6:02 a.m.
Dear all,
I am having a bit of a broad issue, so I am not sure how and where to write, but maybe
someone can point me into the right direction.
I have a usecase where I got some Gemalto eToken 5110 which are quite properitary, but
work with their own libraries in accordance with pam_pkcs11 (not with opensc in any way or
form).
The system this is being worked on is a Debian 12 machine, included into our freeIPA.
The certificates configured on these eTokens have a UPN username / X509v3 Subject
Alternative Name for Windows Login.
The certificates are from another authority and are unknown to our freeIPA - and we cannot
reach the other authority.
To still use them, we included pam_pkcs11 with check for the root CA, signature and CRL,
which all work.
To login the users, I took the pam_pkcs11 with the generic mapper and map the UPN name to
one of our freeIPA usernames, which have been logged into the Debian 12 system
beforehand.
This works very well, meaning that all our eTokens (basically subscribing to the same UPN
username, but still being different certs) are mapped to this one internal user which has
been created on the freeIPA. Thanks to this rework, any member can take his/her eToken and
successfully log into the system.
However, it does not trigger the generation of the Kerberos Ticket for the freeIPA user
that its logged into.
This is the final step I would need for this to work, as this Kerberos Ticket is the key
to all the applications needed to run.
Any idea how I can solve this?
Thanks so much!