On 08.01.24 17:58, Alexander Bokovoy wrote:
On Пан, 08 сту 2024, Ronald Wimmer wrote:
On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
On 02.01.24 16:27, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 14.12.23 14:42, Alexander Bokovoy wrote:
On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: > In our company we do have an IAM tool for user management. We > need to > create IPA users via this particular tool. I am aware of all IPA > commands or API calls to create/modify or delete a user. > > As the tool does not support FreeIPA yet they asked if there is a > way > to manage users by using LDAP only. Could that work? What about > attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?
Learn about lifecycle management. This is your way of integrating with such tools bvy creating staged users: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm...
I followed the instructions from the documentation.
How could I possibly overcome
Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: ipa: ERROR: Constraint violation: pre-hashed passwords are not valid
I need to set passwords from the external system.
You need to enable migration mode (ipa config-mod --enable-migration true).
By default a pre-hashed password can only be set once: during the user add operation.
Ok. So this would not work for a password change. So if we need to set an initial password and change that particular password in some point in time the only feasible way is the IPA API, right?
Can the immediate password expiration be overridden?
As we have an upcoming please allow me to ask if I got the point here.
I appreciate your support in this matter!
I was looking over the code. The only way to accept pre-hashed passwords is when they also have Kerberos keys set. This means you cannot use external LDAP modify/add for that as you cannot create the Kerberos key without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is either a cn=Directory Manager or a one from the passsync managers, it would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP browser and chose "plaintext" the value gets hashed immediately. I do see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipatest.mydomain.at Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: True Certificate Subject base: O=IPATEST.MYDOMAIN.AT Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA CA servers: tipa01.ipatest.mydomain.at IPA CA renewal master: tipa01.ipatest.mydomain.at Domain resolution order: org.mydomain.at:ipatest.mydomain.at [root@tipa01 ~]# ipa config-mod --enable-migration=false ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS
Ronald Wimmer via FreeIPA-users wrote:
On 08.01.24 17:58, Alexander Bokovoy wrote:
On Пан, 08 сту 2024, Ronald Wimmer wrote:
On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
On 02.01.24 16:27, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 14.12.23 14:42, Alexander Bokovoy wrote: > On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: >> In our company we do have an IAM tool for user management. We >> need to >> create IPA users via this particular tool. I am aware of all IPA >> commands or API calls to create/modify or delete a user. >> >> As the tool does not support FreeIPA yet they asked if there is >> a way >> to manage users by using LDAP only. Could that work? What about >> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber? > > Learn about lifecycle management. This is your way of integrating > with > such tools bvy creating staged users: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm... > >
I followed the instructions from the documentation.
How could I possibly overcome
Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: ipa: ERROR: Constraint violation: pre-hashed passwords are not valid
I need to set passwords from the external system.
You need to enable migration mode (ipa config-mod --enable-migration true).
By default a pre-hashed password can only be set once: during the user add operation.
Ok. So this would not work for a password change. So if we need to set an initial password and change that particular password in some point in time the only feasible way is the IPA API, right?
Can the immediate password expiration be overridden?
As we have an upcoming please allow me to ask if I got the point here.
I appreciate your support in this matter!
I was looking over the code. The only way to accept pre-hashed passwords is when they also have Kerberos keys set. This means you cannot use external LDAP modify/add for that as you cannot create the Kerberos key without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is either a cn=Directory Manager or a one from the passsync managers, it would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP browser and chose "plaintext" the value gets hashed immediately. I do see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
IPA does not store passwords in the clear.
I tried to enable migration mode and wanted to try it again but now I cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipatest.mydomain.at Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: True Certificate Subject base: O=IPATEST.MYDOMAIN.AT Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA CA servers: tipa01.ipatest.mydomain.at IPA CA renewal master: tipa01.ipatest.mydomain.at Domain resolution order: org.mydomain.at:ipatest.mydomain.at [root@tipa01 ~]# ipa config-mod --enable-migration=false ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS
As who? The user with the reset password? Did you look in the krb5 log for a denial reason?
rob
On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:
On 08.01.24 17:58, Alexander Bokovoy wrote:
On Пан, 08 сту 2024, Ronald Wimmer wrote:
On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
On 02.01.24 16:27, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 14.12.23 14:42, Alexander Bokovoy wrote: > On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: >> In our company we do have an IAM tool for user management. We >> need to >> create IPA users via this particular tool. I am aware of all IPA >> commands or API calls to create/modify or delete a user. >> >> As the tool does not support FreeIPA yet they asked if there is >> a way >> to manage users by using LDAP only. Could that work? What about >> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber? > > Learn about lifecycle management. This is your way of integrating > with > such tools bvy creating staged users: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm... >
I followed the instructions from the documentation.
How could I possibly overcome
Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: ipa: ERROR: Constraint violation: pre-hashed passwords are not valid
I need to set passwords from the external system.
You need to enable migration mode (ipa config-mod --enable-migration true).
By default a pre-hashed password can only be set once: during the user add operation.
Ok. So this would not work for a password change. So if we need to set an initial password and change that particular password in some point in time the only feasible way is the IPA API, right?
Can the immediate password expiration be overridden?
As we have an upcoming please allow me to ask if I got the point here.
I appreciate your support in this matter!
I was looking over the code. The only way to accept pre-hashed passwords is when they also have Kerberos keys set. This means you cannot use external LDAP modify/add for that as you cannot create the Kerberos key without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is either a cn=Directory Manager or a one from the passsync managers, it would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP browser and chose "plaintext" the value gets hashed immediately. I do see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipatest.mydomain.at Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: True Certificate Subject base: O=IPATEST.MYDOMAIN.AT Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA CA servers: tipa01.ipatest.mydomain.at IPA CA renewal master: tipa01.ipatest.mydomain.at Domain resolution order: org.mydomain.at:ipatest.mydomain.at [root@tipa01 ~]# ipa config-mod --enable-migration=false ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS
I should have done a little debugging instead of asking again. dirsrv was not running after ipa config-mod --enable-migration=true
OK. Let me summarize... The whole procedure (creating a user in the staging area if the password is a cleartext one) works if migration mode is enabled. What drawbacks arise if migration mode is enabled all the time?
Cheers, Ronald
Ronald Wimmer via FreeIPA-users wrote:
On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:
On 08.01.24 17:58, Alexander Bokovoy wrote:
On Пан, 08 сту 2024, Ronald Wimmer wrote:
On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
On 02.01.24 16:27, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote: > > > On 14.12.23 14:42, Alexander Bokovoy wrote: >> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: >>> In our company we do have an IAM tool for user management. We >>> need to >>> create IPA users via this particular tool. I am aware of all IPA >>> commands or API calls to create/modify or delete a user. >>> >>> As the tool does not support FreeIPA yet they asked if there is >>> a way >>> to manage users by using LDAP only. Could that work? What about >>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber? >> >> Learn about lifecycle management. This is your way of >> integrating with >> such tools bvy creating staged users: >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm... >> >> > > I followed the instructions from the documentation. > > How could I possibly overcome > > Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: > ipa: ERROR: Constraint violation: pre-hashed passwords are not valid > > I need to set passwords from the external system.
You need to enable migration mode (ipa config-mod --enable-migration true).
By default a pre-hashed password can only be set once: during the user add operation.
Ok. So this would not work for a password change. So if we need to set an initial password and change that particular password in some point in time the only feasible way is the IPA API, right?
Can the immediate password expiration be overridden?
As we have an upcoming please allow me to ask if I got the point here.
I appreciate your support in this matter!
I was looking over the code. The only way to accept pre-hashed passwords is when they also have Kerberos keys set. This means you cannot use external LDAP modify/add for that as you cannot create the Kerberos key without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is either a cn=Directory Manager or a one from the passsync managers, it would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP browser and chose "plaintext" the value gets hashed immediately. I do see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipatest.mydomain.at Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: True Certificate Subject base: O=IPATEST.MYDOMAIN.AT Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA CA servers: tipa01.ipatest.mydomain.at IPA CA renewal master: tipa01.ipatest.mydomain.at Domain resolution order: org.mydomain.at:ipatest.mydomain.at [root@tipa01 ~]# ipa config-mod --enable-migration=false ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS
I should have done a little debugging instead of asking again. dirsrv was not running after ipa config-mod --enable-migration=true
OK. Let me summarize... The whole procedure (creating a user in the staging area if the password is a cleartext one) works if migration mode is enabled. What drawbacks arise if migration mode is enabled all the time?
It is extra work whenever a user is unauthorized and has provided a password because it will try to authenticate with both Kerberos and LDAP in an attempt to migrate it.
rob
On 25.01.24 19:52, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:
On 08.01.24 17:58, Alexander Bokovoy wrote:
On Пан, 08 сту 2024, Ronald Wimmer wrote:
On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote:
On 02.01.24 16:27, Rob Crittenden wrote: > Ronald Wimmer via FreeIPA-users wrote: >> >> >> On 14.12.23 14:42, Alexander Bokovoy wrote: >>> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: >>>> In our company we do have an IAM tool for user management. We >>>> need to >>>> create IPA users via this particular tool. I am aware of all IPA >>>> commands or API calls to create/modify or delete a user. >>>> >>>> As the tool does not support FreeIPA yet they asked if there is >>>> a way >>>> to manage users by using LDAP only. Could that work? What about >>>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber? >>> >>> Learn about lifecycle management. This is your way of >>> integrating with >>> such tools bvy creating staged users: >>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm... >>> >>> >> >> I followed the instructions from the documentation. >> >> How could I possibly overcome >> >> Dec 19 09:18:39 tipa01.ipatest.mydomain.at ipa-activate-all[836863]: >> ipa: ERROR: Constraint violation: pre-hashed passwords are not valid >> >> I need to set passwords from the external system. > > You need to enable migration mode (ipa config-mod > --enable-migration true). > > By default a pre-hashed password can only be set once: during the > user > add operation.
Ok. So this would not work for a password change. So if we need to set an initial password and change that particular password in some point in time the only feasible way is the IPA API, right?
Can the immediate password expiration be overridden?
As we have an upcoming please allow me to ask if I got the point here.
I appreciate your support in this matter!
I was looking over the code. The only way to accept pre-hashed passwords is when they also have Kerberos keys set. This means you cannot use external LDAP modify/add for that as you cannot create the Kerberos key without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is either a cn=Directory Manager or a one from the passsync managers, it would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP browser and chose "plaintext" the value gets hashed immediately. I do see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipatest.mydomain.at Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: True Certificate Subject base: O=IPATEST.MYDOMAIN.AT Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA CA servers: tipa01.ipatest.mydomain.at IPA CA renewal master: tipa01.ipatest.mydomain.at Domain resolution order: org.mydomain.at:ipatest.mydomain.at [root@tipa01 ~]# ipa config-mod --enable-migration=false ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS
I should have done a little debugging instead of asking again. dirsrv was not running after ipa config-mod --enable-migration=true
OK. Let me summarize... The whole procedure (creating a user in the staging area if the password is a cleartext one) works if migration mode is enabled. What drawbacks arise if migration mode is enabled all the time?
It is extra work whenever a user is unauthorized and has provided a password because it will try to authenticate with both Kerberos and LDAP in an attempt to migrate it.
When I add a new IPA user as described above it gets created in the staging area and automaticalle moved to the correct users DN. (as described here https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/htm... )
However, the given (plaintext) password does not work. I do get an error upon login saying "The password or username you entered is incorrect". Why?
Remark: If I set a new password for this particular user after the user has been activated, it works.
Cheers, Ronald
On 02.02.24 09:48, Ronald Wimmer via FreeIPA-users wrote:
On 25.01.24 19:52, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 25.01.24 15:27, Ronald Wimmer via FreeIPA-users wrote:
On 08.01.24 17:58, Alexander Bokovoy wrote:
On Пан, 08 сту 2024, Ronald Wimmer wrote:
On 02.01.24 17:57, Ronald Wimmer via FreeIPA-users wrote: > On 02.01.24 16:27, Rob Crittenden wrote: >> Ronald Wimmer via FreeIPA-users wrote: >>> >>> >>> On 14.12.23 14:42, Alexander Bokovoy wrote: >>>> On Чцв, 14 сне 2023, Ronald Wimmer via FreeIPA-users wrote: >>>>> In our company we do have an IAM tool for user management. We >>>>> need to >>>>> create IPA users via this particular tool. I am aware of all IPA >>>>> commands or API calls to create/modify or delete a user. >>>>> >>>>> As the tool does not support FreeIPA yet they asked if there is >>>>> a way >>>>> to manage users by using LDAP only. Could that work? What about >>>>> attributes like ipaNTSecurityIdentifier, ipaUniqueID or >>>>> uidNumber? >>>> >>>> Learn about lifecycle management. This is your way of >>>> integrating with >>>> such tools bvy creating staged users: >>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/htm... >>>> >>>> >>> >>> I followed the instructions from the documentation. >>> >>> How could I possibly overcome >>> >>> Dec 19 09:18:39 tipa01.ipatest.mydomain.at >>> ipa-activate-all[836863]: >>> ipa: ERROR: Constraint violation: pre-hashed passwords are not >>> valid >>> >>> I need to set passwords from the external system. >> >> You need to enable migration mode (ipa config-mod >> --enable-migration true). >> >> By default a pre-hashed password can only be set once: during the >> user >> add operation. > > Ok. So this would not work for a password change. So if we need to > set an initial password and change that particular password in some > point in time the only feasible way is the IPA API, right? > > Can the immediate password expiration be overridden?
As we have an upcoming please allow me to ask if I got the point here.
I appreciate your support in this matter!
I was looking over the code. The only way to accept pre-hashed passwords is when they also have Kerberos keys set. This means you cannot use external LDAP modify/add for that as you cannot create the Kerberos key without knowing a Kerberos master key.
So the only other option is to submit a clear-text password:
userPassword: {CLEAR}text-password
That will be accepted and if bind DN that performed this change is either a cn=Directory Manager or a one from the passsync managers, it would also not be marked for expiration immediately.
If I try to set the userPassword attribute to some value with an LDAP browser and chose "plaintext" the value gets hashed immediately. I do see {PBKDF2_SHA256}. As a consequence the user cannot be activated.
What am I doing wrong?
I tried to enable migration mode and wanted to try it again but now I cannot connect to IPA's LDAP directory at all anymore...
[root@tipa01 ~]# ipa config-mod --enable-migration=true Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: ipatest.mydomain.at Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: True Certificate Subject base: O=IPATEST.MYDOMAIN.AT Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA master capable of PKINIT: tipa01.ipatest.mydomain.at, tipa02.ipatest.mydomain.at IPA CA servers: tipa01.ipatest.mydomain.at IPA CA renewal master: tipa01.ipatest.mydomain.at Domain resolution order: org.mydomain.at:ipatest.mydomain.at [root@tipa01 ~]# ipa config-mod --enable-migration=false ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638972): KDC returned error string: PROCESS_TGS
I should have done a little debugging instead of asking again. dirsrv was not running after ipa config-mod --enable-migration=true
OK. Let me summarize... The whole procedure (creating a user in the staging area if the password is a cleartext one) works if migration mode is enabled. What drawbacks arise if migration mode is enabled all the time?
It is extra work whenever a user is unauthorized and has provided a password because it will try to authenticate with both Kerberos and LDAP in an attempt to migrate it.
When I add a new IPA user as described above it gets created in the staging area and automaticalle moved to the correct users DN. (as described here https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/8/htm... )
However, the given (plaintext) password does not work. I do get an error upon login saying "The password or username you entered is incorrect". Why?
Remark: If I set a new password for this particular user after the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Cheers, Ronald
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
Cheers, Ronald
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
While writing the lines above another question came up in my mind: Is there a way to forbid password modification for IPA users so that users are forced to do that in an external sytem?
Cheers, Ronald
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
Remark: If I set a new password for this particular user after the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
While writing the lines above another question came up in my mind: Is there a way to forbid password modification for IPA users so that users are forced to do that in an external sytem?
Yes, that's easy, remove the self service permission "Self can write own password".
On 12/02/2024 14.15, Christian Heimes wrote:
While writing the lines above another question came up in my mind: Is there a way to forbid password modification for IPA users so that users are forced to do that in an external sytem?
Yes, that's easy, remove the self service permission "Self can write own password".
Actually, it's not *that* trivial. Alexander just pointed out to me, that this will break service and host accounts requesting their own keytab. Ops!
You may be able to archive the desired effect by replacing the ACI with a different self-service ACI that permits self-write for everybody except externally managed user accounts. Perhaps you can add your external users to a non-POSIX group and add a filter like
(targetfilter = "(memberOf!=cn=external-passwords,cn=groups,cn=accounts,$SUFFIX)")
to the self-service ACI.
Christian
On 12.02.24 14:36, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 14.15, Christian Heimes wrote:
While writing the lines above another question came up in my mind: Is there a way to forbid password modification for IPA users so that users are forced to do that in an external sytem?
Yes, that's easy, remove the self service permission "Self can write own password".
Actually, it's not *that* trivial. Alexander just pointed out to me, that this will break service and host accounts requesting their own keytab. Ops!
You may be able to archive the desired effect by replacing the ACI with a different self-service ACI that permits self-write for everybody except externally managed user accounts. Perhaps you can add your external users to a non-POSIX group and add a filter like
(targetfilter = "(memberOf!=cn=external-passwords,cn=groups,cn=accounts,$SUFFIX)")
to the self-service ACI.
That's a great idea. Thanks for that!
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote:
> Remark: If I set a new password for this particular user after > the user has been activated, it works.
We are still facing this particular problem and do not have any clue why the initial password set by the external system does not work. Any ideas/hints here?
Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote:
On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >> Remark: If I set a new password for this particular user after >> the user has been activated, it works. > > We are still facing this particular problem and do not have any > clue why the initial password set by the external system does not > work. Any ideas/hints here? Two ideas:
Are you supplying pre-hashed passwords in the correct format? 389-DS expects hashed passwords in a specific format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and 100,000 iterations.
IPA cannot create Kerberos keys from a pre-hashed passwords. Kerberos does not work until the user's Kerberos key is generated from a plain password, e.g. with a password change at https://yourserver/ipa/migration/. SSSD can also detect the case and generate Kerberos keys.
When you log into LDAP as "cn=Directory Manager", then you can read and check the "userPassword" and "krbPrincipalKey" entries.
Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 12:38, Christian via FreeIPA-users wrote: >On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>Remark: If I set a new password for this particular >>>user after the user has been activated, it works. >> >>We are still facing this particular problem and do not >>have any clue why the initial password set by the >>external system does not work. Any ideas/hints here? >Two ideas: > >Are you supplying pre-hashed passwords in the correct >format? 389-DS expects hashed passwords in a specific >format, e.g. "{PBKDF2-SHA512}100000$base64data" for PKBDF2 >with SHA-512 and 100,000 iterations. > >IPA cannot create Kerberos keys from a pre-hashed >passwords. Kerberos does not work until the user's >Kerberos key is generated from a plain password, e.g. with >a password change at https://yourserver/ipa/migration/. >SSSD can also detect the case and generate Kerberos keys. > >When you log into LDAP as "cn=Directory Manager", then you >can read and check the "userPassword" and >"krbPrincipalKey" entries. > >Christian
We are providing plaintext passwords. When the user is initially created in the staging area the password does not seem to work. When the user is activated and thus moved to the right place in the LDAP tree we can set a different password that works immediately.
In both cases an LDAP browser reveals that the password gets hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry.
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote: > On 12.02.24 12:38, Christian via FreeIPA-users wrote: >> On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>> Remark: If I set a new password for this particular user after >>>> the user has been activated, it works. >>> >>> We are still facing this particular problem and do not have any >>> clue why the initial password set by the external system does >>> not work. Any ideas/hints here? >> Two ideas: >> >> Are you supplying pre-hashed passwords in the correct format? >> 389-DS expects hashed passwords in a specific format, e.g. >> "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and >> 100,000 iterations. >> >> IPA cannot create Kerberos keys from a pre-hashed passwords. >> Kerberos does not work until the user's Kerberos key is >> generated from a plain password, e.g. with a password change at >> https://yourserver/ipa/migration/. SSSD can also detect the case >> and generate Kerberos keys. >> >> When you log into LDAP as "cn=Directory Manager", then you can >> read and check the "userPassword" and "krbPrincipalKey" entries. >> >> Christian > > We are providing plaintext passwords. When the user is initially > created in the staging area the password does not seem to work. > When the user is activated and thus moved to the right place in > the LDAP tree we can set a different password that works > immediately. > > In both cases an LDAP browser reveals that the password gets > hashed immediately by 389DS. (PBKDF2_SHA256)
This works for me: $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first test --last user testuser
This creates a staging user, sets their password to "MyPass1234", and marks the password as expired. IPA always marks passwords as expired when they are touched by a different user. They are ways to work around the limitation (passSyncManagersDNs / PassSync Service)
$ ipa stageuser-activate testuser
Now "testuser" can ssh into the machine and is forced the reset their password.
By the way, you do not need migration mode if you are providing cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the user from staging. Even after minutes. When I use this particular user for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and krbPrincipalKey are added almost immediately.
Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote: > On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote: >> On 12.02.24 12:38, Christian via FreeIPA-users wrote: >>> On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>>> Remark: If I set a new password for this particular user >>>>> after the user has been activated, it works. >>>> >>>> We are still facing this particular problem and do not have >>>> any clue why the initial password set by the external system >>>> does not work. Any ideas/hints here? >>> Two ideas: >>> >>> Are you supplying pre-hashed passwords in the correct format? >>> 389-DS expects hashed passwords in a specific format, e.g. >>> "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and >>> 100,000 iterations. >>> >>> IPA cannot create Kerberos keys from a pre-hashed passwords. >>> Kerberos does not work until the user's Kerberos key is >>> generated from a plain password, e.g. with a password change at >>> https://yourserver/ipa/migration/. SSSD can also detect the >>> case and generate Kerberos keys. >>> >>> When you log into LDAP as "cn=Directory Manager", then you can >>> read and check the "userPassword" and "krbPrincipalKey" entries. >>> >>> Christian >> >> We are providing plaintext passwords. When the user is initially >> created in the staging area the password does not seem to work. >> When the user is activated and thus moved to the right place in >> the LDAP tree we can set a different password that works >> immediately. >> >> In both cases an LDAP browser reveals that the password gets >> hashed immediately by 389DS. (PBKDF2_SHA256) > > This works for me: > $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first > test --last user testuser > > This creates a staging user, sets their password to "MyPass1234", > and marks the password as expired. IPA always marks passwords as > expired when they are touched by a different user. They are ways > to work around the limitation (passSyncManagersDNs / PassSync > Service) > > $ ipa stageuser-activate testuser > > Now "testuser" can ssh into the machine and is forced the reset > their password. > > By the way, you do not need migration mode if you are providing > cleartext passwords to LDAP.
OK. I see. It might be an expiration issue. But if it was I should run into the same issue when modifying a user's password (over LDAP) later on.
Maybe Flo, Rob or Alexander could clarify what to expect in which scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the user from staging. Even after minutes. When I use this particular user for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and krbPrincipalKey are added almost immediately. --
This is SSSD "migrating" the password. If migration mode is enabled and SSSD can't get a Kerberos ticket it will do an LDAP bind instead which will cause the Kerberos keys to be generated.
The WebUI only uses Kerberos. You'd have to use the password migration page to set the keys.
rob
On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote:
On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote: > On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote: >> On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote: >>> On 12.02.24 12:38, Christian via FreeIPA-users wrote: >>>> On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>>>> Remark: If I set a new password for this particular user >>>>>> after the user has been activated, it works. >>>>> >>>>> We are still facing this particular problem and do not have >>>>> any clue why the initial password set by the external system >>>>> does not work. Any ideas/hints here? >>>> Two ideas: >>>> >>>> Are you supplying pre-hashed passwords in the correct format? >>>> 389-DS expects hashed passwords in a specific format, e.g. >>>> "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and >>>> 100,000 iterations. >>>> >>>> IPA cannot create Kerberos keys from a pre-hashed passwords. >>>> Kerberos does not work until the user's Kerberos key is >>>> generated from a plain password, e.g. with a password change at >>>> https://yourserver/ipa/migration/. SSSD can also detect the >>>> case and generate Kerberos keys. >>>> >>>> When you log into LDAP as "cn=Directory Manager", then you can >>>> read and check the "userPassword" and "krbPrincipalKey" entries. >>>> >>>> Christian >>> >>> We are providing plaintext passwords. When the user is initially >>> created in the staging area the password does not seem to work. >>> When the user is activated and thus moved to the right place in >>> the LDAP tree we can set a different password that works >>> immediately. >>> >>> In both cases an LDAP browser reveals that the password gets >>> hashed immediately by 389DS. (PBKDF2_SHA256) >> >> This works for me: >> $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first >> test --last user testuser >> >> This creates a staging user, sets their password to "MyPass1234", >> and marks the password as expired. IPA always marks passwords as >> expired when they are touched by a different user. They are ways >> to work around the limitation (passSyncManagersDNs / PassSync >> Service) >> >> $ ipa stageuser-activate testuser >> >> Now "testuser" can ssh into the machine and is forced the reset >> their password. >> >> By the way, you do not need migration mode if you are providing >> cleartext passwords to LDAP. > > OK. I see. It might be an expiration issue. But if it was I should > run into the same issue when modifying a user's password (over > LDAP) later on. > > Maybe Flo, Rob or Alexander could clarify what to expect in which > scenario and how to disable immediate expiration if necessary?
The password expiration is controlled by ipa_pwd_extop plugin. To disable password expiration, add the user DN of your service account to the "passSyncManagersDNs" attribute of cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the user from staging. Even after minutes. When I use this particular user for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and krbPrincipalKey are added almost immediately. --
This is SSSD "migrating" the password. If migration mode is enabled and SSSD can't get a Kerberos ticket it will do an LDAP bind instead which will cause the Kerberos keys to be generated.
The WebUI only uses Kerberos. You'd have to use the password migration page to set the keys.
Perfect. I can confirm that all required LDAP properties appear after I do an LDAP bind manually.
Cheers, Ronald
On 13.02.24 07:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote: > On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote: >> On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote: >>> On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote: >>>> On 12.02.24 12:38, Christian via FreeIPA-users wrote: >>>>> On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>>>>> Remark: If I set a new password for this particular user >>>>>>> after the user has been activated, it works. >>>>>> >>>>>> We are still facing this particular problem and do not have >>>>>> any clue why the initial password set by the external system >>>>>> does not work. Any ideas/hints here? >>>>> Two ideas: >>>>> >>>>> Are you supplying pre-hashed passwords in the correct format? >>>>> 389-DS expects hashed passwords in a specific format, e.g. >>>>> "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and >>>>> 100,000 iterations. >>>>> >>>>> IPA cannot create Kerberos keys from a pre-hashed passwords. >>>>> Kerberos does not work until the user's Kerberos key is >>>>> generated from a plain password, e.g. with a password change at >>>>> https://yourserver/ipa/migration/. SSSD can also detect the >>>>> case and generate Kerberos keys. >>>>> >>>>> When you log into LDAP as "cn=Directory Manager", then you can >>>>> read and check the "userPassword" and "krbPrincipalKey" entries. >>>>> >>>>> Christian >>>> >>>> We are providing plaintext passwords. When the user is initially >>>> created in the staging area the password does not seem to work. >>>> When the user is activated and thus moved to the right place in >>>> the LDAP tree we can set a different password that works >>>> immediately. >>>> >>>> In both cases an LDAP browser reveals that the password gets >>>> hashed immediately by 389DS. (PBKDF2_SHA256) >>> >>> This works for me: >>> $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first >>> test --last user testuser >>> >>> This creates a staging user, sets their password to "MyPass1234", >>> and marks the password as expired. IPA always marks passwords as >>> expired when they are touched by a different user. They are ways >>> to work around the limitation (passSyncManagersDNs / PassSync >>> Service) >>> >>> $ ipa stageuser-activate testuser >>> >>> Now "testuser" can ssh into the machine and is forced the reset >>> their password. >>> >>> By the way, you do not need migration mode if you are providing >>> cleartext passwords to LDAP. >> >> OK. I see. It might be an expiration issue. But if it was I should >> run into the same issue when modifying a user's password (over >> LDAP) later on. >> >> Maybe Flo, Rob or Alexander could clarify what to expect in which >> scenario and how to disable immediate expiration if necessary? > > The password expiration is controlled by ipa_pwd_extop plugin. To > disable password expiration, add the user DN of your service > account to the "passSyncManagersDNs" attribute of > cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the > setting to all your servers manually.
I found out that the password is working perfectly fine when ssh-ing to an IPA machine. Also su works. But trying to logon to the WebUI does not. I do get "The password or username you entered is incorrect". Might be related to the fact that the user does not have any kerberos specific LDAP attributes(apart from krbCanonicalName and krbPrincipalName) after initial creation from the external system.
As the password is set in plaintext from the external system there should be a possibility for IPA to generate Kerberos keys etc. What could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the user from staging. Even after minutes. When I use this particular user for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and krbPrincipalKey are added almost immediately. --
This is SSSD "migrating" the password. If migration mode is enabled and SSSD can't get a Kerberos ticket it will do an LDAP bind instead which will cause the Kerberos keys to be generated.
The WebUI only uses Kerberos. You'd have to use the password migration page to set the keys.
Perfect. I can confirm that all required LDAP properties appear after I do an LDAP bind manually.
What would probably be the best way to do this in an automated way? What would you suggest?
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 07:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote: > On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote: >> On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote: >>> On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote: >>>> On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote: >>>>> On 12.02.24 12:38, Christian via FreeIPA-users wrote: >>>>>> On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>>>>>> Remark: If I set a new password for this particular user >>>>>>>> after the user has been activated, it works. >>>>>>> >>>>>>> We are still facing this particular problem and do not have >>>>>>> any clue why the initial password set by the external system >>>>>>> does not work. Any ideas/hints here? >>>>>> Two ideas: >>>>>> >>>>>> Are you supplying pre-hashed passwords in the correct format? >>>>>> 389-DS expects hashed passwords in a specific format, e.g. >>>>>> "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and >>>>>> 100,000 iterations. >>>>>> >>>>>> IPA cannot create Kerberos keys from a pre-hashed passwords. >>>>>> Kerberos does not work until the user's Kerberos key is >>>>>> generated from a plain password, e.g. with a password change at >>>>>> https://yourserver/ipa/migration/. SSSD can also detect the >>>>>> case and generate Kerberos keys. >>>>>> >>>>>> When you log into LDAP as "cn=Directory Manager", then you can >>>>>> read and check the "userPassword" and "krbPrincipalKey" >>>>>> entries. >>>>>> >>>>>> Christian >>>>> >>>>> We are providing plaintext passwords. When the user is initially >>>>> created in the staging area the password does not seem to work. >>>>> When the user is activated and thus moved to the right place in >>>>> the LDAP tree we can set a different password that works >>>>> immediately. >>>>> >>>>> In both cases an LDAP browser reveals that the password gets >>>>> hashed immediately by 389DS. (PBKDF2_SHA256) >>>> >>>> This works for me: >>>> $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first >>>> test --last user testuser >>>> >>>> This creates a staging user, sets their password to "MyPass1234", >>>> and marks the password as expired. IPA always marks passwords as >>>> expired when they are touched by a different user. They are ways >>>> to work around the limitation (passSyncManagersDNs / PassSync >>>> Service) >>>> >>>> $ ipa stageuser-activate testuser >>>> >>>> Now "testuser" can ssh into the machine and is forced the reset >>>> their password. >>>> >>>> By the way, you do not need migration mode if you are providing >>>> cleartext passwords to LDAP. >>> >>> OK. I see. It might be an expiration issue. But if it was I should >>> run into the same issue when modifying a user's password (over >>> LDAP) later on. >>> >>> Maybe Flo, Rob or Alexander could clarify what to expect in which >>> scenario and how to disable immediate expiration if necessary? >> >> The password expiration is controlled by ipa_pwd_extop plugin. To >> disable password expiration, add the user DN of your service >> account to the "passSyncManagersDNs" attribute of >> cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the >> setting to all your servers manually. > > I found out that the password is working perfectly fine when ssh-ing > to an IPA machine. Also su works. But trying to logon to the WebUI > does not. I do get "The password or username you entered is > incorrect". Might be related to the fact that the user does not have > any kerberos specific LDAP attributes(apart from krbCanonicalName > and krbPrincipalName) after initial creation from the external > system. > > As the password is set in plaintext from the external system there > should be a possibility for IPA to generate Kerberos keys etc. What > could I try?
It looks like IPA generates missing attributes after some time. When I tried to login to the WebUI just seconds ago it worked. Can the generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the user from staging. Even after minutes. When I use this particular user for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and krbPrincipalKey are added almost immediately. --
This is SSSD "migrating" the password. If migration mode is enabled and SSSD can't get a Kerberos ticket it will do an LDAP bind instead which will cause the Kerberos keys to be generated.
The WebUI only uses Kerberos. You'd have to use the password migration page to set the keys.
Perfect. I can confirm that all required LDAP properties appear after I do an LDAP bind manually.
What would probably be the best way to do this in an automated way? What would you suggest?
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
rob
On 13.02.24 17:47, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 07:54, Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 23:02, Rob Crittenden via FreeIPA-users wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 12.02.24 20:47, Alexander Bokovoy via FreeIPA-users wrote:
On Пан, 12 лют 2024, Ronald Wimmer via FreeIPA-users wrote: > On 12.02.24 15:54, Ronald Wimmer via FreeIPA-users wrote: >> On 12.02.24 14:15, Christian Heimes via FreeIPA-users wrote: >>> On 12/02/2024 13.32, Ronald Wimmer via FreeIPA-users wrote: >>>> On 12.02.24 13:23, Christian Heimes via FreeIPA-users wrote: >>>>> On 12/02/2024 12.47, Ronald Wimmer via FreeIPA-users wrote: >>>>>> On 12.02.24 12:38, Christian via FreeIPA-users wrote: >>>>>>> On 11/02/2024 22.40, Ronald Wimmer via FreeIPA-users wrote: >>>>>>>>> Remark: If I set a new password for this particular user >>>>>>>>> after the user has been activated, it works. >>>>>>>> >>>>>>>> We are still facing this particular problem and do not have >>>>>>>> any clue why the initial password set by the external system >>>>>>>> does not work. Any ideas/hints here? >>>>>>> Two ideas: >>>>>>> >>>>>>> Are you supplying pre-hashed passwords in the correct format? >>>>>>> 389-DS expects hashed passwords in a specific format, e.g. >>>>>>> "{PBKDF2-SHA512}100000$base64data" for PKBDF2 with SHA-512 and >>>>>>> 100,000 iterations. >>>>>>> >>>>>>> IPA cannot create Kerberos keys from a pre-hashed passwords. >>>>>>> Kerberos does not work until the user's Kerberos key is >>>>>>> generated from a plain password, e.g. with a password change at >>>>>>> https://yourserver/ipa/migration/. SSSD can also detect the >>>>>>> case and generate Kerberos keys. >>>>>>> >>>>>>> When you log into LDAP as "cn=Directory Manager", then you can >>>>>>> read and check the "userPassword" and "krbPrincipalKey" >>>>>>> entries. >>>>>>> >>>>>>> Christian >>>>>> >>>>>> We are providing plaintext passwords. When the user is initially >>>>>> created in the staging area the password does not seem to work. >>>>>> When the user is activated and thus moved to the right place in >>>>>> the LDAP tree we can set a different password that works >>>>>> immediately. >>>>>> >>>>>> In both cases an LDAP browser reveals that the password gets >>>>>> hashed immediately by 389DS. (PBKDF2_SHA256) >>>>> >>>>> This works for me: >>>>> $ ipa stageuser-add --setattr 'userpassword=MyPass1234' --first >>>>> test --last user testuser >>>>> >>>>> This creates a staging user, sets their password to "MyPass1234", >>>>> and marks the password as expired. IPA always marks passwords as >>>>> expired when they are touched by a different user. They are ways >>>>> to work around the limitation (passSyncManagersDNs / PassSync >>>>> Service) >>>>> >>>>> $ ipa stageuser-activate testuser >>>>> >>>>> Now "testuser" can ssh into the machine and is forced the reset >>>>> their password. >>>>> >>>>> By the way, you do not need migration mode if you are providing >>>>> cleartext passwords to LDAP. >>>> >>>> OK. I see. It might be an expiration issue. But if it was I should >>>> run into the same issue when modifying a user's password (over >>>> LDAP) later on. >>>> >>>> Maybe Flo, Rob or Alexander could clarify what to expect in which >>>> scenario and how to disable immediate expiration if necessary? >>> >>> The password expiration is controlled by ipa_pwd_extop plugin. To >>> disable password expiration, add the user DN of your service >>> account to the "passSyncManagersDNs" attribute of >>> cn=ipa_pwd_extop,cn=plugins,cn=config. You have to apply the >>> setting to all your servers manually. >> >> I found out that the password is working perfectly fine when ssh-ing >> to an IPA machine. Also su works. But trying to logon to the WebUI >> does not. I do get "The password or username you entered is >> incorrect". Might be related to the fact that the user does not have >> any kerberos specific LDAP attributes(apart from krbCanonicalName >> and krbPrincipalName) after initial creation from the external >> system. >> >> As the password is set in plaintext from the external system there >> should be a possibility for IPA to generate Kerberos keys etc. What >> could I try? > > It looks like IPA generates missing attributes after some time. When > I tried to login to the WebUI just seconds ago it worked. Can the > generation of missing attributes be triggered manually?
It is triggered as you move the user from staging. The operation is asynchronous so might take place shortly after the move. There is no specific way to control it, sorry
What I see is that no LDAP attributes were added after having moved the user from staging. Even after minutes. When I use this particular user for SSH login krbExtraData, krbLastPwdChange, krbPasswordExpiration and krbPrincipalKey are added almost immediately. --
This is SSSD "migrating" the password. If migration mode is enabled and SSSD can't get a Kerberos ticket it will do an LDAP bind instead which will cause the Kerberos keys to be generated.
The WebUI only uses Kerberos. You'd have to use the password migration page to set the keys.
Perfect. I can confirm that all required LDAP properties appear after I do an LDAP bind manually.
What would probably be the best way to do this in an automated way? What would you suggest?
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
Christian
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Cheers, Ronald
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You don't provide enough information to tell. Did you upgrade versions?
Per the link, do your users have SIDs?
rob
On 13.06.24 14:30, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You don't provide enough information to tell. Did you upgrade versions?
Per the link, do your users have SIDs?
I was asking in an unspecific way because I knew that you would have some sort of suspicion...
You were absolutely right. The user does not have a SID. Which information do you need in order to further investigate the problem?
Cheers Ronald
Ronald Wimmer wrote:
On 13.06.24 14:30, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote: > > I don't think it's possible to speculate without knowing your > process. > > This requires the cleartext password so assuming you create the > staged > user then immediately active them, that would be the time to do the > bind. Otherwise you have to store cleartext passwords and that is a > recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You don't provide enough information to tell. Did you upgrade versions?
Per the link, do your users have SIDs?
I was asking in an unspecific way because I knew that you would have some sort of suspicion...
You were absolutely right. The user does not have a SID. Which information do you need in order to further investigate the problem?
There are a bunch of threads in freeipa-users that describe how to troubleshoot this.
rob
On 17.06.24 19:53, Rob Crittenden wrote:
Ronald Wimmer wrote:
On 13.06.24 14:30, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote: > On 13.02.24 17:47, Rob Crittenden wrote: >> >> I don't think it's possible to speculate without knowing your >> process. >> >> This requires the cleartext password so assuming you create the >> staged >> user then immediately active them, that would be the time to do the >> bind. Otherwise you have to store cleartext passwords and that is a >> recipe for disaster. > > User is created by an external tool. User activation in IPA is done > by a script on one of the IPA servers periodically. Sadly, the > external tool cannot do an initial LDAP bind in order to create a > users's krb LDAP attributes. I am looking for a simple way these > properties are created. > > Sure I could say a user has to SSH somewhere but why can't that > happen if a user tries to login to IPA's WebGUI and the krb > properties are missing? Or is there another option for users to > accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You don't provide enough information to tell. Did you upgrade versions?
Per the link, do your users have SIDs?
I was asking in an unspecific way because I knew that you would have some sort of suspicion...
You were absolutely right. The user does not have a SID. Which information do you need in order to further investigate the problem?
There are a bunch of threads in freeipa-users that describe how to troubleshoot this.
I am aware of that. But in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Alexander states "One issue we identified today together with Fedora infrastructure team is that staged users (created with 'ipa stageuser-add') will prevent sidgen plugin to generate entries." Is this already fixed? Yes? No? How can we possibly prevent this from happening again in the future?
How does https://access.redhat.com/articles/7027037 relate to the above? Does the sidgen plugin not work because of that or is this completely unrelated?
This is not completely clear to us. I was hoping for two or three sentences of explanation what could most likely have happened here...
On Срд, 19 чэр 2024, Ronald Wimmer via FreeIPA-users wrote:
On 17.06.24 19:53, Rob Crittenden wrote:
Ronald Wimmer wrote:
On 13.06.24 14:30, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote: >On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote: >>On 13.02.24 17:47, Rob Crittenden wrote: >>> >>>I don't think it's possible to speculate without knowing your >>>process. >>> >>>This requires the cleartext password so assuming you create the >>>staged >>>user then immediately active them, that would be the time to do the >>>bind. Otherwise you have to store cleartext passwords and that is a >>>recipe for disaster. >> >>User is created by an external tool. User activation in IPA is done >>by a script on one of the IPA servers periodically. Sadly, the >>external tool cannot do an initial LDAP bind in order to create a >>users's krb LDAP attributes. I am looking for a simple way these >>properties are created. >> >>Sure I could say a user has to SSH somewhere but why can't that >>happen if a user tries to login to IPA's WebGUI and the krb >>properties are missing? Or is there another option for users to >>accomplish this? > >Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the >hood. It allows the WebUI to talk to the LDAP server on behalf of the >user. This feature require a proper Kerberos credentials. See >https://www.freeipa.org/page/V4/Service_Constraint_Delegation > >I already mentioned the recommended option to archive this a while >ago. You may have missed the piece of information in this very long >thread. IPA servers have a special /ipa/migration route (e.g. >https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. >Under the hood the endpoint just does an LDAP bind with username and >password. You can ask your users to either log into a machine with >ssh or go to the migration page.
I did indeed miss that vital information. It is more than sufficient for our needs.
Thanks a lot guys. All scenarios that need to be working in our environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You don't provide enough information to tell. Did you upgrade versions?
Per the link, do your users have SIDs?
I was asking in an unspecific way because I knew that you would have some sort of suspicion...
You were absolutely right. The user does not have a SID. Which information do you need in order to further investigate the problem?
There are a bunch of threads in freeipa-users that describe how to troubleshoot this.
I am aware of that. But in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Alexander states "One issue we identified today together with Fedora infrastructure team is that staged users (created with 'ipa stageuser-add') will prevent sidgen plugin to generate entries." Is this already fixed? Yes? No? How can we possibly prevent this from happening again in the future?
This is already fixed upstream: https://pagure.io/freeipa/issue/9517
and it is released in RHEL 9.4/9.3.z/9.2.z/9.0.z and RHEL 8.10z/8.9z/8.8z/8.6z. Also fixed in Fedora 39-41.
if you specific problems, make sure to provide concrete logs or talk to your support organization, if you have access to one.
On 19.06.24 10:32, Alexander Bokovoy via FreeIPA-users wrote:
On Срд, 19 чэр 2024, Ronald Wimmer via FreeIPA-users wrote:
On 17.06.24 19:53, Rob Crittenden wrote:
Ronald Wimmer wrote:
On 13.06.24 14:30, Rob Crittenden wrote:
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 21:04, Ronald Wimmer via FreeIPA-users wrote: > On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote: >> On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote: >>> On 13.02.24 17:47, Rob Crittenden wrote: >>>> >>>> I don't think it's possible to speculate without knowing your >>>> process. >>>> >>>> This requires the cleartext password so assuming you create the >>>> staged >>>> user then immediately active them, that would be the time to >>>> do the >>>> bind. Otherwise you have to store cleartext passwords and that >>>> is a >>>> recipe for disaster. >>> >>> User is created by an external tool. User activation in IPA is >>> done >>> by a script on one of the IPA servers periodically. Sadly, the >>> external tool cannot do an initial LDAP bind in order to create a >>> users's krb LDAP attributes. I am looking for a simple way these >>> properties are created. >>> >>> Sure I could say a user has to SSH somewhere but why can't that >>> happen if a user tries to login to IPA's WebGUI and the krb >>> properties are missing? Or is there another option for users to >>> accomplish this? >> >> Because the IPA WebUI uses the Kerberos extension S4U2Proxy >> under the >> hood. It allows the WebUI to talk to the LDAP server on behalf >> of the >> user. This feature require a proper Kerberos credentials. See >> https://www.freeipa.org/page/V4/Service_Constraint_Delegation >> >> I already mentioned the recommended option to archive this a while >> ago. You may have missed the piece of information in this very long >> thread. IPA servers have a special /ipa/migration route (e.g. >> https://ipa.demo1.freeipa.org/ipa/migration/) for password >> migration. >> Under the hood the endpoint just does an LDAP bind with username >> and >> password. You can ask your users to either log into a machine with >> ssh or go to the migration page. > > I did indeed miss that vital information. It is more than sufficient > for our needs. > > Thanks a lot guys. All scenarios that need to be working in our > environment do actually work now.
Did something change on the IPA side? Newly created users cannot login to the WebGUI anymore. They get a "Your session has expired" error. Might have to do with this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
You don't provide enough information to tell. Did you upgrade versions?
Per the link, do your users have SIDs?
I was asking in an unspecific way because I knew that you would have some sort of suspicion...
You were absolutely right. The user does not have a SID. Which information do you need in order to further investigate the problem?
There are a bunch of threads in freeipa-users that describe how to troubleshoot this.
I am aware of that. But in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Alexander states "One issue we identified today together with Fedora infrastructure team is that staged users (created with 'ipa stageuser-add') will prevent sidgen plugin to generate entries." Is this already fixed? Yes? No? How can we possibly prevent this from happening again in the future?
This is already fixed upstream: https://pagure.io/freeipa/issue/9517
and it is released in RHEL 9.4/9.3.z/9.2.z/9.0.z and RHEL 8.10z/8.9z/8.8z/8.6z. Also fixed in Fedora 39-41.
if you specific problems, make sure to provide concrete logs or talk to your support organization, if you have access to one.
The problem was that the external system specified UIDs/GIDs out of the range defined by IPA. We changed that to let IPA assign IDs dynamically upon activation. (if somebody is interested in the details... read about static vs. automatic assignment here: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/lin... )
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
You wrote "under the hood it just does an LDAP bind". We let the external IAM system do an LDAP bind whenever a user's password changes. So we do not need to force users to establish an SSH connection or call the /ipa/migration route manually.
Is it ok from your point of view to do it like that or do you see any culprits?
Cheers, Ronald
Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 18:54, Christian Heimes via FreeIPA-users wrote:
On 13/02/2024 18.03, Ronald Wimmer via FreeIPA-users wrote:
On 13.02.24 17:47, Rob Crittenden wrote:
I don't think it's possible to speculate without knowing your process.
This requires the cleartext password so assuming you create the staged user then immediately active them, that would be the time to do the bind. Otherwise you have to store cleartext passwords and that is a recipe for disaster.
User is created by an external tool. User activation in IPA is done by a script on one of the IPA servers periodically. Sadly, the external tool cannot do an initial LDAP bind in order to create a users's krb LDAP attributes. I am looking for a simple way these properties are created.
Sure I could say a user has to SSH somewhere but why can't that happen if a user tries to login to IPA's WebGUI and the krb properties are missing? Or is there another option for users to accomplish this?
Because the IPA WebUI uses the Kerberos extension S4U2Proxy under the hood. It allows the WebUI to talk to the LDAP server on behalf of the user. This feature require a proper Kerberos credentials. See https://www.freeipa.org/page/V4/Service_Constraint_Delegation
I already mentioned the recommended option to archive this a while ago. You may have missed the piece of information in this very long thread. IPA servers have a special /ipa/migration route (e.g. https://ipa.demo1.freeipa.org/ipa/migration/) for password migration. Under the hood the endpoint just does an LDAP bind with username and password. You can ask your users to either log into a machine with ssh or go to the migration page.
You wrote "under the hood it just does an LDAP bind". We let the external IAM system do an LDAP bind whenever a user's password changes. So we do not need to force users to establish an SSH connection or call the /ipa/migration route manually.
Is it ok from your point of view to do it like that or do you see any culprits?
If the remote system already has the cleartext password it doesn't seem risky for it to do a bind with it. Assuming you use startTLS or the ldaps port of course.
rob
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Christian Heimes -
Rob Crittenden -
Ronald Wimmer