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.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to