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.
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.
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.
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:
- 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.
--
/ 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
