0
350
ViewsAsignación de S-1-22-[12]-* SID de Samba a nombres
Samba3 usa SID en el rango S-1-22-1 para usuarios y S-1-22-2 para grupos. Por ejemplo, S-1-22-1-1-10042 es el usuario de UNIX con uid 10042. Me gustaría poder asignar dicho SID a un nombre, como 'myunixaccount', similar a esta funcionalidad para la cuenta de Windows cartografía:
SecurityIdentifier sid = ...; // For instance from FileSystemAccessRule. name = sid.Translate(typeof(NTAccount)).Value;Windows mismo puede hacer este mapeo, pero parece que no puedo encontrar un algoritmo de mapeo.
AGREGADO: Descripción del entorno
Solución propuesta probada en Convertir SID a nombre de usuario en C# . No ayudó. Por lo tanto, alguna descripción adicional del entorno:
- PC con Windows, ya sea unida a un dominio o independiente, con W7 Professional, x86.
- Archivo ubicado en una unidad basada en Samba. Samba se autentica en el controlador AD del dominio.
- Versión de Samba: 4.0.3, ejecutándose en Linux 2.6.18-238, x64.
- PAM para Samba, sesiones interactivas, etc.
- El controlador AD es W2012 con algún atributo de extensión UNIX predeterminado en el directorio para permitir la asignación de UID, etc.
- Bibliotecas de .NET Framework 4.5.2.
- ldap.conf:
piece of ldap.conf
nss_base_passwd=OU=nl,OU=xxx,dc=yyy,dc=local?sub(objectCategory=user) nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber uidNumber nss_map_attribute gidNumber gidNumber nss_map_attribute cn sAMAccountName nss_map_attribute uniqueMember member nss_map_attribute userPassword msSFUPassword nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute loginShell loginShell nss_map_attribute gecos cn nss_map_objectclass posixGroup Group nss_map_attribute shadowLastChange pwdLastSetLos inicios de sesión interactivos en UNIX con autenticación de Windows funcionan bien, dito para recursos compartidos de Samba. Al usar una PC en el dominio, no solicita credenciales.
Algunas muestras, el usuario gle3 (resaltado en 1) también existe en el dominio pero con un SID diferente. El SID utilizado aquí es el Samba SID, como S-1-22-1-1-10001.
En (2) puede ver que el usuario existe en la configuración de contraseña utilizada. Por supuesto, lo siguiente no produce resultados: grep gle3 /etc/passwd , ya que las entradas se usan desde un servidor remoto. El servidor remoto asigna el SID de usuario de gle3 a UNIX uid 10001 y grupo predeterminado 10003.
En (3) puede ver que el grupo predeterminado no existe, y es por eso que los permisos no pueden resolverlo en un nombre.
Entonces, obviamente, Windows de alguna manera le pregunta al servidor de archivos: "Dame los datos en estos SID" y el servidor de archivos Samba responde de alguna manera: Ok, eso es "Unix User\gle3" y "Unix Group\10003" pero no tengo un grupo nombre para este último.
1 answers
Answer question0
He estado jugando con esto hace algún tiempo para construir un rastreador de LAN local en una red de más de 2000 computadoras. Estoy bastante seguro de que lo que está preguntando no es parte del protocolo SMB. De hecho, puede ver eso: si Windows no puede resolver las credenciales, mostrará los SID en las propiedades de seguridad.
Básicamente, lo que sucede es que un SID es un ID de objeto (como un nombre de usuario/grupo) que está asignado a un ID único. Funcionan como GUID. Por lo general, las PC se comunican en SID, no en nombres de usuario.
Ahora, hay diferentes tipos de SID que debe considerar:
- Tiene el SID de Active Directory que puede resolver mediante los métodos estándar. Tenga en cuenta que estos incluyen SID de grupo y usuario.
- Están los SID de la PC local que puede resolver utilizando los métodos estándar. Nuevamente, SID de grupo y usuario. Esto probablemente funcione tanto para Samba como para Windows, aunque solo lo he probado en Windows en el pasado.
- Hay SID en PC remotas que normalmente no se pueden resolver. Básicamente, esto es lo que sucede si obtiene un token NTLM de otra manera.
En realidad, hay mucho más que esto... las credenciales de certificado, los usuarios reservados, etc. también son ID de objeto que se pueden usar para iniciar sesión, pero lo mantendré simple. La conclusión clave de este comentario es que, si bien todos los nombres de usuario tienen un SID, no es cierto que todos los SID también tengan un nombre de usuario .
Si tiene un AD en algún lugar (parece que lo tiene), una configuración adecuada contiene a todos los usuarios aquí. La forma más fácil de obtener el mapeo completo es simplemente enumerar el directorio activo completo. Eso debería contener todas las asignaciones. Básicamente eso funciona así:
DirectoryEntry root = new DirectoryEntry("LDAP://dc=MyCompany,dc=com"); DirectorySearcher search = new DirectorySearcher(root); search.Filter = "(objectCategory=Person)"; search.SearchScope = SearchScope.Subtree; search.PropertiesToLoad.Add("objectSid"); search.PropertiesToLoad.Add("displayName"); foreach(SearchResult result in search.FindAll()) { // grab the data - if present if(result.Properties["objectSid"] != null && result.Properties["objectSid"].Count > 1) { var sid = result.Properties["objectSid"][0]; } if(result.Properties["displayName"] != null && result.Properties["displayName"].Count > 0) { var userName = result.Properties["displayName"][0].ToString(); } }