Отображение 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:

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

Интерактивные входы в систему 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();
   }
}