On Суб, 29 сак 2025, Jostein Fossheim wrote:
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
Good, thanks for the investigation. So the core part is to use explicit
SID in the powershell command. This will use LSA RPC command
lsa_LookupSids to do SID to name transformation which would work for
users and groups. The other way around (user or group name to SID) may
not work, both powershell and UI try to optimize through LDAP queries
instead of lsa_LookupNames3. lsa_LookupNames3 might also fail but this
is our problem in ipasam driver which we didn't fix yet.
It used not to work in past at all. It will not work for host and
service SPNs as we do not allow resolving them via DCE RPCs even for
direct SID to name transformation, except for the services created with
'ipa-client-samba' tool due to IPA services not having SIDs associated
with them by default (to do so, they need POSIX IDs allocated to the
Kerberos services which will be very expensive ID range-wise and
generally is not needed for how Kerberos services are used on IPA side).
As for the foreign security principal behavior, this is actually a known
path. Any SID you explicitly add to a group in the domain, will be
reflected in the FSP subtree. See MS-ADTS 3.1.1.5.2.4 for details:
------------------------------------------------------------------------
If the Add assigns a value to an FPO-enabled attribute (section
3.1.1.5.2.3) of the new object, and the DN value in the add request has
<SID=stringizedSid> format (section 3.1.1.3.1.2.4), then the DC creates
a corresponding foreignSecurityPrincipal object in the
ForeignSecurityPrincipals container (section 6.1.1.4.10) and assigns a
reference to the new foreignSecurityPrincipal object as the FPO-enabled
attribute value. [MS-SAMR] section 3.1.1.8.9 specifies the creation of
the foreignSecurityPrincipal object.
------------------------------------------------------------------------
The problem is that this only works for explicitly assigned
users/groups. If you'd look at a mounted SMB share that has other IPA
users owning files or mentioned in POSIX ACLs, they will not be resolved
properly. Or will be resolved (if lsa_LookupSids request would come to
IPA server) but cannot be assigned through UI because Windows UI to
search for users/groups will not be able to find them: they can only
find users/groups via LDAP in either global catalog or in the specified
domain's LDAP server's subtrees. The latter will fail for IPA as we use
totally different LDAP schema than what Windows expects to be present.
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).
The access should work, yes, as long as AD DCs are able to resolve those
SIDs. I have not seen whether it is possible to make third-party NFS
storages (NetApp, Isilon, etc) to work in such configuration, but this
is more to those companies, not Microsoft.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
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
