Re: Create IPA user via LDAP

[Ronald Wimmer]

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/...
> >>>>>
> >>>>
> >>>> 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

Create IPA user via LDAP

[Rob Crittenden]

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/...
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> 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

Create IPA user via LDAP

[Ronald Wimmer]

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/...
> >>>>>>
> >>>>>
> >>>>> 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

Create IPA user via LDAP

[Rob Crittenden]

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/...
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> 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

Create IPA user via LDAP

[Ronald Wimmer]

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/...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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/...

)

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

Create IPA user via LDAP

[Ronald Wimmer]

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/...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> 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/...
> )
>  
>  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

Create IPA user via LDAP

[Christian Heimes]

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
-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

Create IPA user via LDAP

[Ronald Wimmer]

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

Create IPA user via LDAP

[Christian Heimes]

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.

-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

Create IPA user via LDAP

[Ronald Wimmer]

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

Create IPA user via LDAP

[Christian Heimes]

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".

-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

Create IPA user via LDAP

[Christian Heimes]

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
-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

Create IPA user via LDAP

[Ronald Wimmer]

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!

Create IPA user via LDAP

[Ronald Wimmer]

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?

Create IPA user via LDAP

[Ronald Wimmer]

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?

Create IPA user via LDAP

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

Create IPA user via LDAP

[Ronald Wimmer]

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.

Create IPA user via LDAP

[Rob Crittenden]

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

Create IPA user via LDAP

[Ronald Wimmer]

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

Create IPA user via LDAP

[Ronald Wimmer]

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?

Create IPA user via LDAP

[Rob Crittenden]

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

Create IPA user via LDAP

[Ronald Wimmer]

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?

Create IPA user via LDAP

[Christian Heimes]

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

-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

Create IPA user via LDAP

[Ronald Wimmer]

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

Create IPA user via LDAP

[Ronald Wimmer]

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/[e-mail]...

Create IPA user via LDAP

[Rob Crittenden]

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/[e-mail]...
You don't provide enough information to tell. Did you upgrade versions?

Per the link, do your users have SIDs?

rob

Create IPA user via LDAP

[Ronald Wimmer]

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/[e-mail]...
>  
>  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

Create IPA user via LDAP

[Rob Crittenden]

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/[e-mail]...
> >>
> >
> > 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

Create IPA user via LDAP

[Ronald Wimmer]

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/[e-mail]...
> >>>
> >>
> >> 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/[e-mail]...

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...

Create IPA user via LDAP

[Alexander Bokovoy]

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/[e-mail]/thread/YFPMHCWA7R47ZSI75EZKCMSWLH5QYH4P/?sort=date
> >>>>
> >>>
> >>>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/[e-mail]...
>
> 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.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland