On 28/03/2025 13:50, Alexander Bokovoy wrote:
On Пят, 28 сак 2025, Jostein Fossheim wrote:
On 2025-03-28 08:42, Alexander Bokovoy wrote:
Sure, what's surprising here? From IPA side you can access resources on
the trusted AD forest side if you have inbound trust. You cannot do
that
from Windows machines because their UI calls into some DCE RPC APIs we
do not support on IPA side. They also try to call into Global Catalog
and the primary LDAP instances while expecting those to have AD LDAP
schema and DIT structure. IPA is not supporting those so no wonder
things fail.
One strange observation after playing more with SIDs. I was trying to
add the admin-user from IPA's sid to a local group,.
The domain controller of course don't have any local groups or users.
Well, it has some, look at this:
PS C:\Users\Administrator> Get-LocalGroup
Name Description
---- -----------
Cert Publishers Members of this group are
permitted to publish certificates to the directory
RAS and IAS Servers Servers in this group can
access remote access properties of users
Allowed RODC Password Replication Group Members in this group can
have their passwords replicated to all read-only d...
Denied RODC Password Replication Group Members in this group cannot
have their passwords replicated to any read-onl...
PS C:\Users\Administrator> Add-LocalGroupMember -Group "Cert
Publishers" -Member "S-1-5-21-355267255-715991334-1594671509-500"
PS C:\Users\Administrator> Get-LocalGroupMember "Cert Publishers"
ObjectClass Name PrincipalSource
----------- ---- ---------------
User IPA-NAS-LAB\admin ActiveDirectory
PS C:\Users\Administrator>
It seems that via this powershell-command it is actually able to
resolve the SID, from the IPA-domain, but this puzzles me, and I
cannot understand why, the SID is not resolved when i look at the
previous mentioned NTFS-acls in the gui?
Welcome to Windows Security Tab world. ;)
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
I can show more practically examples and investigate this further, the
next few days, and try to understand exactly why the Foreign Security
Principial was created in the ldap tree.
It should be fairly trivial to import all sids via a scripted automation
or a similar mechanism.
It looks rather promising when it comes to let IPA-users access (at
least) file-services on the windows-servers (I have only tested smb not
NTFSv4.1).
Best Regards,
Jostein
--
_______________________________________________
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
