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

neighter

%domainname\\group ALL=(ALL) ALL

ни

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

обработанный...

но если я только использую groupname как это:

%Domain^Admins ALL=(ALL) ALL

работает.

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

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

Сначала проверьте aduser, используя команду id

#id <AD user>( #id domain\\aduser01 )

Результаты на мои:

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

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

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

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

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

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

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

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

sudo usermod -a -G sudo DOMAIN\username 

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

Проблема с другими предложениями - это

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

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

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

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

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

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

TL; DR:

AD

Захватите последний выпуск sudo, получите документ/схему. Файл 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: откройте контекст именования Схемы и ищите sudoRole класс.

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

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

• sudoHost: foo32linux
• sudoCommand: ВСЕ
• 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

Это должно перечислить все связанные записи, которые Вы добавили к тому пользователю и компьютеру. Легкий-peasy!

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

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

sudo visudo

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

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

в конец sudoers.