On 11.01.25 15:29, Alexander Bokovoy via FreeIPA-users wrote:
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.
Sorry. Took some time cause this is done by colleagues in a different department.
A user is created with this LDAP classes and attributes:
dn: uid=testuser,cn=staged users,cn=accounts,cn=provisioning,dc=linux,dc=mydomain,dc=at nsaccountlock: false uid: testuser ou: some department cn: testuser sn: surname givenname: somegivenname objectclass: inetorgperson objectclass: organizationalPerson objectclass: person objectclass: top userpassword: <content suppressed>
When a user is created like this, we see that krbPrincipalKey, karbLastAdminUnlock, krbLastPwdChange, krbPasswordExpiration are created automatically. (this has definitely been different a whila ago)