Mirroring FreeIPA’s SIDs and MS-pac-tickets in alternative MIT-LDAP setups?

[Jostein Fossheim]

Hello all,

I assume that the developer’s list is the right/best place to ask.

We are helping a customer with a homebuilt MiT-kerberos and openldap based setup, and are considering if we can gently improve this setup, with SID and MS-PACs added to the users/tickets.

Would it be possbile, to add a SID-attribute to the schema and users/hosts in such a setup, and mirror how this is done in freeIPA (or in Samba compiled with MiT)?

I have not tried yet to investegate how this
works/are done/configured in IPA or samba, so I was hoping for some pointers on where to start the investegation.

Is there custom code, to handle this? or is it done via MIT-configuration attributes?

Best Regards,
Jostein Fossheim

[Alexander Bokovoy]

On Няд, 30 сак 2025, Jostein Fossheim via FreeIPA-devel wrote:
> Hello all,
>
> I assume that the developer’s list is the right/best place to ask.
>
> We are helping a customer with a homebuilt MiT-kerberos and openldap
> based setup, and are considering if we can gently improve this setup,
> with SID and MS-PACs added to the users/tickets.
>
> Would it be possbile, to add a SID-attribute to the schema and
> users/hosts in such a setup, and mirror how this is done in freeIPA (or
> in Samba compiled with MiT)?
>
> I have not tried yet to investegate how this works/are done/configured
> in IPA or samba, so I was hoping for some pointers on where to start
> the investegation.
>
> Is there custom code, to handle this? or is it done via
> MIT-configuration attributes?

Standard MIT Kerberos KDB drivers (lmdb, ldap, db2) do not support
generating full PAC for the tickets. MIT Kerberos only generates a
minimal PAC that contains signatures required to prevent forging
attacks (that's why stock drivers generate the PAC structure at all).

In order to have proper PAC issued, aside from the data with an information
that is not typically available in KDB databases, one also needs the
code that could generate complex NDR structures described in MS-PAC /
MS-KILE specifications. Open Source implementation of the code that
generates it is only available in Samba project, under GNU GPLv3. While
it is fine for FreeIPA and Samba AD (both of which are under GNU GPLv3
themselves), it is not something that can be used by default in MIT
Kerberos which has a more permissive license (MIT). MIT Kerberos
actually consumes a number of components with complex licensing
arrangement but making PAC generator a part of it would effectively turn
it licensed it under GNU GPLv3. In past this was not welcomed by the
project.

Last year we made some effort to enable stacking of KDB drivers[1][2].
This theoretically gives us a starting point to enable creation of a KDB
driver that implements issue_pac() independently of the KDB storage
backend, if it would be able to pick up the details required for PAC
generation somewhere else. We aim eventually to have a combined
stackable driver that can be reused across FreeIPA, Samba AD/MIT, and
local KDC work, so that we don't need to maintain multiple versions of
this code all using the same RPC libraries provided by Samba project.
However, this is several years away, at the very least.

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.

[1] see thread at https://mailman.mit.edu/pipermail/krbdev/2024-June/013670.html
[2] https://github.com/krb5/krb5/pull/1396

[Jostein Fossheim]

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.

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?

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?

[Alexander Bokovoy]

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.