Pavel Zuna wrote:
Rob Crittenden wrote:
Pavel Zuna wrote:
Example output of migration plugin:
I have a DS server setup on a VM at 192.168.122.4 and I made a few
tweaks to show how errors are reported.
# ipa migrate-ds ldap://192.168.122.4:389
Password:
Enter password again to verify:
---
migrate-ds:
---
Migrated:
users: pzuna, mnagy
groups: skupina1, skupina2, skupina3
Errors:
user: mnagy: Kerberos principal mn...@pzuna already exists. Use
'ipa user-mod' to set it manually.
group: accounting managers: This entry already exists
group: hr managers: This entry already exists
group: qa managers: This entry already exists
group: pd managers: This entry already exists
--
Passwords have been migrated in pre-hashed format. IPA is unable to
generate Kerberos keys unless provided with clean text passwords.
All migrated users need to login at
http://your.domain/ipa/migration/ before they can use their Kerberos
accounts.
I didn't try it yet, but this might also work for IPAv1-IPAv2
migration.
Pavel
I have some concerns with this. Rather than presenting a user
password change page this enables basic-auth like kerberos negotiate
fallback and uses the username/password presented there to do the
password reset. I thought we had discussed actually presenting a form
to the user to prompt for this information.
One of our goals is to promote the usage of single sign-on using
kerberos. Enabling the password fallback can be practical and needed in
some cases but I think by default we want to leave it off.
According to this page, we need to use form base authentication to
replay the password:
https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA
At first, I thought that form base authentication is a normal HTML
form, but the term is actually pretty ambiguous and there is no way to
replay HTML form data.
Without the kerberos negotiate fallback on, replaying the password is
useless. There's no replaying going on actually.
So, either:
1) we set negotiate fallback ON and use password replaying, after
migration page, the user is redirected to his kerberos protected
self-service page without the need to enter his password twice
But this should be done once during his migration.
Next time he gets to this page if he does not have a ticket and tries to
log in using password the server should say: you already migrated use
use kinit to obtain kerberos ticket.
Next time he tries to get to this page already having a ticket the page
should not be displayed at all and he should be redirected to to the
self service screen.
Agree?
2) we only use the password migration page to generate kerberos keys
and tell users to use kinit from then on.
The function get_base_dn() needs some error handling. I'm not sure
how this will blow up if the LDAP server is down but it won't be
pretty, it assumes that a namingcontext is returned, etc.
For the migration there is a typo in pwd_migration_msg, clean text
instead of clear text.
Ok, I'm going to fix those asap.
Why are you duplicating the user_add functionality instead of calling
api.Command['user_add']?
Same with groups, why not user the gropu_add and group_add_member
methods?
Because it would be too much overhead.
Migrating a single user would mean:
- extract data from DS and convert it to the format accepted by IPA
commands
- user_add (2 ldap operations: RETRIEVE ipaConfig, ADD)
- user_mod (2 ldap operations: RETRIEVE, MODIFY)
Now that's 4 operations instead of 1 and a lot of needless processing.
It's even worst for groups, because we also have to do group_add_member.
On the other hand, migration is a one-shot process, so we don't have
to be concerned about speed/server load that much and using IPA
commands has its advantages.
rob
Pavel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Thank you,
Dmitri Pal
Engineering Manager IPA project,
Red Hat Inc.
---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
