Добавить пользователя домена AD в sudoers из командной строки

В моем случае решение заключалось в добавлении опции noperm в запись fstab

10
задан 30 September 2011 в 23:39

11 ответов

Я столкнулся с этой проблемой, и вот мое решение:

Правка /etc/sudoers: со следующими записями

Сначала проверьте aduser с помощью команды id

#id <AD user>( #id domain\\aduser01 )
[d3 ] Результаты по моему:

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 и gid NUMBERS не работают для меня. DOMAIN\\domain^users работает для меня

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

, поскольку все мы знаем, что отдельные пользователи AD работают также

SMB\\<aduser01> ALL=(ALL) ALL
6
ответ дан 25 May 2018 в 18:31

Проблема с другими предложениями заключается в том, что

они работают только тогда, когда у вас есть доступ к корпоративной локальной сети (или VPN), которую вы должны постоянно поддерживать файл sudoers на каждом компьютере в качестве бонус, они не работали для меня - вообще

Вместо этого я хотел что-то, что

они работают только, когда у вас есть доступ к корпоративной локальной сети (или VPN) централизованно управляется

Фактическое решение использует SSSD и расширяет схему AD. Таким образом, SSSD периодически выбирает параметры sudo и учетные данные пользователя из AD и поддерживает локальный кеш. Правила sudo затем сохраняются в объектах AD, где вы можете ограничить правила компьютерами, пользователями и командами, даже - все это, не касаясь файла sudoers на рабочих станциях.

Точный учебник слишком длинный для объяснения здесь, но вы можете найти пошаговое руководство и некоторые сценарии, чтобы помочь в автоматизации здесь:

централизованно управляется

TL; DR:

AD

Захватите последнюю версию sudo, получите файл doc / schema.ActiveDirectory, затем импортируйте его (обязательно измените путь домена в соответствии с вашим доменным именем) :

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

Проверьте его с помощью ADSI Edit: откройте контекст именования doc / schema.ActiveDirectory и найдите класс sudoRole.

Теперь создайте sudoRole OU в вашем корне домена, это подразделение будет содержать все настройки sudo для всех ваших рабочих станций Linux. Под этим OU создайте объект sudoRole. Чтобы создать объект sudoRole, вы должны использовать ADSI Edit, но после его создания вы можете использовать Active Directory - пользователи и компьютеры для его изменения.

Предположим, у меня есть компьютер с именем Пользователи и компьютеры Active Directory , пользователь, называемый stewie.griffin, и я хочу позволить ему запускать все команды с sudo на этом comp. В этом случае я создаю объект sudoRole под подразделением sudoers. Для sudoRole вы можете использовать любое имя, которое вы хотите - я придерживаюсь имени компьютера, так как я использую правила для каждого компьютера. Теперь установите его атрибуты следующим образом:

sudoHost: foo32linux вы должны поддерживать файл sudoers на каждом компьютере все время sudoUser: stewie.griffin [d37 ] Для команд вы также можете использовать определенные записи, например stewie.griffin или что угодно.

SSSD

Добавьте к вашему / etc / sssd / sssd. conf, по крайней мере:

[sssd]
services = nss, pam, sudo

[domain/AD.FOOBAR.COM]
cache_credentials = True

SSSD обновляет свой локальный кеш с обновленными правилами каждые несколько часов, но самый простой способ проверить его - просто перезагрузить компьютер. Затем войдите в систему с пользователем AD и проверьте:

sudo -l

Он должен указать все связанные с вами сведения, которые вы добавили этому пользователю и компьютеру. Easy-Peasy!

2
ответ дан 25 May 2018 в 18:31
  • 1
    Это может быть длинным, но поскольку ссылки становятся недействительными, правило, что основные части должны быть включены здесь, со ссылкой для ссылки. – TheWanderer 3 November 2015 в 06:56
  • 2
    Фактически, я добавил основные части, т. Е. Концепцию. Я мог бы забрать некоторые другие части, но они бесполезны без остального и не понимают большой картины, поэтому я не вижу смысла. Это принесет больше вреда, чем пользы. – bviktor 3 November 2015 в 23:58
  • 3
    является правилом AskUbuntu, что кто-то, кто приходит, должен иметь возможность посмотреть ваш ответ и решить проблему, не выходя на внешний сайт. – TheWanderer 4 November 2015 в 00:00
  • 4
    Добавлена ​​дополнительная информация. – bviktor 4 November 2015 в 02:45

Лучшая информация, которую я мог найти по этому вопросу, здесь:

http://www.mail-archive.com/likewise-open-discuss@lists.likewisesoftware.com/msg00572.html [ ! d1]

Он в основном просит вас изменить ваш файл /etc/sudoers с правильной конфигурацией, чтобы люди из группы вашего администратора в AD имели доступ ко всем привилегиям.

Если вам нужно быть выборочно и ограничивать пользователя, вы тоже можете это сделать. Но он предупреждает, что вы должны убедиться, что имя пользователя в системе Linux используется с помощью команды getend passwd, как показано на рисунке.

1
ответ дан 25 May 2018 в 18:31
  • 1
    Спасибо, правда, не мог понять, где искать. Для записи DOMAIN \\ имя пользователя работает для отдельных пользователей. – Wyatt Barnett 30 September 2011 в 23:38

у нас есть длинное доменное имя с .local sufix,

сопоставить

%domainname\\group ALL=(ALL) ALL

и

[ f2]

работал ...

, но если я использую только такое имя группы:

%Domain^Admins ALL=(ALL) ALL

, он работает.

1
ответ дан 25 May 2018 в 18:31
  • 1
    Это было решение, которое работало в конце. [F1] – mjp 29 March 2017 в 17:51

Использование Centify direct Я добавил пользователя домена в файл / etc / sudoers.

(Пользователь домена) ALL = (ALL) ALL

0
ответ дан 25 May 2018 в 18:31

Я использую общую команду

sudo usermod -a -G sudo DOMAIN\username 

и заменяю DOMAIN\user на DOMAIN\\\username.

0
ответ дан 25 May 2018 в 18:31

у нас есть длинное доменное имя с .local sufix,

сопоставить

%domainname\\group ALL=(ALL) ALL

и

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

работал ...

, но если я использую только такое имя группы:

%Domain^Admins ALL=(ALL) ALL

, он работает.

1
ответ дан 25 July 2018 в 21:15

Проблема с другими предложениями в том, что

  • они работают только при наличии доступа к корпоративной локальной сети (или VPN)
  • , вам необходимо сохранить файл sudoers на каждом компьютере все время
  • в качестве бонуса, они не работали для меня - вообще

Вместо этого я хотел что-то, что

  • кэширует как учетные данные, так и доступ sudo
  • централизованно управляется

Фактическое решение использует SSSD и расширяет схему AD. Таким образом, SSSD периодически выбирает параметры sudo и учетные данные пользователя из AD и поддерживает локальный кеш. Правила sudo затем сохраняются в объектах AD, где вы можете ограничить правила компьютерами, пользователями и командами, даже - все это, не касаясь файла sudoers на рабочих станциях.

Точное руководство слишком длинное для объяснения здесь, но вы можете найти пошаговое руководство и некоторые сценарии, чтобы помочь в автоматизации здесь:

TL; DR:

AD

Захватите последнюю версию sudo , получите файл doc / schema.ActiveDirectory, затем импортируйте его (убедитесь, что вы изменили путь к домену в соответствии с вашим доменным именем):

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

Проверьте его с помощью ADSI Edit: откройте контекст именования схемы и найдите класс sudoRole.

Теперь создайте подразделение sudoers OU в вашем корне домена, это подразделение будет содержать все настройки sudo для всех ваших рабочих станций Linux. Под этим OU создайте объект sudoRole. Чтобы создать объект sudoRole, вы должны использовать ADSI Edit, но после его создания вы можете использовать Active Directory - пользователи и компьютеры для его изменения.

Предположим, у меня есть компьютер с именем foo32linux, пользователь, называемый stewie.griffin и я хочу, чтобы он выполнял все команды с помощью sudo на этом comp. В этом случае я создаю объект sudoRole под подразделением sudoers. Для sudoRole вы можете использовать любое имя, которое вы хотите - я придерживаюсь имени компьютера, так как я использую правила для каждого компьютера. Теперь установите его атрибуты следующим образом:

  • sudoHost: foo32linux
  • sudoCommand: ALL
  • sudoUser: stewie.griffin

Для команд вы также можете использовать определенные записи, например / bin / less или что-то еще.

SSSD

Добавьте в /etc/sssd/sssd.conf, по крайней мере :

[sssd]
services = nss, pam, sudo

[domain/AD.FOOBAR.COM]
cache_credentials = True

SSSD обновляет локальный кеш с обновленными правилами каждые несколько часов, но самый простой способ проверить его - просто перезагрузить компьютер. Затем войдите в систему с пользователем AD и проверьте:

sudo -l

Он должен указать все связанные с вами сведения, которые вы добавили этому пользователю и компьютеру. Easy-Peasy!

2
ответ дан 31 July 2018 в 11:00

Я использую общую команду

sudo usermod -a -G sudo DOMAIN\username 

и заменяю DOMAIN\user на DOMAIN\\\username.

0
ответ дан 2 August 2018 в 02:55

Наилучшая информация, которую я мог найти по этому вопросу, здесь:

http://www.mail-archive.com/likewise-open-discuss@lists.likewisesoftware.com/msg00572 .html

Он в основном просит вас изменить ваш файл /etc/sudoers с правильной конфигурацией, чтобы люди из группы вашего администратора в AD имели доступ ко всем привилегиям.

Если вам нужно быть избирательным и ограничивать пользователем, вы также можете это сделать. Но он предупреждает, что вы должны убедиться, что имя пользователя в системе Linux используется с помощью команды getend passwd, как показано.

1
ответ дан 4 August 2018 в 18:44

Проблема с другими предложениями в том, что

  • они работают только при наличии доступа к корпоративной локальной сети (или VPN)
  • , вам необходимо сохранить файл sudoers на каждом компьютере все время
  • в качестве бонуса, они не работали для меня - вообще

Вместо этого я хотел что-то, что

  • кэширует как учетные данные, так и доступ sudo
  • централизованно управляется

Фактическое решение использует SSSD и расширяет схему AD. Таким образом, SSSD периодически выбирает параметры sudo и учетные данные пользователя из AD и поддерживает локальный кеш. Правила sudo затем сохраняются в объектах AD, где вы можете ограничить правила компьютерами, пользователями и командами, даже - все это, не касаясь файла sudoers на рабочих станциях.

Точное руководство слишком длинное для объяснения здесь, но вы можете найти пошаговое руководство и некоторые сценарии, чтобы помочь в автоматизации здесь:

TL; DR:

AD

Захватите последнюю версию sudo , получите файл doc / schema.ActiveDirectory, затем импортируйте его (убедитесь, что вы изменили путь к домену в соответствии с вашим доменным именем):

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

Проверьте его с помощью ADSI Edit: откройте контекст именования схемы и найдите класс sudoRole.

Теперь создайте подразделение sudoers OU в вашем корне домена, это подразделение будет содержать все настройки sudo для всех ваших рабочих станций Linux. Под этим OU создайте объект sudoRole. Чтобы создать объект sudoRole, вы должны использовать ADSI Edit, но после его создания вы можете использовать Active Directory - пользователи и компьютеры для его изменения.

Предположим, у меня есть компьютер с именем foo32linux, пользователь, называемый stewie.griffin и я хочу, чтобы он выполнял все команды с помощью sudo на этом comp. В этом случае я создаю объект sudoRole под подразделением sudoers. Для sudoRole вы можете использовать любое имя, которое вы хотите - я придерживаюсь имени компьютера, так как я использую правила для каждого компьютера. Теперь установите его атрибуты следующим образом:

  • sudoHost: foo32linux
  • sudoCommand: ALL
  • sudoUser: stewie.griffin

Для команд вы также можете использовать определенные записи, например / bin / less или что-то еще.

SSSD

Добавьте в /etc/sssd/sssd.conf, по крайней мере :

[sssd]
services = nss, pam, sudo

[domain/AD.FOOBAR.COM]
cache_credentials = True

SSSD обновляет локальный кеш с обновленными правилами каждые несколько часов, но самый простой способ проверить его - просто перезагрузить компьютер. Затем войдите в систему с пользователем AD и проверьте:

sudo -l

Он должен указать все связанные с вами сведения, которые вы добавили этому пользователю и компьютеру. Easy-Peasy!

2
ответ дан 6 August 2018 в 03:08

Другие вопросы по тегам:

Похожие вопросы: