[Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page.

[Rob Crittenden]

Dmitri Pal wrote:
> Rob Crittenden wrote:
>> 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 mnagy at 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
>>> 2) we only use the password migration page to generate kerberos keys
>>> and tell users to use kinit from then on.
>> #2 is the way to go. We need to put up a simple form that has fields
>> for username, old password and 2 new passwords and a submit button. We
>> can't redirect them to the UI once we're done, as you point out. This
>> is fine IMHO as it is unlikely their browser is set up to use kerberos
>> anyway. We could redirect them to the login page, which will fail and
>> contain instructions on how to set up their browser and do a kinit. We
>> may need to modify the message on that page to contain specific info
>> for those migrating.
> 
> Why we can't call kinit (or equivalent) on their behalf as soon as we
> migrated them right away ourselves and then redirect then to the right
> place - self service page?

There is no way to trigger this AFAIK.

> Why make them fail? 

True, it isn't ideal but all users fail the first time in the browser as 
it is. There isn't a stable way to pre-configure the browser currently. 
It either involves directly modifying files in the firefox rpm which 
will both cause rpm verification issues and be lost when an upgrade is 
done. Or we have to run something on the client to fix their browser 
profile when we run ipa-client-install and this will only affect 
existing profiles (and won't take effect until any running browser is 
restarted).

There is a browser bug filed so one can configure a directory of 
additional settings to be read as sort of a global configuration cache. 
Once this is available we can write to one spot and pre-configure 
kerberos settings.

Similarly once the global NSS database is in place we can put the IPA CA 
cert there and be trusted by all browsers on the system.

> I assume that things like cfengine or puppet can be used to already
> precofigure browsers to know about IPA.

Probably but again it's a client-side issue and the browser profile 
needs to be updated. Definitely a possibility.

> So failing them and forcing them to use kinit manually sounds like a bad
> user experience approach to me.

Yup. But this is close to what happens with new users now. They kinit 
(or not), try to hit the UI and in FF 3.5 fail with a nasty error 
message about untrusted CA's. If they decide to continue they get a 
kerberos failed page and can run a little javascript program to 
configure the browser. This little program causes a hair-on-fire warning 
to pop up. Then they need to restart the browser to work.

> Do browsers support this? I understand that we would need to pass the
> ticket back so that the browser can store it in the key store on the
> client for future use?

No, and I don't think I want my browser to be writing to my ccache to be 
honest.

> If it is not possible I would suggest filing an RFE so that the browser
> can get the ticket from the application and store it on the user's machine.
> With kerberos now supporting S4U this might be a very valuable feature
> to have.

You can always file one and see what they say.

> Am I smoking something?

Well, wanting a nice user experience isn't a bad thing.

I sure could use a drink right now.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20091030/cade5246/attachment.bin>