Estoy configurando una máquina virtual de servidor Ubuntu 11.04 para usar como servidor de base de datos. Facilitaría la vida de todos si pudiéramos hacer que la gente inicie sesión con las credenciales de Windows y tal vez incluso hacer que la máquina funcione con la seguridad actual basada en AD que tenemos en otros lugares.

La primera etapa de esto fue realmente fácil de lograr, apt-get install likewise-openy yo estaba prácticamente en el negocio. El problema que estoy teniendo es que nuestros administradores entren en los grupos de sudoers; parece que no puedo obtener nada para llevar. He intentado:

a) usermod -aG sudoers [username]
b) agregar los nombres de usuario en varios formatos (DOMINIO \ usuario, usuario @ dominio) al archivo sudoers.

Ninguno de los cuales pareció tomar, todavía me dicen "DOMINIO \ usuario no está en el archivo sudoers. Este incidente será reportado".

Entonces, ¿cómo agrego usuarios no locales a los sudoers?

Me encuentro con este problema y aquí está mi solución:

Editar /etc/sudoers: con las siguientes entradas

Primero verifique el aduser usando la identificación del comando

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

Resultados sobre el mío:

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 passwdy gid NUMBERSno funciona para mi DOMAIN\\domain^usersfunciona para mi

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

como todos sabemos, el usuario individual de AD también trabaja

SMB\\<aduser01> ALL=(ALL) ALL

tenemos un nombre de dominio largo con sufijo .local,

más cerca del

%domainname\\group ALL=(ALL) ALL

ni el

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

trabajó...

pero si solo uso el nombre del grupo de esta manera:

%Domain^Admins ALL=(ALL) ALL

funciona.

El problema con las otras sugerencias es que

• solo funcionan cuando tienes acceso a la LAN corporativa (o VPN)
• tienes que mantener el archivo sudoers en cada computadora todo el tiempo
• como beneficio adicional, no funcionaron para mí, en absoluto

En cambio, quería algo que

• almacena en caché tanto las credenciales como el acceso a sudo
• se gestiona de forma centralizada

La solución real es usar SSSD y extender el esquema AD. De esta forma, SSSD obtiene periódicamente configuraciones de sudo y credenciales de usuario de AD y mantiene una memoria caché local de ellas. Las reglas de sudo se almacenan en objetos AD, donde puede restringir las reglas a computadoras, usuarios y comandos, incluso, todo eso sin siquiera tocar un archivo de sudoers en las estaciones de trabajo.

El tutorial exacto es demasiado largo para explicarlo aquí, pero puede encontrar la guía paso a paso y algunos scripts para ayudar con la automatización aquí:

• Integrando Ubuntu con Active Directory

TL; DR:

ANUNCIO

Obtenga la última versión de sudo , obtenga el archivo doc / schema.ActiveDirectory , luego impórtelo (asegúrese de modificar la ruta del dominio de acuerdo con su nombre de dominio):

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

Verifíquelo con ADSI Edit: abra el contexto de nomenclatura de Schema y busque la clase sudoRole .

Ahora cree la unidad organizativa sudoers en la raíz de su dominio, esta unidad organizativa contendrá todas las configuraciones de sudo para todas sus estaciones de trabajo Linux. Debajo de esta unidad organizativa, cree un objeto sudoRole. Para crear el objeto sudoRole, debe usar ADSI Edit, pero una vez creado, puede usar Usuarios y equipos de Active Directory para modificarlo.

Supongamos que tengo una computadora llamada foo32linux , un usuario llamado stewie.griffin y quiero permitirle ejecutar todos los comandos con sudo en esa comp. En este caso, creo un objeto sudoRole debajo de la unidad organizativa sudoers . Para el sudoRole puede usar el nombre que desee: me quedo con el nombre de la computadora ya que uso las reglas por computadora. Ahora establezca sus atributos de la siguiente manera:

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

Para los comandos, también puede utilizar entradas específicas, como / bin / less o lo que sea.

SSSD

Agregue a su /etc/sssd/sssd.conf , al menos:

[sssd]
services = nss, pam, sudo

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

SSSD actualiza su caché local con las reglas actualizadas cada pocas horas, pero la forma más sencilla de probarlo es simplemente reiniciar la computadora. Luego inicie sesión con el usuario de AD y verifique:

sudo -l

Debería enumerar todas las entradas relacionadas que agregó a ese usuario y computadora. ¡Pan comido!

La mejor información que pude encontrar sobre el tema está aquí:

http://www.mail-archive.com/[email protected]/msg00572.html

Básicamente, le pide que modifique su /etc/sudoersarchivo con la configuración correcta para permitir que las personas en el grupo de su administrador en AD tengan acceso a todos los privilegios.

Si necesita ser selectivo y restringido por el usuario, también puede hacerlo. Pero advierte que debe asegurarse de averiguar cuál es el nombre del usuario en el sistema Linux mediante el getend passwdcomando como se muestra.

Usando Centify Direct , he agregado un usuario de dominio al archivo / etc / sudoers.

(Usuario de dominio) TODOS = (TODOS) TODOS

Yo uso el comando común

sudo usermod -a -G sudo DOMAIN\username 

y reemplazar DOMAIN\usercon DOMAIN\\\username.