On 05/27/2014 02:19 PM, Martin Kosek wrote:
On 05/27/2014 02:16 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote:
On 05/27/2014 11:53 AM, Jan Cholasta wrote:
On 27.5.2014 11:14, thierry bordaz wrote:
Hello,
Me again !!!
Thanks to all your inputs, the discussion about User_life_cycle
clarified a lot workflow/command verbs.
Now I have a doubt about what would be an entry in staging
(objectclass/attribute). Also I wonder if ipa CLI (ipa user-add
--stage), would be the only support way to create stage entry.
An active entry is looking like (with krb* attributes if the
userpassword is defined):
dn:
uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
displayName: tb15 tb15
cn: tb15 tb15
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
gecos: tb15 tb15
sn: tb15
homeDirectory: /home/tb17
uid: tb17
mail: t...@idm.lab.bos.redhat.com
krbPrincipalName: t...@idm.lab.bos.redhat.com
givenName: tb15
initials: tt
ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd
uidNumber: 646400009
gidNumber: 646400009
mepManagedEntry:
cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,
dc=com
memberOf:
cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=
com
nsAccountLock: False
A staged entry created by 'ipa user-add --stage' may look like the
following. This kind of entry is easy to activate 'ipa user-unstage'
dn: uid=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
dc=redhat,dc=com
displayName: tb20 tb20
cn: tb20 tb20
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
uidNumber: -1
ipaUniqueID: autogenerate
gidNumber: -1
gecos: tb20 tb20
sn: tb20
homeDirectory: /home/tb20
uid: tb20
mail: t...@idm.lab.bos.redhat.com
krbPrincipalName: t...@idm.lab.bos.redhat.com
givenName: tb20
initials: tt
nsAccountLock: True
Now are we going to support the following entries for 'ipa user-unstage'
dn: cn=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
dc=redhat,dc=com
objectClass: top
objectClass: person
sn: tb20
cn: tb20
nsAccountLock: True
or
dn: uid=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
dc=redhat,dc=com
objectClass: top
objectClass: person
objectClass: posixAccount
sn: tb20
cn: tb20 tb20
uid: tb20
uidNumber: -1
gidNumber: -1
homeDirectory: /home/tb20
nsAccountLock: True
thanks
thierry
IIUC unstaging a user will do something like this:
staged_user = ldap.get_entry(staged_dn, ['*'])
api.Command.user_add(**staged_user)
So IMO virtually any kind of entry should be supported in the staging tree.
The workflow will be different from what Jan suggested, but yes, we should
support wide range of entries. I suspect some provisioning systems may even
write entries with different RDN - i.e. with CN for example.
About the unstaging - we already spoke about it, we will need to consolidate
current operations in user-add and user-mod in common functions that will be
called by those commands and user-unstage command.
I imagine user-unstage command would then do:
1) MODRDN from staged users to active users
2) Update user with the same default as user-add, if RDN is different than UID,
it should be converted to UID
I wonder how should be the step 2) authorized LDAP-wise. The easiest way to
make it happen is to give the operator making unstage operator write
permission/ACI to active users, but it may not be the ideal way - we would want
to limit the write permission only to the actual unstage operation of the
particular user... Simo, what is your take on this?
My take is that users need to be created with uid=<name> as the RDN or
the operation should be refused. We have still some rules for what our
users need to look like.
Simo.
Hm, I was more relaxed in my original RFE and allowed records like:
dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: organizationalperson
cn: Test User
sn: User
nsAccountLock: True
RDN is just part of the problem though - note that the user-unstage command
would also need to generate the default attributes for the user (including
kerberos principal ones) - and we need to somehow authorize that LDAP modify
operation.
Martin
In short, a large kind of entries should be supported in staging and we
can not assum that provisioning in staging was done through FreeIPA CLI.
Now if an entry was not created by FreeIPA CLI ('ipa user-add --stage')
it could be impossible to update/unstage the entry with FreeIPA CLI .
For example with those two entries. 'ipa user-mod TestUser --stage' or
'ipa user-unstage TestUser' are unable to select the correct entry
# Created from provisioning system
dn: cn=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: organizationalperson
objectClass: posixAccount
cn: Test User
sn: User
uid: xxx
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1
nsAccountLock: True
# Created from the FreeIPA CLI
dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: organizationalperson
objectClass: posixAccount
cn: Test User
sn: User
uid: Test User
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1
nsAccountLock: True
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
