- 1 15 Feb 2010
- 2 Technology Review
- 3 Anticipated User Complaints
- 4 Suggested Screen Content (Ideal)
- 5 Review of Current Screens
15 Feb 2010
- Need to avoid having nested firstboot screens
- Need to avoid having multiple ways to do the same thing
- UI vs command line vs config files
- Please only use one menu item, not two
- The basic pattern we had come up with was, "Have two paths, and ask the user a question to figure out which path they should go on and put them on it." (e.g., local account only, vs centrally-managed account are the two paths.)
- A better path would be, "Put the users on the most common path (local account only) and offerthem the option to also go on the alternative path."(which is how firstboot works today, but the language in the dialog is confusing to users.) The problem is, having three levels of dialogs is unacceptable from a usability standpoint. The challenge: can we come up with a way to have one dialog to configure both SSSD and the legacy way and have it not suck?
- The intent for the UI changes should be to reduce the complexity, support only those configurations most end-users care about and improve the end-user experience. The authconfig command line functionality will remain as is as to not break existing scripts for customers.
|Identity Technology||Authentication Technology||Recommended Implementation||Misc Notes|
|NIS||Kerberos||Legacy auth-config||should not call 'secure' because that's used to mean something else wrt NIS ('usually means you've set things up at the server so that clients can only read from certain maps (for example, 'passwd.adjunct', which is similar in purpose and use to /etc/shadow) if they send their request from privileged ports')|
|NIS||NIS||Legacy auth-config||far more common than NIS / shadow|
|Hesiod||Historically, Kerberos||Cut from UI||iastate / NCSU / MIT potential current users. iastate said it's fine to cut from UI, they don't need UI for it.|
|Smart Card (cert-based)||Smart Card (cert-based)||too difficult to manage without UI, can't drop.||will be in SSSD 6-12 months / smartcard/smartcard most common setup|
|Smart Card (cert-based)||Kerberos||too difficult to manage without UI, can't drop.||Least common setup, smart card enables you to get a krb ticket|
|???||Fingerprint||Cut from UI|
Anticipated User Complaints
- Have to know how user info maps to password. Legacy UI lets you select all the user info / password methods you want, and tries different combos until it finds something that works. The new way requires you explicitly state the user info + password mapping. (explicit mapping is less prone to accidental configuration thus more secure - less holes that could be broken through)
Suggested Screen Content (Ideal)
Tab 1: Identity & Authentication
- [ ] NIS
- [ ] Secure NIS (uses Kerberos)
- [ ] Winbind (Winbind for both)
[ ] Cache User Info
Tab 2: Advanced Options
- [ ] Homedir creation on login
- [ ] Enable local access control
- [ ] Password hash algorithm [ dropdown goes here | \/]
Review of Current Screens
Tab 1: User Info
- NIS (Should be listed #1)
- Winbind (Should be listed #2)
- Hesiod (Should be listed #3 or pulled. Talk to Nalin)
- Change "User Account Storage" to "User Account Database"
- Use the word password - not just for Kerberos password, but also LDAP password, NIS password, Winbind password
Tab 2: Password
- Kerberos (should be kept for NIS)
- LDAP (should be pulled)
- Smartcard (consider pulling, talk to Nalin, et. al.)
- Fingerprint (consider pulling)
- locally works by just installing the right package. GNOME About Me dialog handles.
- network - nobody reasonable uses this over the network
- Winbind (should be kept for winbind)
Tab 3: Options
- Cache user info KEEP
- uses nscd. Identity, not auth. Requires less nework trips if enabled - otherwise everytime you type 'ls' or 'ps ax' it uses a network trip to identify the username <=> uid mappings. Can't kill it. Has a higher-performance cache even though it gets staler / harder to flush / caches more stuff than SSSD does.
- Use shadow KILL
- this should be enabled. it removes the ability for non-root users to read your password hash.
- password hash login KEEP
- only useful for local users
- controls creation of new passwords
- folks in particular countries with particular regulations (including france?) government workers care about this
- local authorization sufficient KILL
- enable it by default
- auth sys accounts via network KILL
- disable it
- for example, apache accounts are not normally login enabled accounts anyway. this would let you auth it over the network.
- check access.conf during auth KEEP
- reword 'Enable local access control'
- create homedirs on first login KEEP
- 2 ways to do it, pam-make homedirs vs pam make homedirs dbus
- dbus method uses policykit/root, more capabilitity but currently issues with setting proper SELinux user context
- in the Create home directories for centrally-managed users... checkbox, I would drop the "centrally-managed" word because the setting does not differentiate between centrally-managed and local users.
- Instead of "Cache user information", name it "Enable the name service caching daemon" with the helper text of "Speeds up user lookups for NIS, HESIOD and Winbind domains" OR Drop it from the UI completely because with sssd caching and nscd caching there could be unexpected results.
- auto-detection of settings
- validity checking of server configurations
24 Feb 2010
I forgot to mention one additional feature in the discussion about LDAP. In the LDAP account settings, we need one more radio button. This button should specify the schema in use on the LDAP server. LDAP servers can provide UNIX users with schema rfc2307 or rfc2307bis, the difference being in how group memberships are looked up.
I recommend we add a radio button that reads:
* RFC 2307 (Select this if the server is OpenLDAP, 389 or similar) * RFC 2307bis (Select this if the server is FreeIPA or ActiveDirectory)
Internal to the sssd.conf, this is controlled by the "ldap_schema" option in the domain, and should be set to 'rfc2307' or 'rfc2307bis', respectively.