Samba3在用户S-1-22-1的范围内使用SID,在组中使用S-1-22-2.例如,S-1-22-1-1-10042是具有uid 10042的UNIX用户.我希望能够将这样的SID映射到名称,如'myunixaccount',类似于Windows帐户的此功能制图:
SecurityIdentifier sid = ...; // For instance from FileSystemAccessRule.
name = sid.Translate(typeof(NTAccount)).Value;
Run Code Online (Sandbox Code Playgroud)
Windows本身能够进行此映射,但我似乎无法找到映射算法.
增加:环境描述
测试了在C#中将SID转换为用户名的建议解决方案.它没有帮助.因此一些额外的环境描述:
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
Run Code Online (Sandbox Code Playgroud)
使用Windows身份验证的UNIX上的交互式登录工作正常,适用于Samba共享的dito.在域上使用PC时,它不会要求凭据.
一些样本,用户gle3(在1中突出显示)也存在于域中但具有不同的SID.这里使用的SID是Samba SID,如S-1-22-1-1-10001.
在(2)中,您可以看到用户存在于使用过的passwd配置中.以下当然不会产生任何结果:grep gle3 /etc/passwd …
在进行从SID到NTAccount的转换时,我使用以下代码:
DirectorySecurity folder_sec = Directory.GetAccessControl("c:\\test", AccessControlSections.All);
AuthorizationRuleCollection rules = folder_sec.GetAccessRules(true, true, typeof(SecurityIdentifier));
foreach (FileSystemAccessRule rule in rules)
{
SecurityIdentifier sid = new SecurityIdentifier(rule.IdentityReference.Value);
IdentityReference name = sid.Translate(typeof(NTAccount));
string output = name + " | " + sid.tostring();
}
Run Code Online (Sandbox Code Playgroud)
是的我意识到你可以NTAccount从folder_sec.GetAccessRules方法中获得一个来自但我发现SecurityIdentifier.Translate正在使用相同的子程序并且发生相同的错误.在一天结束时,ACL只是SID数组.
如果您有两个具有完全相同名称但位于两个单独域(受信任,而不是子域)的活动目录对象(组,用户等),则该translate方法返回错误的NTAccount.它最终在执行代码的机器所在的域中返回具有相同名称的NTAccount.NTAccount从其他域中获取与您的域中的另一个对象共享相同名称的s返回正常.
假设您在domain_frank中的计算机上有一个目录,这是ACL:
如果你运行它,虽然上面的代码output看起来像:
domain_frank\IT Team | S-1-5-21-4000000000-4000000000-2000000000-28480
domain_frank\IT Team | S-1-5-21-1000000000-8000000000-3000000000-81912
domain_frank\Dave | S-1-5-21-4000000000-4000000000-2000000000-86875
domain_bob\Ted | S-1-5-21-1000000000-8000000000-3000000000-96521
Run Code Online (Sandbox Code Playgroud)
假设名为Dave的对象不在domain_bob中,并且名为Ted的对象不在domain_frank中.但是如果查看SID,您可以清楚地看到域部分完全不同,因此您至少在SID中知道ACL中的正确对象.与查找有关的事情正在打破.
我的结果是我必须编写自己的算法来查看SID并在SID所属的域上查找活动目录.非常非常缓慢,并且总是疼痛.
这是一个已知的错误,是否有一个令人满意的解决方案?