У нас длинное доменное имя с суффиксом.local,

соседствовать

%domainname\\group ALL=(ALL) ALL

ни

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

работал...

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

%Domain^Admins ALL=(ALL) ALL

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

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

sudo usermod -a -G sudo DOMAIN\username 

и заменить DOMAIN\user с DOMAIN\\\username,

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

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

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

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

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

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

• Интеграция Ubuntu с Active Directory

TL; DR:

ОБЪЯВЛЕНИЕ

Возьмите последнюю версию 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 в корневом каталоге вашего домена. Это подразделение будет содержать все настройки sudo для всех ваших рабочих станций Linux. Под этим подразделением создайте объект sudoRole. Чтобы создать объект sudoRole, вы должны использовать ADSI Edit, но после его создания вы можете использовать Active Directory Users and Computers для его изменения.

Предположим, у меня есть компьютер с именем foo32linux, пользователь с именем stewie.griffin, и я хочу позволить ему запускать все команды с sudo на этом компе. В этом случае я создаю объект 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

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

sudo visudoзатем вставьте:

      "%domain users" ALL=(ALL) ALL

работал у меня на Ubuntu 20.04.2 LTS. Он также работал с другими произвольными группами AD.

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

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

Я бы предпочел ответить @bviktor, но я еще не достаточно продвинутый администратор домена. Ни один из других ответов выше не помог мне. Я всегда получал одно и то же сообщение об ошибке, о котором сообщает OP. Формат сообщения об ошибке подсказывает мне, что записи в sudoers чувствительны к регистру, но я никогда не видел обсуждения этого в многочисленных сообщениях, которые я читал по этой теме. Например, в некоторых сообщениях предлагается название группы "Домен ^ Администраторы", тогда как в других предлагается "домен ^ администраторы". Ни то, ни другое не сработало в моем случае. На контроллере домена (Synology DS) группа отображается как "Администраторы домена", но на клиентском ПК (под управлением Ubuntu Studio 18.04) команда "id" возвращает группу как "администраторы домена".

Что мне удалось, так это использовать:

sudo visudo

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

username@my.domain.name ALL=(ALL) ALL

до конца sudoers.

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

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

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

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

Хорошо, ни один из этих ответов на самом деле не работал для меня. Ответ о том, чтобы изменить схему AD, может быть приятным, если у вас есть большой парк машин Linux в вашем имении, но для небольшого числа это нецелесообразно.

Что сработало для меня, так это:

Создайте группу sudo в AD, добавьте в нее пользователей. на ваших машинах Linux (с учетной записью, которая может использовать sudo): создайте файл в /etc/sudoers.d

      sudo touch /etc/sudoers.d/{yourdomain}

Теперь отредактируйте файл sudoers с помощью visudo. Не вносите никаких изменений и существуйте в редакторе, он должен предложить вам отредактировать новый файл в sudoers.d.

добавьте это в этот файл:

      %sudo@yourdomain.name ALL=(ALL:ALL) ALL

Сохраните этот файл.

Тебе должно быть хорошо сейчас. Члены группы sudo в вашей AD могут использовать sudo на любом компьютере с этим новым файлом.

После того, как пользователь входит в систему при подключении к домену, я проверил это на компьютере (моем ноутбуке), отключенном от домена, и он все еще работает, поскольку членство в группах кэшируется.

Примечание. Не редактируйте новый файл напрямую, это не сработает.