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.
Does samba query the local-ldap tree on IPA for this to work then? Or do
samba have it's own mystery database (or cache) as well?
--
Vennlig Hilsen
Jostein Fossheim
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
