c# - Mapeo de Samba S-1-22-[12]-* SID en nombres

security-identifier

Question

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 un SID de este tipo 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 es capaz de hacer este mapeo, pero parece que no puedo encontrar un algoritmo de mapeo.

AÑADIDO: Descripción del entorno

Solución propuesta probada en Convertir SID a nombre de usuario en C # . No ayudó. Por lo tanto, una descripción adicional del entorno:

• PC con Windows, ya sea unido a un dominio o independiente, ejecutando W7 Professional, x86.
• Archivo ubicado en disco basado en Samba. Samba se autentica al controlador AD de dominio.
• Versión de Samba: 4.0.3, que se ejecuta 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.
• Librerías 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 pwdLastSet

Los inicios de sesión interactivos en UNIX con autenticación de Windows funcionan bien, dito para los recursos compartidos de Samba. Cuando se usa 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 usado aquí es el Samba Samba, 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 utilizan desde el servidor remoto. El servidor remoto asigna el SID de usuario de gle3 a UNIX uid 10001 y al grupo predeterminado 10003.

En (3) puede ver que el grupo predeterminado no existe, y es por eso que los permisos no pueden resolverlo con un nombre.

Entonces, obviamente, Windows de alguna manera le pregunta al servidor de archivos: "dame los datos en estos SID" y la respuesta del servidor de archivos Samba de alguna manera: Ok, eso es "Unix User / gle3" y "Unix Group / 10003" pero no tengo un grupo Nombre para el último.

Answer 1

He estado jugando con esto hace algún tiempo para construir un rastreador de LAN local en una red de computadoras de más de 2000. Estoy bastante seguro de que lo que estás preguntando no es parte del protocolo SMB. Realmente puede ver eso: si Windows no puede resolver las credenciales, mostrará el 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 se asigna a un ID único. Funcionan como GUID''s. Por lo general, las PC se comunican en SID, no en nombres de usuario.

Ahora, hay diferentes tipos de SID que debes considerar:

1. Tiene el SID de Active Directory que puede resolver utilizando los métodos estándar. Tenga en cuenta que estos incluyen grupo y usuario SID.
2. Están los PC SID locales que puede resolver utilizando los métodos estándar. De nuevo, grupo y usuario de SID. Probablemente esto funciona tanto para Samba como para Windows, aunque solo lo he probado en Windows en el pasado.
3. Hay SID en las PC remotas que normalmente no se pueden resolver. Básicamente, esto es lo que sucede si obtienes un token NTLM de una manera diferente.

En realidad, hay mucho más que esto: las credenciales de certificado, los usuarios reservados, etc. también son identificadores de objetos que se pueden usar para iniciar sesión, pero lo haré 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 hace), una configuración adecuada contiene todos los usuarios aquí. La forma más fácil de obtener la asignación completa 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();
}
}