[Freeipa-users] Understanding the migration mode

[Prasun Gera]

I had a look at ldap/servers/plugins/pwdstorage/crypt_pwd.c, and it looks
like it is hardcoded in crypt_pw_enc, which uses the default DES crypt
method. This only affects the encoding. The verification of passwords works
with any of MD5 or SHA-* schemes since the underlying crypt function in
recent glibcs supports them. Would it make sense to add the other options
to the encoding function ?

On Thu, Apr 2, 2015 at 3:27 AM, Prasun Gera <prasun.gera at gmail.com> wrote:

> I tried enabling crypt for experimentation, and things seem to work well
> for both NIS and SSSD clients. I noticed that the crypt format that the NIS
> plugin in IPA provides is the traditional crypt format with a 2 character
> salt and 13 character hash. NIS clients can understand newer crypt
> encodings which allow MD5, SHA256 and SHA512 (
> https://docs.python.org/3/library/crypt.html) . Is it possible to force
> one of those as the storage scheme in the directory server ?
>
> On Tue, Mar 31, 2015 at 12:04 PM, Prasun Gera <prasun.gera at gmail.com>
> wrote:
>
>> I've figured it out. You are right. SSSD triggers key generation. For
>> migrated clients though, since ypbind still runs and the NIS-plugin serves
>> maps, they authenticate first using NIS before SSSD. If ypbind is stopped,
>> it is forced to use SSSD, and then it triggers the migration. Thanks for
>> persisting with this. It's pretty clear how it works now.
>>
>> On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera <prasun.gera at gmail.com>
>> wrote:
>>
>>>
>>>
>>>> ? SSSD does not seem to be involved as user is found in the /etc/passwd
>>>> and this SSSD should not do anything.
>>>>
>>>> It's not  a local user. There's no entry in /etc/passwd. Here's the
>>> relevant sssd log
>>>
>>>
>>> sssd_ssh
>>>
>>> (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains]
>>> (0x0200): name 'testuser2' matched without domain, user is testuser2
>>> (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client
>>> disconnected!
>>> (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
>>> Received client version [0].
>>>
>>> sssd_pam
>>>
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
>>> domain: ipadomain
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
>>> testuser2
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
>>> service: sshd
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty:
>>> ssh
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>>> not set
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>>> host_ip
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
>>> authtok type: 0
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
>>> newauthtok type: 0
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
>>> cli_pid: 23983
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>>> name: testuser2
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
>>> pam_dp_send_req returned 0
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100):
>>> received: [0][ipadomain]
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
>>> called with result [0].
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27
>>> (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client
>>> disconnected!
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150402/55862406/attachment.htm>