Jakub Hrozek wrote:
Hash: SHA1

(resending to the list, I accidentally replied to Rob only before..)

On 11/02/2010 04:24 AM, Rob Crittenden wrote:
Jakub Hrozek wrote:
Hash: SHA1


The second patch removes the /ipatest section that has been commented
out in ipa.conf anyway..plus, we don't ship /usr/share/ipatest anymore

Migration doesn't seem to be working. The migration page itself comes up
fine and prompts for data but when I enter the password of a migrated
user I don't seem to be getting valid kerberos keys. kinit doesn't work
in any case. It could also be that I'm tired. Does a migrated account
work for you?

It does for me -- or at least I think it's working. This is how I tested:
1) migrate users from LDAP using the migrate-ds plugin.
2) try kinit - preauth will fail
3) go to the migration page, enter username/password  This redirects me
to the ui page if the credentials are correct.
4) kinit for the user works now

This is on the current master + the two patches under review, on a F13
host migrating from 389 DS on another F13 machine.

I still can't get this to work on my F12 machine. The LDAP password is ok, I confirmed that with ldapsearch.

My process is as yours. I get redirected to the UI page which fails because I haven't done a kinit yet. I go do the kinit and that fails.

The KDC is logging:

Nov 08 15:48:48 panther.example.com krb5kdc[23964](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) NEEDED_PREAUTH: tus...@example.com for krbtgt/example....@example.com, Additional pre-authentication required Nov 08 15:48:50 panther.example.com krb5kdc[23964](info): preauth (timestamp) verify failure: Decrypt integrity check failed Nov 08 15:48:50 panther.example.com krb5kdc[23964](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) PREAUTH_FAILED: tus...@example.com for krbtgt/example....@example.com, Decrypt integrity check failed

I think the timestamp part is bogus, I think this just means the password is bad.

I noticed that krbPrincipalKey is getting migrated as well. If I delete this before trying the migration the password works.

I find it unlikely that this is related to your mod_wsgi conversion so I'm going to open a separate ticket on that and ack your changes.



This could be related to redoing the 389-ds password plugin as I did all
previous testing before we did the file split.

I also have two questions:
   1) how should exceptions be handled? In the patch, I only explicitly
handle exceptions that could happen very easily (like, password being
wrong, or the LDAP server down..). Anything else would just trigger 500
Server Error..

I think that's ok as long as we provide enough logging to point the
admin in the right direction.

   2) When playing with the migration command line plugin, I noticed that
it can only handle RFC2307bis groups (member: dn) and has the
objectclass for groups hardcoded to
"(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames))". I think
it would be worthwile (and easy, too!) to modify the plugin to accept
also RFC2307 schema and allow specifying a different objectclass
(posixGroup might come handy..). Thoughts?

Yes, that sounds like a good enhancement. Great idea.


(taken, since I was already poking at the plugin anyway)

Freeipa-devel mailing list

Reply via email to