2:02 p.m.
Hi all,
We have a need to set the password hash value directly, is this possible?
It does not appear that ipa user-mod will support this, and using the API
or other methods looks like it will be fraught with access control
complications.
Andy
2:08 p.m.
Alfred Victor via FreeIPA-users wrote:
Hi all,
We have a need to set the password hash value directly, is this
possible? It does not appear that ipa user-mod will support this, and
using the API or other methods looks like it will be fraught with access
control complications.
Why do you need to set the hash directly?
It is possible to do when adding a new user for migration purposes, but
after that it is generally not allowed.
rob
3:10 p.m.
Hi Rob,
We have our system in migration mode. Due to the number and diversity of
systems we have, we've found we really need to test everything extensively
before we can cut over and make our IPA cluster our source of truth.
Keeping a subset of systems on IPA during this time allows us to be
comfortable switching at some future date, given that we know we've had no
issues with each subset x of all systems y with t duration of production
utilization.
Andy
On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden <rcritten(a)redhat.com> wrote:
Alfred Victor via FreeIPA-users wrote:
> Hi all,
>
> We have a need to set the password hash value directly, is this
> possible? It does not appear that ipa user-mod will support this, and
> using the API or other methods looks like it will be fraught with access
> control complications.
Why do you need to set the hash directly?
It is possible to do when adding a new user for migration purposes, but
after that it is generally not allowed.
rob
10:52 a.m.
Hi Rob and IPA list -
The alternative is if it is possible to use the sssd method similar to as
described in 39.1.2.3 at the below link to update credentials at IPA as
well when a user resets their password, but I expect that if this is
possible to do with both systems in parallel (OpenLDAP remaining source of
truth until IPA is given the reins), the configuration will be complex.
Hence why I feel we are better off writing this value directly, or else our
IPA systems are going to have a stale credential problem because migrate-ds
will copy the user, or make sure any new user ends up in IPA, but
eventually the user changes password and migrate-ds will only be concerned
that the user already exists and will not update the credential. Can you
please let us know what we'll need to change or do to write to the password
hash directly? I do not plan to store any credential hashes during this
process - nor do I plan to have them accessible by any means. They will be
processed into IPA and that's it. We already sync public key, group changes
to IPA.
SSSD method:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
Another option is of course to drop all users and remigrate them, but this
is incompatible with our use case, as we won't have this opportunity easily.
Andy
On Wed, Feb 3, 2021 at 3:10 PM Alfred Victor <alvic266(a)gmail.com> wrote:
Hi Rob,
We have our system in migration mode. Due to the number and diversity of
systems we have, we've found we really need to test everything extensively
before we can cut over and make our IPA cluster our source of truth.
Keeping a subset of systems on IPA during this time allows us to be
comfortable switching at some future date, given that we know we've had no
issues with each subset x of all systems y with t duration of production
utilization.
Andy
On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden <rcritten(a)redhat.com> wrote:
> Alfred Victor via FreeIPA-users wrote:
> > Hi all,
> >
> > We have a need to set the password hash value directly, is this
> > possible? It does not appear that ipa user-mod will support this, and
> > using the API or other methods looks like it will be fraught with access
> > control complications.
>
> Why do you need to set the hash directly?
>
> It is possible to do when adding a new user for migration purposes, but
> after that it is generally not allowed.
>
> rob
>
>
12:38 p.m.
New subject: Modify user password by accepting hash as input
Alfred Victor via FreeIPA-users wrote:
Hi Rob and IPA list -
The alternative is if it is possible to use the sssd method similar to
as described in 39.1.2.3 at the below link to update credentials at IPA
as well when a user resets their password, but I expect that if this is
possible to do with both systems in parallel (OpenLDAP remaining source
of truth until IPA is given the reins), the configuration will be
complex. Hence why I feel we are better off writing this value directly,
or else our IPA systems are going to have a stale credential problem
because migrate-ds will copy the user, or make sure any new user ends up
in IPA, but eventually the user changes password and migrate-ds will
only be concerned that the user already exists and will not update the
credential. Can you please let us know what we'll need to change or do
to write to the password hash directly? I do not plan to store any
credential hashes during this process - nor do I plan to have them
accessible by any means. They will be processed into IPA and that's it.
We already sync public key, group changes to IPA.
SSSD method:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
Another option is of course to drop all users and remigrate them, but
this is incompatible with our use case, as we won't have this
opportunity easily.
The problem with using a pre-hashed password is that IPA cannot generate
new keys so the user would always have to migrate their password using
either SSSD or an LDAP bind. How often that would be depends on how
often passwords are changing.
Syncing in a password change will also trigger an expired password. So
if you can grab the unhashed password and sync that then see
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/...
section 15.6.3 (ignore everything else, literally).
This will allow an unhashed password to be written without marking it as
expired.For DN you use the user that binds from your existing password
source to do the write.
rob
Andy
On Wed, Feb 3, 2021 at 3:10 PM Alfred Victor <alvic266(a)gmail.com
<mailto:alvic266@gmail.com>> wrote:
Hi Rob,
We have our system in migration mode. Due to the number and
diversity of systems we have, we've found we really need to test
everything extensively before we can cut over and make our IPA
cluster our source of truth. Keeping a subset of systems on IPA
during this time allows us to be comfortable switching at some
future date, given that we know we've had no issues with each subset
x of all systems y with t duration of production utilization.
Andy
On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden <rcritten(a)redhat.com
<mailto:rcritten@redhat.com>> wrote:
Alfred Victor via FreeIPA-users wrote:
> Hi all,
>
> We have a need to set the password hash value directly, is this
> possible? It does not appear that ipa user-mod will support
this, and
> using the API or other methods looks like it will be fraught
with access
> control complications.
Why do you need to set the hash directly?
It is possible to do when adding a new user for migration
purposes, but
after that it is generally not allowed.
rob
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
1:13 p.m.
From:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
*"Users cannot authenticate to the IdM domain or access IdM resources until
they have Kerberos hashes."*
To be sure I understand, without the kerberos keys SSH auth to an IPA
system requiring for instance SSH key+password in sshd_config will fail,
and 39.1.2.3 as described at link above won't generate the keys
transparently? Just trying to be sure I understand the scope and what
actions we need to take to make sure that logins will work, and that the
necessary keys will get created for a user to not notice whether they are
on an IPA or an LDAP system, or if this will require further action from us.
Also it sounds like we'll need to use ldapmodify to connect to the IPA
system to write the password hash. It sounds like I can use the same user
for this bind that does the migrate-ds currently. This user is currently
set up with least privilege, has only a special group we have created. Is
there anything I need to give it specially to be able to write hashes of an
existing user, or I guess it already can do this if it can do a migrate-ds
and create users (and their hash values)?
Andy
On Thu, Feb 4, 2021 at 12:38 PM Rob Crittenden <rcritten(a)redhat.com> wrote:
Alfred Victor via FreeIPA-users wrote:
> Hi Rob and IPA list -
>
> The alternative is if it is possible to use the sssd method similar to
> as described in 39.1.2.3 at the below link to update credentials at IPA
> as well when a user resets their password, but I expect that if this is
> possible to do with both systems in parallel (OpenLDAP remaining source
> of truth until IPA is given the reins), the configuration will be
> complex. Hence why I feel we are better off writing this value directly,
> or else our IPA systems are going to have a stale credential problem
> because migrate-ds will copy the user, or make sure any new user ends up
> in IPA, but eventually the user changes password and migrate-ds will
> only be concerned that the user already exists and will not update the
> credential. Can you please let us know what we'll need to change or do
> to write to the password hash directly? I do not plan to store any
> credential hashes during this process - nor do I plan to have them
> accessible by any means. They will be processed into IPA and that's it.
> We already sync public key, group changes to IPA.
>
> SSSD method:
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
> Another option is of course to drop all users and remigrate them, but
> this is incompatible with our use case, as we won't have this
> opportunity easily.
The problem with using a pre-hashed password is that IPA cannot generate
new keys so the user would always have to migrate their password using
either SSSD or an LDAP bind. How often that would be depends on how
often passwords are changing.
Syncing in a password change will also trigger an expired password. So
if you can grab the unhashed password and sync that then see
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/...
section 15.6.3 (ignore everything else, literally).
This will allow an unhashed password to be written without marking it as
expired.For DN you use the user that binds from your existing password
source to do the write.
rob
> Andy
>
> On Wed, Feb 3, 2021 at 3:10 PM Alfred Victor <alvic266(a)gmail.com
> <mailto:alvic266@gmail.com>> wrote:
>
> Hi Rob,
>
> We have our system in migration mode. Due to the number and
> diversity of systems we have, we've found we really need to test
> everything extensively before we can cut over and make our IPA
> cluster our source of truth. Keeping a subset of systems on IPA
> during this time allows us to be comfortable switching at some
> future date, given that we know we've had no issues with each subset
> x of all systems y with t duration of production utilization.
>
> Andy
>
> On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>> wrote:
>
> Alfred Victor via FreeIPA-users wrote:
> > Hi all,
> >
> > We have a need to set the password hash value directly, is this
> > possible? It does not appear that ipa user-mod will support
> this, and
> > using the API or other methods looks like it will be fraught
> with access
> > control complications.
>
> Why do you need to set the hash directly?
>
> It is possible to do when adding a new user for migration
> purposes, but
> after that it is generally not allowed.
>
> rob
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
1:16 p.m.
(besides add the passSyncManagersDNs attribute of course!)
Andy
On Thu, Feb 4, 2021 at 1:13 PM Alfred Victor <alvic266(a)gmail.com> wrote:
From:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
*"Users cannot authenticate to the IdM domain or access IdM resources
until they have Kerberos hashes."*
To be sure I understand, without the kerberos keys SSH auth to an IPA
system requiring for instance SSH key+password in sshd_config will fail,
and 39.1.2.3 as described at link above won't generate the keys
transparently? Just trying to be sure I understand the scope and what
actions we need to take to make sure that logins will work, and that the
necessary keys will get created for a user to not notice whether they are
on an IPA or an LDAP system, or if this will require further action from us.
Also it sounds like we'll need to use ldapmodify to connect to the IPA
system to write the password hash. It sounds like I can use the same user
for this bind that does the migrate-ds currently. This user is currently
set up with least privilege, has only a special group we have created. Is
there anything I need to give it specially to be able to write hashes of an
existing user, or I guess it already can do this if it can do a migrate-ds
and create users (and their hash values)?
Andy
On Thu, Feb 4, 2021 at 12:38 PM Rob Crittenden <rcritten(a)redhat.com>
wrote:
> Alfred Victor via FreeIPA-users wrote:
> > Hi Rob and IPA list -
> >
> > The alternative is if it is possible to use the sssd method similar to
> > as described in 39.1.2.3 at the below link to update credentials at IPA
> > as well when a user resets their password, but I expect that if this is
> > possible to do with both systems in parallel (OpenLDAP remaining source
> > of truth until IPA is given the reins), the configuration will be
> > complex. Hence why I feel we are better off writing this value directly,
> > or else our IPA systems are going to have a stale credential problem
> > because migrate-ds will copy the user, or make sure any new user ends up
> > in IPA, but eventually the user changes password and migrate-ds will
> > only be concerned that the user already exists and will not update the
> > credential. Can you please let us know what we'll need to change or do
> > to write to the password hash directly? I do not plan to store any
> > credential hashes during this process - nor do I plan to have them
> > accessible by any means. They will be processed into IPA and that's it.
> > We already sync public key, group changes to IPA.
> >
> > SSSD method:
> >
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
> >
> > Another option is of course to drop all users and remigrate them, but
> > this is incompatible with our use case, as we won't have this
> > opportunity easily.
>
> The problem with using a pre-hashed password is that IPA cannot generate
> new keys so the user would always have to migrate their password using
> either SSSD or an LDAP bind. How often that would be depends on how
> often passwords are changing.
>
> Syncing in a password change will also trigger an expired password. So
> if you can grab the unhashed password and sync that then see
>
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/...
> section 15.6.3 (ignore everything else, literally).
>
> This will allow an unhashed password to be written without marking it as
> expired.For DN you use the user that binds from your existing password
> source to do the write.
>
> rob
>
> > Andy
> >
> > On Wed, Feb 3, 2021 at 3:10 PM Alfred Victor <alvic266(a)gmail.com
> > <mailto:alvic266@gmail.com>> wrote:
> >
> > Hi Rob,
> >
> > We have our system in migration mode. Due to the number and
> > diversity of systems we have, we've found we really need to test
> > everything extensively before we can cut over and make our IPA
> > cluster our source of truth. Keeping a subset of systems on IPA
> > during this time allows us to be comfortable switching at some
> > future date, given that we know we've had no issues with each subset
> > x of all systems y with t duration of production utilization.
> >
> > Andy
> >
> > On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden <rcritten(a)redhat.com
> > <mailto:rcritten@redhat.com>> wrote:
> >
> > Alfred Victor via FreeIPA-users wrote:
> > > Hi all,
> > >
> > > We have a need to set the password hash value directly, is
> this
> > > possible? It does not appear that ipa user-mod will support
> > this, and
> > > using the API or other methods looks like it will be fraught
> > with access
> > > control complications.
> >
> > Why do you need to set the hash directly?
> >
> > It is possible to do when adding a new user for migration
> > purposes, but
> > after that it is generally not allowed.
> >
> > rob
> >
> >
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
> >
>
>
4:06 p.m.
New subject: Modify user password by accepting hash as input
Alfred Victor via FreeIPA-users wrote:
From: https://access.redhat.com/documentation/en-us/red_hat_enterprise_li...
*"Users cannot authenticate to the IdM domain or access IdM resources
until they have Kerberos hashes."*
*
*
To be sure I understand, without the kerberos keys SSH auth to an IPA
system requiring for instance SSH key+password in sshd_config will fail,
and 39.1.2.3 as described at link above won't generate the keys
transparently? Just trying to be sure I understand the scope and what
actions we need to take to make sure that logins will work, and that the
necessary keys will get created for a user to not notice whether they
are on an IPA or an LDAP system, or if this will require further action
from us.
An ssh login should proceed because it uses the keys for authentication,
not IPA (though IPA may be involved by providing the public key).
And this doc is not quite accurate. LDAP binds are allowed so a user can
change their password and/or authenticate in order to generate the keys
(if config mode is enabled).
Also it sounds like we'll need to use ldapmodify to connect to
the IPA
system to write the password hash. It sounds like I can use the same
user for this bind that does the migrate-ds currently. This user is
currently set up with least privilege, has only a special group we have
created. Is there anything I need to give it specially to be able to
write hashes of an existing user, or I guess it already can do this if
it can do a migrate-ds and create users (and their hash values)?
Password hash updates are not allowed at all. A hash can only be set
when adding a new user and only when config mode is on.
For good or bad IPA expects to be the central identity authority.
rob
Andy
On Thu, Feb 4, 2021 at 12:38 PM Rob Crittenden <rcritten(a)redhat.com
<mailto:rcritten@redhat.com>> wrote:
Alfred Victor via FreeIPA-users wrote:
> Hi Rob and IPA list -
>
> The alternative is if it is possible to use the sssd method similar to
> as described in 39.1.2.3 at the below link to update credentials
at IPA
> as well when a user resets their password, but I expect that if
this is
> possible to do with both systems in parallel (OpenLDAP remaining
source
> of truth until IPA is given the reins), the configuration will be
> complex. Hence why I feel we are better off writing this value
directly,
> or else our IPA systems are going to have a stale credential problem
> because migrate-ds will copy the user, or make sure any new user
ends up
> in IPA, but eventually the user changes password and migrate-ds will
> only be concerned that the user already exists and will not update the
> credential. Can you please let us know what we'll need to change or do
> to write to the password hash directly? I do not plan to store any
> credential hashes during this process - nor do I plan to have them
> accessible by any means. They will be processed into IPA and
that's it.
> We already sync public key, group changes to IPA.
>
> SSSD method:
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
> Another option is of course to drop all users and remigrate them, but
> this is incompatible with our use case, as we won't have this
> opportunity easily.
The problem with using a pre-hashed password is that IPA cannot generate
new keys so the user would always have to migrate their password using
either SSSD or an LDAP bind. How often that would be depends on how
often passwords are changing.
Syncing in a password change will also trigger an expired password. So
if you can grab the unhashed password and sync that then see
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/...
section 15.6.3 (ignore everything else, literally).
This will allow an unhashed password to be written without marking it as
expired.For DN you use the user that binds from your existing password
source to do the write.
rob
> Andy
>
> On Wed, Feb 3, 2021 at 3:10 PM Alfred Victor <alvic266(a)gmail.com
<mailto:alvic266@gmail.com>
> <mailto:alvic266@gmail.com <mailto:alvic266@gmail.com>>> wrote:
>
> Hi Rob,
>
> We have our system in migration mode. Due to the number and
> diversity of systems we have, we've found we really need to test
> everything extensively before we can cut over and make our IPA
> cluster our source of truth. Keeping a subset of systems on IPA
> during this time allows us to be comfortable switching at some
> future date, given that we know we've had no issues with each
subset
> x of all systems y with t duration of production utilization.
>
> Andy
>
> On Wed, Feb 3, 2021 at 2:08 PM Rob Crittenden
<rcritten(a)redhat.com <mailto:rcritten@redhat.com>
> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>
wrote:
>
> Alfred Victor via FreeIPA-users wrote:
> > Hi all,
> >
> > We have a need to set the password hash value directly,
is this
> > possible? It does not appear that ipa user-mod will support
> this, and
> > using the API or other methods looks like it will be fraught
> with access
> > control complications.
>
> Why do you need to set the hash directly?
>
> It is possible to do when adding a new user for migration
> purposes, but
> after that it is generally not allowed.
>
> rob
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
1174
days inactive
1175
days old
freeipa-users@lists.fedorahosted.org
7 comments
2 participants
participants (2)
-
Alfred Victor -
Rob Crittenden