Mapowanie Samby S-1-22- [12] - * Identyfikator SID na nazwy

Question

Samba3 używa identyfikatorów SID w zakresie S-1-22-1 dla użytkowników i S-1-22-2 dla grup. Na przykład S-1-22-1-1-10042 jest użytkownikiem systemu UNIX z identyfikatorem 10042. Chciałbym umieć odwzorować taki identyfikator SID na nazwę, np. "Mój system", podobnie do tej funkcji dla systemu Windows mapowanie kont:

SecurityIdentifier sid = ...; // For instance from FileSystemAccessRule. 
name = sid.Translate(typeof(NTAccount)).Value; 

Sam system Windows jest w stanie wykonać to mapowanie, ale nie mogę znaleźć algorytmu mapowania.

DODANO: Środowisko Opis

Testowany proponowane rozwiązanie na Convert SID to Username in C#. To nie pomogło. Dlatego niektóre dodatkowe opisy środowiska:

• Komputer z systemem Windows, albo dołączony do domeny lub samodzielny, z systemem W7 Professional, x86.
• Plik zlokalizowany na dysku opartym na Sambie. Samba uwierzytelnia się do kontrolera AD domeny.
• Wersja Samby: 4.0.3, działająca pod kontrolą systemu Linux 2.6.18-238, x64.
• PAM Samby, sesje interaktywne itp
• kontroler AD W2012 z jakimś atrybutem domyślnym rozszerzeniem UNIX w katalogu umożliwić odwzorowanie UID itp
• bibliotek .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 

Interactive logowania w systemie UNIX z Windows Authentication działać dobrze, Dito do udziałów Samby. Podczas korzystania z komputera w domenie nie pyta o poświadczenia.

Niektóre próbki, użytkownik gle3 (wyróżniony w 1) również istnieje w domenie, ale ma inny identyfikator SID. Używany tutaj identyfikator SID to identyfikator SID Samby, taki jak S-1-22-1-1-10001.

W (2) widać, że użytkownik istnieje w używanej konfiguracji passwd. Poniższe oczywiście nie daje żadnych wyników: grep gle3 /etc/passwd, ponieważ wpisy są używane ze zdalnego serwera. Zdalny serwer odwzorowuje identyfikator SID użytkownika dla KG3 na UNIDID 10001 i grupę domyślną 10003.

W (3) widać, że grupa domyślna nie istnieje, i dlatego uprawnienia nie mogą jej rozwiązać na nazwę .

Oczywistym jest, że Windows w jakiś sposób pyta serwer plików: "podaj dane na temat tych identyfikatorów SID", a serwer plików Samby odpowie w jakiś sposób: Ok, to jest "Unix User \ gle3" i "Grupa Unix \ 10003", ale ja nie ma nazwy grupy dla tego ostatniego.

Answer 1

byłem toying wokół z tego jakiś czas temu do budowy robota lokalnej LAN w sieci komputerowej 2000+. Jestem prawie pewien, że to, o co prosisz, nie jest częścią protokołu SMB. Widać, że: jeśli system Windows nie może rozpoznać poświadczeń, pokaże identyfikatory SID we właściwościach zabezpieczeń.

Zasadniczo chodzi o to, że identyfikator SID jest identyfikatorem obiektu (takim jak nazwa użytkownika/grupa), który jest odwzorowany na unikalny identyfikator. Działają jak GUID. Zwykle komunikacja z komputerem odbywa się w SID, a nie w nazwach użytkowników.

Teraz tam różne rodzaje SID trzeba rozważyć:

1. Masz SID Active Directory, które można rozwiązać przy użyciu standardowych metod. Należy pamiętać, że obejmują one identyfikatory SID grupy i użytkownika.
2. Istnieją lokalne identyfikatory SID komputera, które można rozwiązać przy użyciu standardowych metod. Ponownie, identyfikator SID grupy i użytkownika. To prawdopodobnie działa zarówno w Sambie, jak i w Windowsie, chociaż w przeszłości testowałem to tylko w systemie Windows.
3. Na zdalnych komputerach są identyfikatory SID, których normalnie nie można rozwiązać. Zasadniczo dzieje się tak, jeśli otrzymasz token NTLM w inny sposób.

W rzeczywistości jest o wiele więcej ... poświadczenia certyfikatów, zarezerwowani użytkownicy itp. Są również identyfikatorami obiektów, z których można się logować - ale po prostu będę proste. Kluczowym wnioskiem z tego komentarza jest to, że podczas gdy wszystkie nazwy użytkowników mają identyfikator SID, , nie jest prawdą, że wszystkie identyfikatory SID mają również nazwę użytkownika.

Jeśli masz gdzieś AD (wydaje się, że to robisz), właściwa konfiguracja zawiera tutaj wszystkich użytkowników. Najprostszym sposobem uzyskania pełnego mapowania jest wyliczenie pełnego katalogu aktywnego. To powinno zawierać wszystkie mapowania. W zasadzie to działa tak:

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(); 
    } 
}