<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/27/2015 01:20 PM, Prasun Gera
wrote:<br>
</div>
<blockquote
cite="mid:CAFLz+B=2WwqMLyNLoSLRSC9LBrNCAbHybz15dXs9V7aMrYek1w@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
class=""><br>
</span>Keys can be generated in migration in two ways: by
the migration web UI<br>
or by sssd. I'm guessing you were unaware of this second
method and that<br>
is how the keys are being created.<br>
<span class=""><br>
</span></blockquote>
<div><br>
</div>
<div>That's what I suspected too. But it doesn't look like
SSSD is generating keys. At least not right away. I SSHed
to one of the clients with ipa-client installed as well as
to the ipa-server, and that didn't change anything right
away. That's what I was trying to figure out. i.e Which
event triggers key generation ?</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'd
suggest using nss_ldap over NIS. You can also manually
configure<br>
Kerberos and have basic functionality as long as nscld
doesn't drive you<br>
crazy.<br>
</blockquote>
<div><br>
</div>
<div>Thanks. I'll look into it.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
class=""><br>
</span>It's not the encryption type, it is how it is
encoded in 389-ds. When<br>
you migrated the passwords they were stored as
{crypt}hash. When the<br>
password is changed in 389-ds it becomes {SSHA}hash. The
NIS<br>
configuration for slapi-nis only provides those passwords
prefixed with<br>
{crypt} (because NIS can only grok that format). </blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span
class=""><font color="#888888"><br>
rob<br>
</font></span></blockquote>
<div><br>
</div>
<div>Yeah that sounds like a possible fix, although a less
than ideal one. Is it possible to change it back to {SSHA}
after all the clients have been migrated suitably ? How
would one force all the existing users' passwords to be
converted to {SSHA} once slapi-nis is no longer needed ? </div>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
The idea is that you tel lall the users to either login via
migration page or via SSSD.<br>
If your server is in a migration mode the migration page should be
available and SSSD should detect that server is in migration mode.<br>
In this case any authentication via SSSD will end up creating proper
hashes for Kerberos. I suspect this is when the conversion of the
LDAP hashes happens too.<br>
You suggested that this is not the case but I am not sure that the
test was 100 correct.<br>
<br>
Please try:<br>
- check that migration mode is on<br>
- check that user does not have kerberos password only LDAP hash
from NIS migration<br>
- ssh into a box that runs SSSD with such user, authenticate<br>
As a result you should see Kerberos hash created for this user and I
suspect the LDAP hash is converted at the same time. <br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
</body>
</html>