Linux group domain users

Содержание

Add AD Domain user to sudoers from the command line
9 Answers 9
SSSD
sssd доменные пользователи и локальные группы.
Похожие темы
Edit Sudoers file to allow sudo rights to a AD domain group
The goal of what I am trying to achieve is as follows:
What I’ve done:

Add AD Domain user to sudoers from the command line

I’m setting up an Ubuntu 11.04 server VM for use as a database server. It would make everyone’s lives easier if we could have folks login using windows credentials and perhaps even make the machine work with the current AD-driven security we’ve got elsewhere. The first leg of this was really easy to accomplish — apt-get install likewise-open and I was pretty much in business. The problem I’m having is getting our admins into the sudoers groups — I can’t seem to get anything to take. I’ve tried: a) usermod -aG sudoers [username]
b) adding the user names in several formats (DOMAIN\user, user@domain) to the sudoers file. None of which seemed to take, I still get told «DOMAIN\user is not in the sudoers file. This incident will be reported.» So, how do I add non-local users to the sudoers?

9 Answers 9

I encounter this problem and here’s my solution:

Edit /etc/sudoers : with the following entries

First check aduser using command id

SMB\aduser01@linux01:~/Desktop$ id smb\\aduser02 uid=914883676(SMB\aduser02) gid=914883073(SMB\domain^users) groups=914883073(SMB\domain^users),1544(BUILTIN\Administrators),1545(BUILTIN\Users),914883072(SMB\domain^admins)

getent passwd and gid NUMBERS doesn’t work for me. DOMAIN\\domain^users works for me

%SMB\\domain^users ALL=(ALL) ALL

as we all know individual AD user works also

The %\\ method didn’t work for me. I had to use % , probably because I have my samba/winbind set with winbind use default domain and winbind normalize names set to yes .

we have a long domain name with .local sufix,

%domainname\\group ALL=(ALL) ALL

%domainname.local\\group ALL=(ALL) ALL

but if I only use the groupname like this:

sudo usermod -a -G sudo DOMAIN\username

and replace DOMAIN\user with DOMAIN\\\username .

The problem with the other suggestions is that

they only work when you have access to the corporate LAN (or VPN)
you have to maintain the sudoers file on each and every computer all the time
as a bonus, they didn’t work for me — at all

Instead, I wanted something that

The actual solution is using SSSD and extending the AD schema. This way SSSD fetches sudo settings and user credentials periodically from AD and maintains a local cache of them. The sudo rules are then stored in AD objects, where you can restrict rules to computers, users and commands, even — all that without ever touching a sudoers file on the workstations.

The exact tutorial is way too long to explain here, but you can find the step-by-step guide and some scripts to help with automation here:

Grab the latest release of sudo, get the doc/schema.ActiveDirectory file, then import it (make sure to modify the domain path according to your domain name):

ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=X" "CN=Schema,CN=Configuration,DC=ad,DC=foobar,DC=com" -j .

Verify it with ADSI Edit: open the Schema naming context and look for the sudoRole class.

Now create the sudoers OU on your domain root, this OU will hold all the sudo settings for all your Linux workstations. Under this OU, create a sudoRole object. To create the sudoRole object you have to use ADSI Edit, but once created, you can use Active Directory Users and Computers to modify it.

Let’s assume I have a computer named foo32linux, a user called stewie.griffin and I want to let him run all commands with sudo on that comp. In this case, I create a sudoRole object under the sudoers OU. For the sudoRole you can use any name you want — I stick with the computer name since I use per-computer rules. Now set its attributes as follows:

For commands you can use specific entries as well, like /bin/less or whatever.

SSSD

Add to your /etc/sssd/sssd.conf, at least:

[sssd] services = nss, pam, sudo [domain/AD.FOOBAR.COM] cache_credentials = True

SSSD refreshes its local cache with the updated rules every few hours, but the simplest way to test it is to just reboot the computer. Then log in with the AD user and check:

It should list all the related entires you added to that user and computer. Easy-peasy!

Источник

sssd доменные пользователи и локальные группы.

Есть сервер под rhel 8.4 с доменной авторизацией. Подскажите, как добавить доменного пользователя в локальную группу? Т.е. usernod -aG добавляет, но когда проверяю id username, то вижу только доменные группы. Что-то мне подсказывает, что надо где-то в /etc/pam.d/ шаманить, но что именно? Спасибо.

Покажи nsswitch.conf. Если доменная группа по имени совпадает с локальной, то очевидно, что нифига не получится.

Приветствую. Нет. В домене группы nginx нет. Причем пробовал на Ubuntu, то там все ок. Вижу что id отдает (показывает) локальную группу

Извеняюсь. Что-то скрыть это полотно не получается. Я убрал все что закоментированно #

passwd: sss files systemd group: sss files systemd netgroup: sss files automount: sss files services: sss files shadow: files sss hosts: files dns myhostname aliases: files ethers: files gshadow: files # Allow initgroups to default to the setting for group. # initgroups: files networks: files dns protocols: files publickey: files rpc: files

mplane ( 23.06.21 12:38:02 MSK )
Последнее исправление: mplane 23.06.21 12:43:16 MSK (всего исправлений: 5)

Ок, давай по порядку, что выдаёт:

Как видно, доменный пользователь присутствует в локальной группе.

[root@server ~]# getent group | grep nginx nginx:x:986:fakeuser

Если просто ввести id fakeuser, то получим вывод всех доменных груп в которых он учавствует. Но локальная группа nginx не подтянулась

[root@server ~]# id fakeuser | grep nginx

Ты случаем на этот веселый баг не напоролся?

TL;DR — id показывает фактическое членство в группах, которое определяется при ЛОГИНЕ пользователя.

То есть если ты залогинился под пользователем aaa, потом из другой консоли добавил его в группу bbb, то в сессии пользователя aaa будет виден(и фактически применяться) СТАРЫЙ набор групп(и тут неважно локальные они, или через AD). Лечится костылем — а именно закрытием/открытием новой сессии пользователя aaa.

getent плюет на эти условности — он забирает список групп непосредственно из источника, будь то passwd и/или локальные файлы

Update: хотя нет, не похоже — id ты вызываешь из под рута. Тогда другой вопрос — эти настройки в sssd есть?

Pinkbyte ★★★★★ ( 23.06.21 18:54:09 MSK )
Последнее исправление: Pinkbyte 23.06.21 18:57:00 MSK (всего исправлений: 2)

Блин. Вообще ерунда получилась. Что я нашел. Чисто случайно. Итак сейчас сервера скажем заводятся в новый домен, пусть будет newdomain.local, а юзера попрежнему находятся в старом домене, olddomain.local. Между доменами настроены доверительные отношения. Так вот. На серверах которые еще числятся в старом домене olddomain.local, добавление в группу происходит нормально и id вычитывает локальную группу + кучу доменных. А вот на заведенных уже в новый домен server.newdomain.local уже id не отрабатывает как хочется. В sssd.conf я естественно прописал default_domain_suffix = newdomain, чтобы не приходилось писать fakeuser@newdomain

Но опять же. Ubuntu как-то обошла данная проблема.

З.Ы. hiera то у меня нет. Но строчку добавлять пытался.

Интересно. А сервера те же самые заводятся в новый домен или разворачиваются новые(на более новой версии ОС, например)? Если те же самые, то это вообще не понятно — я бы понял проблемы с определением ДОМЕННЫХ групп, но локальные-то при чем?

1.1.2. Data providers in /etc/nsswitch.conf The default sssd profile establishes SSSD as a source of information by creating sss entries in /etc/nsswitch.conf: passwd: sss files group: sss files netgroup: sss files automount: sss files services: sss files . This means that the system first looks to SSSD if information concerning one of those items is requested: passwd for user information group for user group information netgroup for NIS netgroup information automount for NFS automount information services for information regarding services Only if the requested information is not found in the sssd cache and on the server providing authentication, or if sssd is not running, the system looks at the local files, that is /etc/*. For example, if information is requested about a user ID, the user ID is first searched in the sssd cache. If it is not found there, the /etc/passwd file is consulted. Analogically, if a user’s group affiliation is requested, it is first searched in the sssd cache and only if not found there, the /etc/group file is consulted. In practice, the local files database is not normally consulted. The most important exception is the case of the root user, which is never handled by sssd but by files

т.е. получается у меня не смотрит в files

mplane ( 23.06.21 20:40:07 MSK )
Последнее исправление: mplane 23.06.21 20:43:33 MSK (всего исправлений: 2)

Edit Sudoers file to allow sudo rights to a AD domain group

I recently managed to get my Ubuntu Server 18.04 machine connected to my companies Windows AD. I am able to login with my AD credentials however I want to take it a step further. This is the article I followed in order to get my Ubuntu 18.04 machine onto the windows domain, note I did not do any configuration on restricting ssh login to a domain group as I am still struggling. https://www.smbadmin.com/2018/06/connecting-ubuntu-server-1804-to-active.html?showComment=1548915938955#c6716393705599388679 However.

The goal of what I am trying to achieve is as follows:

Add a line to /etc/sudoers file that specifies an AD group within my organization.
This groups members should have sudo access on the Linux machines in our organisation.

What I’ve done:

I tried adding lines like :
«nameofdomain\nameofgroup ALL=(ALL:ALL) ALL»
And more. However whenever I try to sudo with a user I know is in the group I receive the usual «. user not in sudoers. incident will be reported. «

What could be the reason for this? Is it perhaps due to the configurations I’ve specified when connecting the machine to the AD domain?

The full path to this group is as follows: — domainname/Groups/Elab/Elab-Level3

Here is the configuration for my files used to join the AD domain:

[libdefaults] default_realm = MYREALM dns_lookup_kdc = true dns_lookup_realm = true

[users] default-home = /home/%D/%U default-shell = /bin/bash [active-directory] default-client = sssd os-name = Ubuntu Server os-version = 18.04 [service] automatic-install = no [mydomain] fully-qualified-names = yes automatic-id-mapping = no user-principal = yes manage-system = yes

[sssd] domains = mydomain config_file_version = 2 services = nss, pam, ssh [domain/mydomain] ad_domain = mydomain krb5_realm = MYDOMAIN realmd_tags = manages-system joined-with-adcli cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u@%d access_provider = ad ldap_user_ssh_public_key = altSecurityIdentities

I’m really hoping that someone here has the answer, I’ve searched many many threads and have not been able to crack this nut