[Freeipa-users] slapi-nis user password error

[cbulist at gmail.com]

Nalin, Alexander and Dmitri,

Thanks so much for help and clarified me some points.
Yes, we are using {CRYPT} and after configure Kerberos for
authentication we are able to log in.
Again, thank so much!



On 09/05/2013 10:11 AM, Nalin Dahyabhai wrote:
> On Thu, Sep 05, 2013 at 09:17:36AM -0500, cbulist at gmail.com wrote:
>> The users were imported from a openldap server and the password
>> encryption is MD5.
> Is that {CRYPT} using an md5-based crypt, or {MD5} or {SMD5}?  A client
> that's trying to check passwords using hashes which it reads via NIS is
> usually only compatible with hashes that are identified with {CRYPT}.
>
>> I installed slapi-nis in the server and configure a NIS client(Red Hat
>> 5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26).
>> I'm able to get info of the users from NIS client (getent passwd
>> user_id) but when the user try to log in to the NIS client the
>> authentication fails.
> Which authentication mechanism did you configure in combination with NIS
> for user information?
>
>> Slapi-nis was installed and configured using the default options.
>> Any clue about this problem or How can I debug this?
> If you're using pam_unix (which you probably are, if you're using
> neither LDAP nor Kerberos for authenticating users), then you need to
> have {CRYPT} hashes in your user entries.  If you don't have those,
> you'll need to remedy that first, by configuring the server to use the
> CRYPT password storage scheme (IIRC the default is SSHA), and then
> forcing some password changes.  After that, the default configuration
> for the version of slapi-nis you have should cause them to start showing
> up when you use getent (or ypmatch) to read the user's entry from the
> passwd map.
>
> Then you can double-check that a password is correct by taking a hashed
> value and a candidate password and running them through something like
>
>   python -c 'import crypt; print crypt.crypt("password","hash")'
>
> to check if hashing the password using the salt that's part of the
> hashed value reproduces the hashed value, which is more or less what
> pam_unix does to check the password.
>
> That all said, I'd recommend using SSSD's support for reading identity
> information via LDAP, or better still its IPA provider, which can
> interact with the IPA server when it's in migration mode, and start
> moving you toward being able to switch over to using Kerberos.
>
> HTH,
>
> Nalin