On Аўт, 01 кра 2025, Jostein Fossheim wrote:
On 2025-03-31 09:36, Alexander Bokovoy wrote:
Coming back to the original question: no, you currently cannot enable
MIT Kebreros to handle PAC with ldap KDB driver without additional and
non-trivial engineering work.
Thank you for you're response, we might be up for diving into some
non-trivial engineering work. I am not _very_ interested in Posix ->
AD trust, but, the other way AD trust/interoperability -> with
Posix-based systems, lonely windows-island in the environments we are
managing to work, with IPA and our Posix-systems is rather vital for
several setups that we manage. I will investigate how far we can push
the small break through from the discussion in the User's tread deeper
the next couple of days.
It is something that you will have to care about. POSIX attributes are
important to Samba. Samba processes run on Linux system, so they must be
running under a particular POSIX account. This is how Samba handles
ability to run or perform operations on behalf of the users. So if a
user connects from Windows machine after authentication, Windows will
use user's account creds, hopefully Kerberos, to authenticate. On smbd
side we will have to make sure that the authenticated identity can be
represented as POSIX account to allow smbd process to switch under that
identity.
If Windows machine uses their own machine account, this account will not
be mapped to a POSIX user representing that machine. For trust with
Active Directory, AD DCs will use trusted domain object (TDO) account
which we map to a POSIX user on IPA side. Windows domain members may
talk to us directly but typically they delegate through their own domain
controllers, so it typically works.
In the MIT-setup in question the following "kldap"-db-module is loaded:
[dbmodules]
openldap_ldapconf = {
db_library = kldap
And in our internal IPA-based (production and ldap) - setups:
[dbmodules]
LAB.SKYFRITT.NET = {
db_library = ipadb.so
}
are loaded? Do you know if the ipadb.so-module doing actually is doing
all the MS-pac work, or is there other custom changes to MiT involved
as well?
These are completely different KDB drivers. PAC generator is part of the
KDB driver, so it is implemented in ipadb. It is not implemented in
kldap or any other driver in the MIT Kerberos tree.
So either modifying freeipa's plugin, or extending the default
kldap-plugin to deal with SIDs would be the most viable places to
start, I assume this is the relevant code (for each plugin-module):
https://github.com/freeipa/freeipa/tree/master/daemons/ipa-kdb
https://github.com/krb5/krb5/tree/master/src/plugins/kdb/ldap
I will discuss it with my team and ases.
I assume if we where able to make a prototype of a generalized plugin
to work based on FreeIPA-codebase, there will always be a license
conflict as well to deal with? That is, it has to be "standalone"
under GNU GPLv3, and could never merge with the MiT-codebase?
Yes. This is one of reasons we looked at the stackable KDB feature, to
allow creating a KDB driver that provides issue_pac implementation but
otherwise delegates actual principal handling to a lower layer's KDB
implementation. We don't have such implementation yet and we wouldn't
get there soon, as I said.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
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/freeipa-devel@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
