Отображение Samba S-1-22- [12] - * SID в именах

Samba3 использует SID в диапазоне S-1-22-1 для пользователей и S-1-22-2 для групп. Например, S-1-22-1-1-10042 является пользователем UNIX с uid 10042. Я хотел бы иметь возможность отображать такой SID в имя, например "myunixaccount", подобно этой функции для сопоставления учетных записей Windows:

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

Сама Windows может выполнить это сопоставление, но мне кажется не удается найти алгоритм сопоставления.

ДОБАВЛЕНО: Описание среды

Протестировано предлагаемое решение на Преобразование SID в имя пользователя на С#. Это не помогло. Поэтому некоторое дополнительное описание среды:

Windows PC, либо подключенный к домену, либо автономный, запустив W7 Professional, x86.
Файл, расположенный на диске Samba. Samba аутентифицируется контроллером домена AD.
Версия Samba: 4.0.3, работающая под Linux 2.6.18-238, x64.
PAM для Samba, интерактивные сеансы и т.д.
Контроллер AD - W2012 с некоторым атрибутом расширения UNIX по умолчанию в каталоге, позволяющим отображать UID и т.д.
Библиотеки .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

Интерактивные входы в систему UNIX с аутентификацией Windows работают нормально, dito для акций Samba. При использовании ПК в домене он не запрашивает учетные данные.

Некоторые образцы, пользователь gle3 (выделено в 1) также существует в домене, но с другим SID. SID используется здесь Samba SID, например S-1-22-1-1-10001.

В (2) вы можете видеть, что пользователь существует в используемой конфигурации passwd. Конечно, следующие результаты не дают результатов: grep gle3 /etc/passwd, поскольку записи используются с удаленного сервера. Удаленный сервер сопоставляет SID пользователя gle3 с UNIX uid 10001 и группой 10003 по умолчанию.

В (3) вы можете видеть, что группа по умолчанию не существует, и поэтому разрешения не могут разрешить ее имени.

Таким образом, очевидно, что Windows как-то спрашивает файловый сервер: "дайте мне данные об этих идентификаторах безопасности", и файловый сервер Samba так или иначе ответит: "Ну, это" Unix User\gle3 "и" Unix Group\10003 ", но я не имя группы для последней.

Ответ 1

Я собирался с этим некоторое время назад для создания локального искателя локальной сети в 2000+ компьютерной сети. Я уверен, что то, что вы просите, не является частью протокола SMB. Фактически вы можете увидеть, что: если Windows не может разрешить учетные данные, она покажет SID в свойствах безопасности.

В основном происходит то, что SID - это идентификатор объекта (например, имя пользователя/группа), сопоставленный с уникальным идентификатором. Они работают как GUID. Обычно ПК взаимодействует в SID, а не в именах пользователей.

Теперь у вас есть разные типы SID:

У вас есть идентификатор службы каталогов Active Directory, который можно разрешить с помощью стандартных методов. Обратите внимание, что они включают в себя групповые и пользовательские SID.
Здесь есть локальный идентификатор ПК, который можно разрешить с помощью стандартных методов. Опять же, SID группы и пользователя. Это, вероятно, работает как для Samba, так и для Windows, хотя я тестировал ее только в Windows в прошлом.
Там SID на удаленном ПК, который обычно не может быть разрешен. В основном это происходит, если вы получаете токен NTLM любым другим способом.

На самом деле гораздо больше, чем это... учетные данные сертификатов, зарезервированные пользователи и т.д. - все это также идентификатор объекта, который можно использовать для входа в систему - но я просто буду держать его простым. Ключевой вывод из этого комментария состоит в том, что, хотя все имена пользователей имеют SID, это не так, что все SID также имеют имя пользователя.

Если у вас есть AD где-то (вы, похоже, делаете), то правильная настройка содержит всех пользователей здесь. Самый простой способ получить полное отображение - просто перечислить полный активный каталог. Это должно содержать все сопоставления. В основном это работает следующим образом:

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