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. ;)
As I said before:
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.
Windows implementation is inconsistent with regards to the ways how user
search and resolving is done, for various reasons we can only guess
about.
See, for example, our talk at SambaXP'20:
https://talks.vda.li/talks/2020/sxp20-d2t2-1-bokovoy-blancrenaud-FreeIPA-Catalog.pdf
For fun I also tryed to forcefully change the ipaNTSecurityIdentifier
on an IPA-user to mach ADs, but then my kerberos tickets get recjected
on the local KDC (which seems reasonable):
root@ipa-nas:~# ldapsearch -LLLQ uid=ipauser ipaNTSecurityIdentifier
dn: uid=ipauser,cn=users,cn=compat,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
dn: uid=ipauser,cn=users,cn=compat,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
dn: uid=ipauser,cn=users,cn=accounts,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
ipaNTSecurityIdentifier: S-1-5-21-3335129051-2596296882-561087841-1108
Can this be overridden some how locally, just for eksperimental purposes?
No, it cannot. Attempting to inject a SID from unrelated domain is
considered a security risk and we reject it intentionally.
Mar 28 11:38:50 ipa-nas.ipa-nas.lab.skyfritt.net krb5kdc[1385](info):
closing down fd 11
Mar 28 11:38:50 ipa-nas.ipa-nas.lab.skyfritt.net krb5kdc[1384](Error):
PAC issue: PAC record claims domain SID different to local domain SID
or any trusted domain SID: local
[S-1-5-21-355267255-715991334-1594671509], PAC
[S-1-5-21-3335129051-2596296882-561087841]
Mar 28 11:38:50 ipa-nas.ipa-nas.lab.skyfritt.net krb5kdc[1384](info):
TGS_REQ : handle_authdata (-1765328364)
Mar 28 11:38:50 ipa-nas.ipa-nas.lab.skyfritt.net krb5kdc[1384](info):
TGS_REQ (4 etypes {aes256-cts-hmac-sha384-192(20),
aes128-cts-hmac-sha256-128(19),
I just want to see how the ADs KDC, handles this, if its possible at all.
--
Vennlig Hilsen
Jostein Fossheim
--
/ 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
