Hi Aurelien,

> - The infra team wants to do a couple things that FreeIPA does not support 
> out of the box,
> like enforcing 2FA for specific services such as sudo, so we need to think 
> about how we
> want to do it.

Alexander Bokovoy created the feature https://github.com/SSSD/sssd/issues/5482. 
Once implemented you will be able to Kerberos check authentication indicators 
like OTP from a PAM service.

> - Also, using kinit with 2FA tokens proved to be more complex than we'd like 
> it to
> be.

The FreeIPA and Kerberos team have been aware of the usability issue for a 
while.

For those how are not familiar with implementation details: Kerberos 2FA/OTP 
requires an existing credential cache (armor cache) to secure 2FA. SSSD 
enrolled systems and FreeIPA webui have ways to create an armor cache. For 
plain kinit a user has to perform "kinit -n -c armor.ccache" first to get a 
ccache for wellknown anymous user, then use that ccache to do "kinit -T 
armor.ccache". For technical reasons the first kinit needs the internal CA 
certificate of FreeIPA.

The Kerberos team is working on a simpler approach based on SPAKE, but it's not 
finished yet. https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-09

> - We're trying out a more continuous approach to importing accounts, because 
> a full
> run takes 3 days and during the migration we'll want to run the import script 
> without
> having a 3 days downtime.

You have a couple of options to speed up migration and improve performance:

You could disable memberOf plugin during migration. According to an old 
benchmark it can make provisioning up to 20 times faster. You need to restart 
DS after you have disabled or enabled the plugin and run a memberOf task to 
fixup attributes, 
https://www.freeipa.org/page/V4/Performance_Improvements#Memberof_plugin 

It might be worth a shot to remove a couple of indices during migration and 
re-create them afterwards. This could speed up migration a bit, too.

You could a two-pass migration: First migrate all users to the new instance 
while the old FAS is online. Then shutdown old FAS and only migrate users 
entries that have changed since the initial migration. You can use the 
modificationTimestamp for that. Every entry in DS has a modificationTimestamp 
attribute. It's an operational attribute which is maintained by the server. 

Do you need the compat tree or NIS? slapi-nis and compat tree require 
additional resources. You can disable the features with ipa-compat-manage and 
ipa-nis-manage commands. You need to disable them on each server separately and 
restart DS.

Christian
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to