On Чцв, 09 сту 2025, Ronald Wimmer via FreeIPA-users wrote:
On 09.01.25 13:17, Alexander Bokovoy via FreeIPA-users wrote:
On Чцв, 09 сту 2025, Ronald Wimmer wrote:
So. Let me summarize this information for me personally. If we
create a new user in the staging area via LDAP with a
clear-text password it is impossible that the user can login
using IPA's WebGUI as it requires Kerberos and the
krbPrincipalKey is not available until an implicit or explicit
LDAP bind is done with this exact user, right?
If you provided IPA-specific LDAP objectclasses (and their required
attributes) when creating via LDAP, then you'll get Kerberos attributes
created automatically and it will not require use of the migration mode.
Basically, it is fully controlled by your side -- if you are able to
extend what is added to LDAP entry template, you can make it working.
Just look at how this entry looks after 'ipa stageuser-add' and model
your LDAP update around it.
But regarding my question... it can't be that we create a user
with a minimal set of attributes and it can login to the WebGUI as
it is missing the krbPrincipalKey (which would be created after an
LDAP bind), right?
Without seeing what is being done to the entries and by whom, it is
impossible to answer. Enable 389-ds audit log, create a stage user via
your mechanism, activate it, and then you'll see all the details in the
audit log, including who (which plugin or client) made what changes.
I do not want to overcomplicate things here. During our PoC phase we
created users via LDAP like we do now. According to your colleague
Christian Heimes an initial LDAP bind was required whenever we had a
clear text password coming from the external system (user creation or
password modification). Why? If I understood it correctly it was
because the password needs to be hashed and the krbPrincipalKey needs
to be (re)generated. Without the proper key a login to the WebUI
should not be possible.
Correct. As I said, it all depends on a way how staging user was
created:
- if initial LDAP ADD contained Kerberos attributes and objectclasses, as
well as initial clear text password, Kerberos keys will be created
right away, no need for initial LDAP BIND once this entry will be
activated
- if initial LDAP ADD did not contain Kerberos attributes and
objectclasses, Kerberos keys will not be created and you would need to
have LDAP BIND once this entry will be activated.
The former is what 'ipa stageuser-add' is doing. The latter is what most
of external LDAP ADDs are doing. However, if you can extend an LDAP
entry template when doing that external LDAP ADD, nothing prevents you
from using a similar set of objectclasses/initial attribute values that
'ipa stageuser-add' is providing.
What we see now is that the krbPrincipalKey is generated without any
interaction (no implicit or explicit LDAP bind from our side).
The only thing we did recently is getting rid of Oracle Linux. We
switched to RHEL (9.5) and implicitly from FreeIPA to RedHat IDM (IPA
VERSION: 4.12.2, API_VERSION: 2.254).
What I would like to understand is why the relevant Kerberos
attributes (like krbPrincipalKey) now seem to be generated on the fly
whereas some time ago an LDAP bind was required to have them
generated.
So far you have not showed how exactly the entry that you added to the
staging area looks like. It doesn't matter who creates it, without
seeing the content of 'ipa stageuser-show foo --all --raw' the rest is
a speculation.
The second remaining question is what behaviour you IPA devs would
expect when IPA is in migration mode. Should the krbPrincipalKey be
generated automatically whenever there is no hashed user password? Or
might it be some kind of erroneous behaviour we see here.
Migration mode affects the way how ipa-pwd-extop plugin handles
pre-generated Kerberos keys during LDAP ADD: in migration mode if we
don't have clear text password but there are present Kerberos principal
keys, they are accepted, assuming they were generated in the staging
area. This is exactly what 'ipa stageuser-activate' does -- it takes the
content of the stage entry and LDAP ADDs it as a normal user, keeping
all attributes that were there.
Of course I can provide logs if what I wrote above here does not ring
a bell immediately on your side.
At least, having actual stage entries after they were created would
help.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-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-users@lists.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
