[Freeipa-devel] User life cycle: question regarding the design

thierry bordaz tbordaz at redhat.com
Wed May 21 14:01:33 UTC 2014


On 05/20/2014 10:30 PM, Martin Kosek wrote:
> I am sharing the question below with the list as I think the 
> information is useful and relevant for everyone interested in this 
> feature. See answers in the text.
>
> On 05/20/2014 06:26 PM, thierry bordaz wrote:
>> Hello Martin, Petr,
>>
>>     I implemented 'user-add --to-stage' in a very simple way. 
>> Basically rather
>>     than filling the 'accounts' container it fills the 'staged users' 
>> container.
>>     It helped me to start digging into the code.
>>
>>     Now I am looking at details of this entry. Especially the attributes
>>     present when the entry is in staging container. So far, the entry is
>>     looking like:
>>
>>         ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" -w
>>         Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb1
>>         dn: uid=tb1,cn=staged
>>         users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d
>>           c=redhat,dc=com
>>         displayName: tb1 tb1
>>         cn: tb1 tb1
>>         objectClass: top
>>         objectClass: person
>>         objectClass: organizationalperson
>>         objectClass: inetorgperson
>>         objectClass: inetuser
>>         objectClass: posixaccount
>>         objectClass: krbprincipalaux
>>         objectClass: krbticketpolicyaux
>>         objectClass: ipaobject
>>         objectClass: ipasshuser
>>         objectClass: ipaSshGroupOfPubKeys
>>         loginShell: /bin/sh
>>         initials: tt
>>         gecos: tb1 tb1
>>         sn: tb1
>>         homeDirectory: /home/tb1
>>         uid: tb1
>>         mail: tb1 at idm.lab.bos.redhat.com
>>         krbPrincipalName: tb1 at IDM.LAB.BOS.REDHAT.COM
>>         givenName: tb1
>>         ipaUniqueID: 5556123c-e036-11e3-9915-001a4a104ecd
>>         uidNumber: 646400005
>>         gidNumber: 646400005
>>         memberOf:
>> cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=
>>           com
>>
>>
>>     As you can see it contains extra objectclasses and some 
>> attributes are set
>>     (like uidNumber or gidNumber).
>>     According to the design that the entry should rather look like:
>>
>>
>>     dn: uid=tb1,cn=staged 
>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d
>>       c=redhat,dc=com
>>     displayName: tb1 tb1
>>     cn: tb1 tb1
>>     objectClass: top
>>     objectClass: organizationalperson
>>     objectClass:krbprincipalaux
>>     objectClass: posixaccount
>>     loginShell: autogenerated
>>     sn: tb1
>>     homeDirectory: /home/tb1
>>     uid: tb1
>>     krbPrincipalName: tb1 at IDM.LAB.BOS.REDHAT.COM
>>     uidNumber: -1
>>     gidNumber: -1
>>
>>     Is that correct ?
>
> user-add sets the uidNumber and gidNumber to -1, meaning that these 
> numbers should be autogenerated by a plugin. If the plugin scope is 
> updated according to design to disregard staging users container, the 
> number should stay -1 until the entry is really moved to active users 
> container.
>
> The same applies for ipaUniqueId, just the generation triggering text 
> is "autogenerate".
>
>
>>     Then when the entry get activated ('ipa user-activate tb1 
>> --from-stage), we
>>     should have the attribute being generated
>>     uidNumber/gidNumber/ipaUniqueId... My understanding is that those
>>     attributes should be generate by DS plugins when the entry is 
>> moved to
>>     'accounts' container. So playing with plugin scope would help to 
>> have
>>     staged users without all these attributes and 'accounts' users 
>> with them.
>
> Right.
>
>>
>>     What is not clear to me is the chapter related to the 
>> 'placeholders'. My
>>     understanding is that it should be a kind of template defining 
>> how to fill
>>     attribute values. I am looking for some code/doc dealing with 
>> placeholders
>>     but I do not know where to start from. Do you know any pointers 
>> on this.
>
> I tried to write down the reasons for using placeholders in this section:
> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholders
>
> Placeholder allows provisioning systems to specify only some 
> attributes of for example posixAccount objectclass while not having to 
> fill all the MUST attributes.
>
> I think the example with filled "homeDirectory: /home/tuser" tells it 
> all - homeDirectory is filled, other attributes are left for FreeIPA 
> to generate based on it's settings.
>
> As for UID and GID, you do not need to do anything - "-1" already 
> means autogenerate the values. Attributes not controlled by a plugin 
> needs to be controlled by the command that moves user from staging 
> users to active users - following list shows how should be the values 
> generated:

Hello,

    Thanks for all these detailed descriptions.
    Just to be sure to be on the same page, here is my understanding of
    the provisioning templates and placeholder definitions. An
    administrator can provide a provisioning template. I suppose it
    would be a file containing a lines of placeholder definitions.

      * Where is located the template file ? Is there a standard
        repository where templates are put ? (somewhere under /etc/ipa/* ?)
      * Is there an already defined syntax for the provisionning
        template. ('$' is separator attr/value, %{<attr>} is substitute
        pattern...). If not, is it possible to user ':<space> ' as
        separator ?
      * What is the priority. The user can provide the 'homeDirectory'
        through different methods. Is it ok to use the following order:
          o the CLI option
          o the provisionning template
          o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX)

    For example, if it exists the provisioning template:
    /etc/ipa/provisioning/shell-user.template

        roomnumber$-2
        homeDirectory$/home/net/shell-%{uid}
        loginShell$?shell-plugin-autogenerate?

    the command: ipa user-add tuser
    --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a
    staging entry:

    dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
    ...
    roomNumber: 1234
    homeDirectory: /tmp/tuser
    loginShell: shell-plugin-autogenerate

    Then a private DS plugin (catching shell-plugin-autogenerate)
    generate the loginShell value when the entry becomes active.


    the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would
    create a staging entry:

    dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
    ...
    roomNumber: -2
    homeDirectory: /tmp/tuser
    loginShell: shell-plugin-autogenerate



    the command: ipa user-add tuser --to-stage would create a staging entry:

    dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
    ...
    roomNumber: -2
    homeDirectory: /home/net/shell-tuser
    loginShell: shell-plugin-autogenerate


    In case the provisioning template does not define 'homeDirectory',
    then the created entry would take the value from the ipa config
    definition:
    dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
    ...
    roomNumber: -2
    homeDirectory: /home/tuser
    loginShell: shell-plugin-autogenerate

    best regards
    thierry

>
> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholder_Definition 
>
>
> HTH,
> Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140521/8d0a0ebe/attachment.htm>


More information about the Freeipa-devel mailing list