[Freeipa-users] Re: Modify user password by accepting hash as input

[Rob Crittenden via FreeIPA-users]

Alfred Victor via FreeIPA-users wrote:
> 
> From: 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa
> 
> *"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  > 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/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa
> >
> > 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/html/identity_management_guide/pass-sync
> 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  
> > >> 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 

[Freeipa-users] Re: Modify user password by accepting hash as input

[Alfred Victor via FreeIPA-users]

(besides add the passSyncManagersDNs attribute of course!)

Andy

On Thu, Feb 4, 2021 at 1:13 PM Alfred Victor  wrote:

>
> From:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa
>
> *"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 
> 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/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa
>> >
>> > 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/html/identity_management_guide/pass-sync
>> 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 > > > 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 > > > 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 

[Freeipa-users] Re: Modify user password by accepting hash as input

[Alfred Victor via FreeIPA-users]

From:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa

*"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  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/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa
> >
> > 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/html/identity_management_guide/pass-sync
> 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  > > 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  > > 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] Re: Trust external IPA?

[Rob Crittenden via FreeIPA-users]

Ian Pilcher via FreeIPA-users wrote:
> At work, I manage a small lab that is used by my team (< 10 people).
> All lab users are currently managed in the lab FreeIPA, but we all use
> it extensively, so creating separate credentials for the lab isn't
> overly burdensome.
> 
> We're now expanding the lab, and the number of users who may need access
> to it at some point is set to grow dramatically.  Additionally, many of
> these people are likely to be "one shot" users; they will need access to
> some lab resources for a week or so and then not use it again for
> months.  For these users, I would *really* like to avoid the usual
> user creation/password reset dance.
> 
> Fortunately(?) all of these users already have credentials in our
> corporate IPA infrastructure.  Is it possible to define users in the
> local IdM server that will use the corporate server for authentication?
> 

There is no IPA-to-IPA trust yet. Once true two-way IPA to AD trust is
done that brings us a lot closer to IPA-to-IPA but there is still a bit
of work to happen. There is no ETA.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Modify user password by accepting hash as input

[Rob Crittenden via FreeIPA-users]

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/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa
> 
> 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/html/identity_management_guide/pass-sync
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  > 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  > 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@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Trust external IPA?

[Ian Pilcher via FreeIPA-users]

At work, I manage a small lab that is used by my team (< 10 people).
All lab users are currently managed in the lab FreeIPA, but we all use
it extensively, so creating separate credentials for the lab isn't
overly burdensome.

We're now expanding the lab, and the number of users who may need access
to it at some point is set to grow dramatically.  Additionally, many of
these people are likely to be "one shot" users; they will need access to
some lab resources for a week or so and then not use it again for
months.  For these users, I would *really* like to avoid the usual
user creation/password reset dance.

Fortunately(?) all of these users already have credentials in our
corporate IPA infrastructure.  Is it possible to define users in the
local IdM server that will use the corporate server for authentication?

--

 In Soviet Russia, Google searches you!

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Jochen Kellner via FreeIPA-users]

Hi,

Robert Kudyba via FreeIPA-users 
writes:

> Yes and I found a fix. All that is needed is to surround the echo command
> with double quotes at the top of the script where username is set:
> username="$(echo $line | cut -f1 -d:)"

For some of these errors using shellcheck might help. Not bulletproof,
but helpful.

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Robert Kudyba via FreeIPA-users]

On Thu, Feb 4, 2021 at 11:47 AM Rob Crittenden  wrote:

> Robert Kudyba wrote:
> >
> > > Now any idea why the original  '$gecos' inserts the actual string
> > $gecos
> > > into FreeIPA/LDAP?
> >
> > It's a shell issue, single quotes prevents any argument expansion,
> use
> > double quotes.
> >
> >
> > Sure but using just double quotes $gecos is still added to the FreeIPA
> > record. I can at least import it with "'$gecos'" but the script then
> > imports the single quotes as a part of the record.
>
> I assume you tried "$gecos"?
>

Yes and I found a fix. All that is needed is to surround the echo command
with double quotes at the top of the script where username is set:
username="$(echo $line | cut -f1 -d:)"

> We also noticed if a NIS user has a middle initial the script errors with:
> > ipa: ERROR: command 'user_add' takes at most 1 argument
>
> There should be a way to file a doc bug within the docs themselves.
>

Indeed perhaps to add comments, but then those are never spam-proof.

The script was never meant to be bullet-proof. It was provided for
> guidance purposes. There are *lots* of corner cases with names.
>

Understood but it's a great launching point. I can share what my colleague
added with a couple awks to handle names in NIS that have middle initial,
"last name, first name" and other permutations:

# Change Last, First to First Last.  (Fill in dummy for empty gecos.)
if [ -z "$gecos" ]; then
firstlast='First Last'
else
firstlast=$(echo $gecos | sed -e 's/\(.*\), \(.*$\)/\2 \1/')
fi

# Extract First and Last into separate variables
first=$(echo $firstlast | awk '/^(\w|[-'\''])+ \w\. / { print $1,
$2; } \
   /^(\w|[-'\''])+ (\w|[-'\''])+( |$)/ {
print $1; }' )
#echo this dollar 1 $1 this is dollar 2 $2
last=$(echo $firstlast  | awk 'BEGIN {ORS=" ";} \
   /^(\w|[-'\''])+ \w\. / { for (i=3;
i<=NF; i++) print $i; } \
   /^(\w|[-'\''])+ (\w|[-'\''])+( |$)/ {
for (i=2; i<=NF; i++) print $i; }' \
| sed 's/ *$//' )

>
> > > Logs also spit out this warning after every user is added:
> >
> > > Failed to set perms (3140) on file
> > (/run/ipa/ccaches/ad...@ourdomain.edu  >)!,
> >
> >
> > I added a comment to issue
> > 7032
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_freeipa_issue_7032-23comment-2D713784=DwIDaQ=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY=X59opfrdKbUDbTLScz3EnMgDGj3HASui0JGAJwm2i5o=-_1fvpWeMHtgSeki3bf6aOD_P8fG2bPuts_obVgg8bo=
> not sure if
> > this is still a "won't fix" issue?
>
> It's not won't fix, it's just extremely low in priority since it doesn't
> affect operation.
>

Thanks for acknowledging. Hope I added some value to future users that
might find this thread.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Modify user password by accepting hash as input

[Alfred Victor via FreeIPA-users]

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/html/linux_domain_identity_authentication_and_policy_guide/migrating_from_a_directory_server_to_ipa

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  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  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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Rob Crittenden via FreeIPA-users]

Robert Kudyba wrote:
> 
> > Now any idea why the original  '$gecos' inserts the actual string 
> $gecos
> > into FreeIPA/LDAP?
> 
> It's a shell issue, single quotes prevents any argument expansion, use
> double quotes.
> 
> 
> Sure but using just double quotes $gecos is still added to the FreeIPA
> record. I can at least import it with "'$gecos'" but the script then
> imports the single quotes as a part of the record.

I assume you tried "$gecos"?

> We also noticed if a NIS user has a middle initial the script errors with:
> ipa: ERROR: command 'user_add' takes at most 1 argument

There should be a way to file a doc bug within the docs themselves.

The script was never meant to be bullet-proof. It was provided for
guidance purposes. There are *lots* of corner cases with names.

> So is there some escape character or something that works around this
> that isn't documented? I don't see anything withip help user-add
> 
> 
> > Logs also spit out this warning after every user is added: 
> 
> > Failed to set perms (3140) on file
> (/run/ipa/ccaches/ad...@ourdomain.edu )!,
> 
> 
> I added a comment to issue
> 7032 https://pagure.io/freeipa/issue/7032#comment-713784 not sure if
> this is still a "won't fix" issue? 

It's not won't fix, it's just extremely low in priority since it doesn't
affect operation.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Robert Kudyba via FreeIPA-users]

>
>
> > Now any idea why the original  '$gecos' inserts the actual string  $gecos
> > into FreeIPA/LDAP?
>
> It's a shell issue, single quotes prevents any argument expansion, use
> double quotes.
>

Sure but using just double quotes $gecos is still added to the FreeIPA
record. I can at least import it with "'$gecos'" but the script then
imports the single quotes as a part of the record.

We also noticed if a NIS user has a middle initial the script errors with:
ipa: ERROR: command 'user_add' takes at most 1 argument

So is there some escape character or something that works around this that
isn't documented? I don't see anything with ip help user-add


> Logs also spit out this warning after every user is added:

> Failed to set perms (3140) on file (/run/ipa/ccaches/ad...@ourdomain.edu
> )!,
>

I added a comment to issue 7032
https://pagure.io/freeipa/issue/7032#comment-713784 not sure if this is
still a "won't fix" issue?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org