[Freeipa-users] Problem migrating passwords fro NIS to IdM

Thu Nov 20 10:54:22 UTC 2014

On 19/11/14 15:00, Rob Crittenden wrote:
> Rob Crittenden wrote:
>> Roderick Johnstone wrote:
>>> On 19/11/2014 08:33, Roderick Johnstone wrote:
>>>> On 18/11/2014 22:58, Rob Crittenden wrote:
>>>>> Roderick Johnstone wrote:
>>>>>> On 18/11/2014 22:19, Dmitri Pal wrote:
>>>>>>> On 11/18/2014 12:57 PM, Roderick Johnstone wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I'm trying to migrate some nis accounts to RHEL 6 IdM while still
>>>>>>>> keeping the original passwords.
>>>>>>>>
>>>>>>>> I followed the instructions at:
>>>>>>>> http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The passwords are in SHA-512 format and I have been testing the
>>>>>>>> migration with commands like this (generated via a script from my nis
>>>>>>>> passwd file) on my IdM server:
>>>>>>>>
>>>>>>>> $ ipa user-add xxx --first=NIS --last=USER --gidnumber=xxxx
>>>>>>>> --uid=xxxx
>>>>>>>> '--gecos=test account' --homedir=/home/xxxx --shell=/bin/bash
>>>>>>>> --setattr userpassword='{SHA-512}xxxxxxx'
>>>>>>>>
>>>>>>>> where the xxxxxxx is the hashed password from the NIS password file
>>>>>>>> with the leading $6$ stripped off.
>>>>>>>>
>>>>>>>> Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
>>>>>>>> left with:
>>>>>>>> passwd:     files   sss
>>>>>>>>
>>>>>>>> and the account that I migrated cannot log in.
>>>>>>>>
>>>>>>>>   From the sssd log file (below) it looks like its trying to migrate
>>>>>>>> the
>>>>>>>> password but failing with an LDAP authentication failure.
>>>>>>>>
>>>>>>>> I'd appreciate any pointers to how to find out whats going wrong
>>>>>>>> here.
>>>>>>>>
>>>>>>>> Accounts which I created manually in the web gui are working ok.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Roderick Johnstone
>>>>>>>>
>>>>>>>> Part of sssd log file
>>>>>>>> =====================
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx'
>>>>>>>> as 'working'
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [fo_set_port_status] (0x0400): Marking port 0 of duplicate server
>>>>>>>> 'xxx.xxx.xxx.xxx' as 'working'
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos
>>>>>>>> password
>>>>>>>> is missing, starting password migration.
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
>>>>>>>> (0x0100): Executing simple bind as:
>>>>>>>> uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
>>>>>>>> (0x0400): Bind result: Invalid credentials(49), no errmsg set
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
>>>>>>>> migration not possible.
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [be_pam_handler_callback] (0x0100): Backend returned: (0, 8, <NULL>)
>>>>>>>> [Success]
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
>>>>>>>> (Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
>>>>>>>> [be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
>>>>>>>>
>>>>>>>
>>>>>>> Did you enable migration mode on the IPA server?
>>>>>>>
>>>>>>
>>>>>> Yes, I ran:
>>>>>> ipa config-mod --enable-migration=true
>>>>>> on the IPA server.
>>>>>>
>>>>>> Roderick
>>>>>>
>>>>>
>>>>> The has name probably needs to match something in cn=Password Storage
>>>>> Schemes,cn=plugins,cn=config.
>>>>>
>>>>> I'd try either {SHA512} or {SSHA512} and see if one of those works
>>>>> better.
>>>>>
>>>>> rob
>>>>>
>>>>
>>>> Rob
>>>>
>>>> I had wondered about the specification of the password hash type.
>>>>
>>>> I chose SHA-512 as it seemed to be suggested in the
>>>> passwordStorageScheme attribute described in Table 14.1 of the Redhat
>>>> Directory Server Admin Guide,
>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html.
>>>>
>>>> But now I come to re-read that doc it suggests perhaps that SHA covers
>>>> all the SHA- variants, so I'll give it another go using {SHA}xxxxxxx as
>>>> the userpassword specification.
>>>>
>>>> I have also seen the userpassword attribute referred to in other places
>>>> as userPassword and wondered whether the attribute name is case
>>>> sensitive. Do you know?
>>>>
>>>> Thanks for your input.
>>>>
>>>> Roderick
>>>>
>>>
>>> Rob
>>>
>>> I just tried with  --setattr userpassword='{SHA}xxxxxxx' but I get the
>>> same result:
>>> [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no
>>> errmsg set
>>> [ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
>>> migration not possible.
>>>
>>> I'm wondering if its something to do with the quoting. The hashed
>>> password contains $ and there are the {} around the SHA so I'm using
>>> strong single quotes to prevent anything following the $ being
>>> interpreted as a variable, I hope. Maybe this is a ref herring.
>>>
>>
>> I think your quoting is correct.
>>
>> I've only used this method with crypt passwords. I guess theoretically
>> it should work with other crypt(3) schemes but I've never tried. There
>> could be some 389-ds-specific gotchas.
>>
>> Crypt defines the storage as $id$salt$encrypted so perhaps strip out the
>> $id$ part since that is being defined by {SHA}, but I'm really only
>> guessing. The 389-ds guys may know.
>>
>> LDAP attributes are not case sensitive.
>
> Ok, this question was bugging me so I took a second to look into it.
>
> The trick is to use CRYPT and not be too clever about knowing the scheme
> the password is stored in.
>
> This worked for me:
>
> # grep myuser /etc/shadow
> $ ipa user-add --first=test --last=user --setattr
> userpassword='{CRYPT}$6$blahblah$moregibberish' testuser
> $ ldapsearch -x -D 'uid=testuser,cn=users,cn=accounts,dc=example,dc=com' -W
> Enter LDAP Password:
> <success>
>
> rob
>

Rob

Fantastic! This works for me too.

Thank you so much.

Roderick