On 2025-03-28 08:42, Alexander Bokovoy wrote:
On Чцв, 27 сак 2025, Jostein Fossheim wrote:
ksetup and mapping will not help with MS-PAC enforcement required now.
hmm... we successfully established trust between ipa and AD, and ipa
is able to resolve users in AD. Can you point me in the right
direvction for how to make /home/DOMAIN/username the home-folder for
AD-users, as demonstrated in the FOSDEM-video?
IPA-realm: IPA-NAS.LAB.SKYFRITT.NET
AD-realm: MAD-NAS.LAB.SKYFRITT.NET
Add ID override for the AD user in the 'Default Trust View' ID view that
states their home directory.
That worked like a charm:
jostein@valkyrie3:~$ ssh -l [email protected]
ipa-nas.ipa-nas.lab.skyfritt.net
([email protected]@ipa-nas.ipa-nas.lab.skyfritt.net)
Password:
Welcome to ipa-nas.ipa-nas.lab.skyfritt.net
Whether you can hear it or not,
The Universe is laughing behind your back.
-- National Lampoon, "Deteriorata"
[email protected]@ipa-nas:~$ pwd
/home/mad-nas.lab.skyfritt.net/maduser
[email protected]@ipa-nas:~$
Newer SSSD (still in development) will have support for having
domain-wide default overrides. This is what that demo showed but it is
not yet in any released FreeIPA or SSSD versions as it is still under
development.
I assumed as much, but you said in the talk, that it was possible today
as well. Thank you. .
But look at this:
root@ipa-nas:/# klist
klist: Credentials cache 'KCM:0' not found
root@ipa-nas:/# smbclient -N --use-kerberos=required -L
'\\mad-nas.mad-nas.lab.skyfritt.net\'
lpcfg_do_global_parameter: WARNING: The "domain logons" option is
deprecated
gensec_spnego_client_negTokenInit_step: Could not find a suitable
mechtype in NEG_TOKEN_INIT
session setup failed: NT_STATUS_INVALID_PARAMETER
root@ipa-nas:/# kinit admin
Password for [email protected]:
root@ipa-nas:/# smbclient -N --use-kerberos=required -L
'\\mad-nas.mad-nas.lab.skyfritt.net\'
lpcfg_do_global_parameter: WARNING: The "domain logons" option is
deprecated
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
E$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Testshare Disk
Z$ Disk Default share
SMB1 disabled -- no workgroup available
root@ipa-nas:/# klist
Ticket cache: KCM:0
Default principal: [email protected]
Valid starting Expires Service principal
27/03/25 13:18:19 28/03/25 12:18:38
krbtgt/[email protected]
27/03/25 13:18:20 27/03/25 23:18:20
cifs/[email protected]
Ticket server:
cifs/[email protected]
root@ipa-nas:/#
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.
ok, it seems that I indeed been able to give ipausers access to a
samba-share on the windows server/ad, by enforcing NTFS-permissions:
First i do a ldap-search in my IPA-directory:
root@ipa-nas:~# ldapsearch -LLLQ uid=admin ipaNTSecurityIdentifier
dn: uid=admin,cn=users,cn=compat,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
dn: uid=admin,cn=users,cn=accounts,dc=ipa-nas,dc=lab,dc=skyfritt,dc=net
ipaNTSecurityIdentifier: S-1-5-21-355267255-715991334-1594671509-500
root@ipa-nas:~#
Then on the windows-server in question, i grant all NTFS-ACLs on to the
given share-folder
C:\>icacls "C:\c-share" /grant
*S-1-5-21-355267255-715991334-1594671509-500:(OI)(CI)(F) /T
Then I test from the IPA-side, first with at "ipauser" with a diffrent SID:
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-355267255-715991334-1594671509-1004
root@ipa-nas:~#
root@ipa-nas:~# kdestroy -A
root@ipa-nas:~# kinit ipauser
Password for [email protected]:
root@ipa-nas:~# smbclient -N --use-kerberos=required
'\\mad-nas.mad-nas.lab.skyfritt.net\c-share'
lpcfg_do_global_parameter: WARNING: The "domain logons" option is deprecated
Try "help" to get a list of possible commands.
smb: \> ls
NT_STATUS_ACCESS_DENIED listing \*
smb: \> mkdir hhhh
NT_STATUS_ACCESS_DENIED making remote directory \hhhh
smb: \> quit
Then I test with the admin-user:
root@ipa-nas:~# kdestroy -A
root@ipa-nas:~# kinit admin
Password for [email protected]:
root@ipa-nas:~# klist -A
Ticket cache: KCM:0
Default principal: [email protected]
Valid starting Expires Service principal
28/03/25 09:35:44 29/03/25 09:22:39
krbtgt/[email protected]
28/03/25 09:35:46 28/03/25 19:35:46
cifs/[email protected]
Ticket server:
cifs/[email protected]
root@ipa-nas:~# smbclient -N --use-kerberos=required
'\\mad-nas.mad-nas.lab.skyfritt.net\c-share'
lpcfg_do_global_parameter: WARNING: The "domain logons" option is deprecated
Try "help" to get a list of possible commands.
smb: \> mkdir new-folder
smb: \> dir
. D 0 Fri Mar 28 09:39:32 2025
.. DHS 0 Thu Mar 27 13:23:31 2025
new-folder D 0 Fri Mar 28 09:39:32 2025
test-folder-from-admin D 0 Fri Mar 28 09:38:38 2025
yyy D 0 Thu Mar 27 14:06:46 2025
zzz D 0 Fri Mar 28 09:26:38 2025
16572415 blocks of size 4096. 12724642 blocks available
smb: \> quit
root@ipa-nas:~#
With ksetup one can add mapping between kerberos-principials and
domain users, like this:
ksetup /mapuser principal@realm domain-user /domain domain-name
What this does is that it add a ldap-attribute to the user, setting :
https://learn.microsoft.com/en-us/windows/win32/ad/security-properties
Setting: altSecurityIdentities
https://learn.microsoft.com/en-us/windows/win32/ADSchema/a-altsecurityidentities
In my windows logs, I still get access denied to files owned by the
AD-user, so something is still not working, but my gut feeling says
that this is a promissing approach. But would need some more
expertice to either dismiss it or make propper adjustments in the
Windows-config. I get no PAC-related errors in my Event Viewer (only
lack of NTFS-prlvleges), but I might not be looking in the right places.
Ask yourself a question: what LDAP user would get that mapping
attribute? AD tools cannot modify anything on IPA side, nor them can
lookup that information in IPA because IPA LDAP tree structure and
schema are unknown to AD.
That `ksetup /mapuser` command maps a domain user to the local machine's
user account. That's all it does. This is even written in their manual
page:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ksetup-mapuser
-----------------------------------------------------------------------
<account>
Specifies any account or security group name that exists on this
computer, such as Guest, Domain Users, or Administrator. If this
parameter is omitted, mapping is deleted for the specified principal.
-----------------------------------------------------------------------
So it is only would be mapping [email protected] to the account in the
local machine's LSA database, not in the AD domain.
Even though you mistakenly might see AD client where you run this
command modifying AD LDAP entry for the 'domain-user' to add
altSecurityIdentities attribute, it does not mean anything for ACLs
evaluation on the specific host. On that host what would happen is this:
I got the "/domain" option from this place:
https://github.com/MicrosoftDocs/windowsserverdocs/blob/main/WindowsServerDocs/administration/windows-commands/ksetup-domain.md
And it does indeed seem to work like I suggest above:
C:\>ksetup /mapuser [email protected] maduser /DOMAIN
MAD-NAS.LAB.SKYFRITT.NET
Connecting to specified domain MAD-NAS.LAB.SKYFRITT.NET...
Using domain MAD-NAS.LAB.SKYFRITT.NET.
Mapping created successfully
C:\>
If i Try to re-run the command i get the following:
C:\>ksetup /mapuser [email protected] maduser /DOMAIN
MAD-NAS.LAB.SKYFRITT.NET
Connecting to specified domain MAD-NAS.LAB.SKYFRITT.NET...
Using domain MAD-NAS.LAB.SKYFRITT.NET.
Failed to set AltSecurityIdentities on
CN=maduser,CN=Users,DC=mad-nas,DC=lab,DC=skyfritt,DC=net; error 0x14.
Failed /MapUser : 0xc0000001
C:\>
And if I do a ldap-search from ipa in the AD-directory, i can indeed see
it set like this:
root@ipa-nas:~# ldapsearch -Y GSS-SPNEGO -LLLQ -H
"ldap://mad-nas.mad-nas.lab.skyfritt.net" -b
"CN=Users,DC=mad-nas,DC=lab,DC=skyfritt,DC=net" cn=maduser
altSecurityIdentities
dn: CN=maduser,CN=Users,DC=mad-nas,DC=lab,DC=skyfritt,DC=net
altSecurityIdentities: KERBEROS:[email protected]
root@ipa-nas:~#
And here it is stated that:
"Contains mappings for X.509 certificates or external Kerberos user
accounts to this user for the purpose of authentication."
https://learn.microsoft.com/en-us/windows/win32/ADSchema/a-altsecurityidentities
- you'd authenticate with Kerberos as IPA principal
- Windows would map that authenticated principal to 'domain-user'
locally and keep the same set of membership RIDs from the PAC of the
Kerberos ticket issued by IPA KDC originally as part of that session's
security token. That set will not include any AD group, as we have no
way to do so.
- When a process on Windows running under this authenticated session
would attempt to access files on NTFS, it would look at this local
user identity and RIDs from the security token. None of them would
match for AD domain access.
Whatever is added to AD LDAP user entry as altSecurityIdentities will
only be consumed by Active Directory domain controller when it issues
the initial TGT for AD user during authentication of that user's
account. It is not used for anything else.
This is explicitly stated in the definition of this attribute in
[MS-ADA1]
section 2.61:
----------------------
This attribute specifies a given user mapping for [X509] certificates or
external Kerberos user accounts for the purpose of authentication.
----------------------
Authentication != authorization.
Again, as it is used for certificate authentication, this is covered in
[MS-PKCA] 3.1.5.2.15.
Once you have authenticated the account, a security token for the
session is created and the account information is never looked up
anymore for the purpose of authorization. It may be looked up for the
purpose of visualization and here Windows have inconsistence it the
behavior because it might use both DCE RPC and LDAP queries, depending
on a tool and a context the tool is used for.
I assume you are right ofcourse, but I still find it somewhat strange
and irritating that it cannot be overridden.
Thank you for all the feedback, by the way, and for all the good work
with IPA, i really love what you are doing with it.
And I will start play around with your ansible and podman containers, to
test ipa-to-ipa trust.
--
Best Regards,
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
