[Freeipa-devel] User life cycle: authentication and preserved attributes

[thierry bordaz]

Hello,

    Thanks for all you feedbacks and help about which attributes to
    preserved and how to limit authentication (simple and krb) to Active
    accounts, here are my understandings:

     1. Staging (container: cn=staged
        users,cn=accounts,cn=provisioning,SUFFIX)
        plugins scoping Staging:
          * ipa_pwd_extop (kerberos keys  generated)
        In order to prevent simple bind, there is pre-bind plugin or cos
        (nsAccoutLock: True).

          * provisioning constraints - no constraint when creating an entry
            but to be activated the entries in that container must have:
              o   'uid' RDN
              o have OC: posixaccount, ipaObject (MUST: cn, uid,
                uidNumber, gidNumber, homedirectory, ipaUniqueID)
          * ipa stageuser-add <login>
            It creates a stage entry with

                uidNumber: -1
                gidNumber: -1
                ipaUniqueID: autogenerate
                description: __no_upg__
                manager: checks that the DN is an active user
                userPassword/krb keys: if userPassword is set, krb keys
                are generated

          * ipa stageuser-add <login> --from-delete
            It possibly updates (MOD-delete) the deleted entry to delete
            the attributes:
              o userPassword
              o krb keys

            Then it moves (modrdn) the deleted entry to staging
            container where

                uidNumber: <unchanged, so it is preserved from the
                prevous active account>
                gidNumber: <unchanged, so it is preserved from the
                prevous active account>
                ipaUniqueID: <unchanged, so it is preserved from the
                prevous active account>
                description: __no_upg__ (to show there is not managed group)
                (Deleted entries have no userPassword nor krb keys)

          * ipa stageuser-activate <login>
            To be activated an entry must have:
              o 'uid' RDN
              o have OC: posixaccount, ipaObject (MUST: cn, uid,
                uidNumber, gidNumber, homedirectory, ipaUniqueID)
            It adds in the active container, a destination copy of a
            stage entry where

                uidNumber: <unchanged> (if it was '-1' DNA generates it)
                gidNumber: <unchanged> (if it was '-1' DNA generates it)
                ipaUniqueID: <unchanged> (if it was 'autogenerate' ipa
                uuid generates it)
                description: value __no_upg__ is removed
                DN syntax attributes are cleared (but kept for schema
                checking) except: manager, managedby and secretary
                (those values must be active DN entries)
                userPassword/krb keys: copied from source entry if they
                exists

            Then removes the source entry from the 'Staging' container.

          * ipa stageuser-find <login>
          * ipa stageuser-show <login>
          * ipa stageuser-mod <login>

                DN syntax attributes: checks that the DN is an active user

          * ipa stageuser-del <login>

     1. Active (container: cn=users,cn=accounts,SUFFIX)
        plugins scoping Staging:

          * ipa_pwd_extop (kerberos keys  generated)
          * attribute uniqueness (ipaUniqueID, uid, krbprincipalname,
            krbcanonicalName)
          * referential integrity
          * memberof
          * managed entries
          * ipa uuid

        In order to allow simple bind, there is pre-bind plugin or cos
        (nsAccoutLock: False).
        A new entry (user-add or stageuser-activate) is updated by DS
        plugins (UUID, memberof, managed entries, and DNA plugins)

          * ipa user-add <login>
          * ipa user-mod <login>
            DN syntax attributes: checks that the DN is an active user
          * ipa user-show <login>
          * ipa user-find <login>
          * ipa user-delete <login>
            The entry is moved (modrdn) to Delete container:
              o all memberships attributes updated by plugins (managed
                entries/memberof)
              o group members updated by referential integrity

            then updated (mod)
              o all DN syntax attributes are wiped except: manager,
                managedby, secretary
              o description: add __no_upg__ value
              o userPassword is deleted
              o kerberos keys are deleted
          * ipa user-undelete <login>
            The entry is possibly updated (MOD-delete) to delete attributes
              o userPassword (no simple bind on undeleted entry,
                requires to create a password)
              o kerberos keys (no kerberos bind on undeleted entry,
                requires to recreate user password)
            Then is moved (modrdn) to Active container

     1. Delete (container is cn=deleted users,cn=accounts,SUFFIX)
        plugins scoping Delete:

              * ipa_pwd_extop (not required as Delete account should not
                have userPassword nor krb keys)
              * attribute uniqueness (ipaUniqueID, uid,
                krbprincipalname, krbcanonicalName)

        In order to prevent simple bind (in addition to userPassword
        being cleared), there is pre-bind plugin or cos (nsAccoutLock:
        True).



    Thanks
    thierry




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140619/2416ed19/attachment.htm>