On 2025-04-01 12:25, Alexander Bokovoy wrote:
On Аўт, 01 кра 2025, Jostein Fossheim wrote:
I was not completely able to let this rest, so I dived deeper
into the mystical name-resolving that occurred via powershell.
It turns out that the SID in question has been added to the
Foreign Security Principials subtree in LDAP, but only visible
through an ldap search or ldap browser other than "Active
Directory Users and Computers" ADSI Edit for example. And it
turns out that I can actually create an Domain Local Group,
and ad the Foreign Security Principial to that group via its
DN.
And now I have an AD group which contain my IPA-NAS-LDAP\admin
user (and it do actually resolve in the "Active Directory
Users and Computers"-view as well. And this group I can assign
other Rights in my Active Directory. I have only tested with
file-services so far though and I can indeed regulate access
control for my IPA-users, so I am quite satisfied so far
Good, thanks for the investigation.
As you can see on the attached picture, I am actually also able to
log into windows with my IPA-user, when I add my "group" to the
"Allow logon localy" GPO, for domain controllers. I willl dig some
more into the exact reason my user is was added to the "Foreign
Security Principials"-container.
I'm sure most of things will work once you added the SID to corresponding
ACLs. That's expected. Most of problems I've encountered are related to
how Windows UI is unable to discover the user/group names in those
tools to be able to convert those names (later) to SIDs. So once you
added the SID to an ACL, SID will be used correctly.
For users actual issue is that Windows UI cannot look those users up
properly. And fixing all edge cases is not always possible.
As assumed, it seems that triggering some powershell activity like
this (adding and removing them via a local group):
PS C:\Users\Administrator> Add-LocalGroupMember -Group "Cert
Publishers" -Member 'S-1-5-21-355267255-715991334-1594671509-1005'
PS C:\Users\Administrator> Remove-LocalGroupMember -Group "Cert
Publishers" -Member 'S-1-5-21-355267255-715991334-1594671509-1005'
PS C:\Users\Administrator> Add-LocalGroupMember -Group "Cert
Publishers" -Member 'S-1-5-21-355267255-715991334-1594671509-1006'
PS C:\Users\Administrator> Remove-LocalGroupMember -Group "Cert
Publishers" -Member 'S-1-5-21-355267255-715991334-1594671509-1006'
Indeed adds the users to the ForeignSecurityPrinicipials-container.
But.. This are the ForeignSecurityPrinicipials for two users ipauser1
and ipauser2 and they resolve nicely everywhere (se attached
pictures).
From ipa:
ldapsearch -LLLQ uid=ipauser* ipaNTSecurityIdentifier
dn: uid=ipauser2,cn=users,cn=accounts,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
ipaNTSecurityIdentifier: S-1-5-21-355267255-715991334-1594671509-1005
dn: uid=ipauser1,cn=users,cn=accounts,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
ipaNTSecurityIdentifier: S-1-5-21-355267255-715991334-1594671509-1006
When I search the relevant AD-tree:
ldapsearch -Y GSS-SPNEGO -LLLQ -H
"ldap://mad-nas.mad-nas.lab.skyfritt.net"; -b
CN=ForeignSecurityPrincipals,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
dn: CN=S-1-5-21-355267255-715991334-1594671509-1005,CN=ForeignSecurityPrincipa
ls,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
objectClass: top
objectClass: foreignSecurityPrincipal
cn: S-1-5-21-355267255-715991334-1594671509-1005
distinguishedName:
CN=S-1-5-21-355267255-715991334-1594671509-1005,CN=ForeignS
ecurityPrincipals,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
instanceType: 4
whenCreated: 20250401115637.0Z
whenChanged: 20250401115637.0Z
uSNCreated: 73769
memberOf: CN=TestGroup,CN=Users,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
uSNChanged: 73769
showInAdvancedViewOnly: TRUE
name: S-1-5-21-355267255-715991334-1594671509-1005
objectGUID:: yzIrE30EUEiqjZwGr6vBcg==
objectSid:: AQUAAAAAAAUVAAAAt/IsFSYprSqVwQxf7QMAAA==
objectCategory:
CN=Foreign-Security-Principal,CN=Schema,CN=Configuration,DC=ma
d-nas,DC=lab,DC=skyfritt,DC=net
dSCorePropagationData: 16010101000000.0Z
dn: CN=S-1-5-21-355267255-715991334-1594671509-1006,CN=ForeignSecurityPrincipa
ls,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
objectClass: top
objectClass: foreignSecurityPrincipal
cn: S-1-5-21-355267255-715991334-1594671509-1006
distinguishedName:
CN=S-1-5-21-355267255-715991334-1594671509-1006,CN=ForeignS
ecurityPrincipals,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
instanceType: 4
whenCreated: 20250401120047.0Z
whenChanged: 20250401120047.0Z
uSNCreated: 73781
uSNChanged: 73781
showInAdvancedViewOnly: TRUE
name: S-1-5-21-355267255-715991334-1594671509-1006
objectGUID:: mKBqKgpDY0q1CcjgKI7DtA==
objectSid:: AQUAAAAAAAUVAAAAt/IsFSYprSqVwQxf7gMAAA==
objectCategory:
CN=Foreign-Security-Principal,CN=Schema,CN=Configuration,DC=ma
d-nas,DC=lab,DC=skyfritt,DC=net
dSCorePropagationData: 16010101000000.0Z
Since both resolves after they are added to the the
ForeignSecurityPrincipals-Container, and the entry does not have any
usernames, etc, they have to lookup via some other channel. You wrote
that "LSA RPC command lsa_LookupSids to do SID to name transformation
which would work for users and groups.", is this done via the
samba-instance running on IPA, after IPA-AD-Trust-controller is
installed?
I played with the rpclient decribed in this article:
https://www.hackingarticles.in/active-directory-enumeration-rpcclient/
rpcclient -k ipa-nas.ipa-nas.lab.skyfritt.net
rpcclient $> queryuser ipauser1
User Name : ipauser1
Full Name : ipa1 user2
Home Drive :
[...]
Somewhat wiser at least.
