[Freeipa-users] Web UI plugins or other extensions

[Hugh]

All,

We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS
6.5. We've set up synching between our IPA and AD and that seems to be
working. What we'd like to do now is allow admins when they're creating
users in IPA to be able to set those users up for synching to AD with
the web UI without having to drop to the command line or edit LDAP
directly. As you know, in order to synch from IPA->AD, you need to add
the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount
attributes. However, those attributes/class are not in the web UI by
defauly and from what I can see, our version of ipa-server/DS does not
have support for web UI plugins. Is that true? Is there any way to be
able to set a user to be synched via the web UI?

Thanks,

Hugh

[Petr Vobornik]

Post by Hugh
All,
We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS
6.5. We've set up synching between our IPA and AD and that seems to be
working. What we'd like to do now is allow admins when they're creating
users in IPA to be able to set those users up for synching to AD with
the web UI without having to drop to the command line or edit LDAP
directly. As you know, in order to synch from IPA->AD, you need to add
the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount
attributes. However, those attributes/class are not in the web UI by
defauly and from what I can see, our version of ipa-server/DS does not
have support for web UI plugins. Is that true? Is there any way to be
able to set a user to be synched via the web UI?
Thanks,
Hugh

Hello Hugh,

it could be done in 3.0 by direct manipulation of
/usr/share/ipa/ui/user.js Doing that is ugly and breaks on rpm upgrades.
IIUC, the goal would be to simulate CLI (API)call:

$ ipa user-mod bbar --addattr='objectclass=ntuser'
--setattr='ntUserDomainId=foo'--setattr='ntUserDomainId=True'

Adding ntUserDomainId and ntUserDomainId is easy - it's just one
declaration in the list of fields. But adding the objectclass isn't,

Current pattern is that the object classes(which are not added by
default) are added in ipalib backend plugin if attribute is present in
the mod list for the first time for the object.

I would discourage to do that in Web UI. But in theory it can be done.
One has to add multivalued field named objectclass and then he can add
new ones and delete others. But this is bad UX. Better would be to add
the objecclass attr on demand on update but it requires direct
modification of update code which is more difficult (don't know it from
top of my head).

HTH

[Dmitri Pal]

Post by Petr Vobornik

Post by Hugh
All,
We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS
6.5. We've set up synching between our IPA and AD and that seems to be
working. What we'd like to do now is allow admins when they're creating
users in IPA to be able to set those users up for synching to AD with
the web UI without having to drop to the command line or edit LDAP
directly. As you know, in order to synch from IPA->AD, you need to add
the ntuser objectclass and the ntUserDomainId and ntUserCreateNewAccount
attributes. However, those attributes/class are not in the web UI by
defauly and from what I can see, our version of ipa-server/DS does not
have support for web UI plugins. Is that true? Is there any way to be
able to set a user to be synched via the web UI?
Thanks,
Hugh

Hello Hugh,
it could be done in 3.0 by direct manipulation of
/usr/share/ipa/ui/user.js Doing that is ugly and breaks on rpm
$ ipa user-mod bbar --addattr='objectclass=ntuser'
--setattr='ntUserDomainId=foo'--setattr='ntUserDomainId=True'
Adding ntUserDomainId and ntUserDomainId is easy - it's just one
declaration in the list of fields. But adding the objectclass isn't,
Current pattern is that the object classes(which are not added by
default) are added in ipalib backend plugin if attribute is present in
the mod list for the first time for the object.
I would discourage to do that in Web UI. But in theory it can be done.
One has to add multivalued field named objectclass and then he can add
new ones and delete others. But this is bad UX. Better would be to add
the objecclass attr on demand on update but it requires direct
modification of update code which is more difficult (don't know it
from top of my head).
HTH

But let us step back and ask the question why do you need to create the
users you sync manually first?
The users in a specific OU will be synced anyways without you manually
creating them in IPA.
So this is unclear why the whole thing is actually needed.
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Hugh]

Post by Dmitri Pal
But let us step back and ask the question why do you need to create the
users you sync manually first?
The users in a specific OU will be synced anyways without you manually
creating them in IPA.
So this is unclear why the whole thing is actually needed.

What we'd like to do is have admins create users in IPA via the web
interface (or CLI, if they're so inclined) and add them to an IPA group
then have those users synched over to our AD environment, so those users
can log into their Windows workstations. We'd like to avoid duplicate or
unnecessary effort in terms of creating users. More steps to a process =
more likelihood of mistakes.

We'd like to create the users in IPA so that we're consistent in
everyone using the IPA web interface to manage their user accounts.

Thanks,

Hugh

[Dmitri Pal]

Post by Hugh

Post by Dmitri Pal
But let us step back and ask the question why do you need to create the
users you sync manually first?
The users in a specific OU will be synced anyways without you manually
creating them in IPA.
So this is unclear why the whole thing is actually needed.

What we'd like to do is have admins create users in IPA via the web
interface (or CLI, if they're so inclined) and add them to an IPA group
then have those users synched over to our AD environment, so those users
can log into their Windows workstations. We'd like to avoid duplicate or
unnecessary effort in terms of creating users. More steps to a process =
more likelihood of mistakes.
We'd like to create the users in IPA so that we're consistent in
everyone using the IPA web interface to manage their user accounts.
Thanks,
Hugh

Will all users created via IPA interface synched to AD?
Is there any harm to make all users be created with the attributes
mentioned earlier in this thread?
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Hugh]

Post by Dmitri Pal
Will all users created via IPA interface synched to AD?
Is there any harm to make all users be created with the attributes
mentioned earlier in this thread?

Almost all. We have some users that will be role accounts for various
pieces of software. It's fine with me if all users by default get those
attributes and for those that shouldn't we can manually go back and
remove the object/attributes.

Hugh

[Dmitri Pal]

Post by Hugh

Post by Dmitri Pal
Will all users created via IPA interface synched to AD?
Is there any harm to make all users be created with the attributes
mentioned earlier in this thread?

Almost all. We have some users that will be role accounts for various
pieces of software. It's fine with me if all users by default get those
attributes and for those that shouldn't we can manually go back and
remove the object/attributes.
Hugh

I think you can start with adding ntUser object class into the list of
the object classes in the IPA configuration in UI. That would apply it
to the new entries automatically.
If that does not work it is probably a bug. If it works you will have
the object class right there.

Next step is creating attributes
- ntUserDomainId - I wonder whether it can be auto-populated using
managed entry or CoS configuration in DS. If that works it will be a
config change rather than a code change which means it will survive
upgrades (most likely).
- ntUserCreateNewAccount - should be set to true AFAIU and I wonder if
it can be set to true using same managed entry or CoS mechanism.

I am not saying that would work but that might work and would avoid
doing code changes.
If you willing to do code changes than it should be possible to just
update the user plugin to autopopulate the entries with these
attributes. But that would definitely blow up during upgrade.
--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Hugh]

Post by Dmitri Pal
I think you can start with adding ntUser object class into the list of
the object classes in the IPA configuration in UI. That would apply it
to the new entries automatically.

How is that done? I'd rather not have to tweak the package files, since
that will cause upgrades to be problematic, as you and Petr said.

Post by Dmitri Pal
If that does not work it is probably a bug. If it works you will have
the object class right there.
Next step is creating attributes
- ntUserDomainId - I wonder whether it can be auto-populated using
managed entry or CoS configuration in DS. If that works it will be a
config change rather than a code change which means it will survive
upgrades (most likely).
- ntUserCreateNewAccount - should be set to true AFAIU and I wonder if
it can be set to true using same managed entry or CoS mechanism.
I am not saying that would work but that might work and would avoid
doing code changes.

I couldn't find any decent documentation on managed entries or class of
service functionality. Can you point me in the right direction?

Post by Dmitri Pal
If you willing to do code changes than it should be possible to just
update the user plugin to autopopulate the entries with these
attributes. But that would definitely blow up during upgrade.

Yeah, that's pretty far down on the list of options for this project.
But, you never know ...

Hugh

[Dmitri Pal]

Post by Hugh

Post by Dmitri Pal
I think you can start with adding ntUser object class into the list of
the object classes in the IPA configuration in UI. That would apply it
to the new entries automatically.

How is that done? I'd rather not have to tweak the package files, since
that will cause upgrades to be problematic, as you and Petr said.

Log into UI. Go to IPA Server -> Configuration.
See default user objectclasses, add a new one: ntUser.
Save configuration. Add a new user in UI or command line. Check his
object classes with --raw using command line. Is should now that an
entry has a new object class applied to it.

But I just checked the schema
objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape
defined objectclass' SUP top MUST ( ntUserDomainId ) MAY ( description $
l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $
ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $
ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $
ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $
ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $
ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId
$ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $
ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $
ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' )


ntUserDomainId is a required attribute so IPA will be broken.
To overcome it you might want to make it non mandatory i.e.


objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape
defined objectclass' SUP top MAY ( ntUserDomainId $ description $ l $ ou
$ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $
ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $
ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $
ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $
ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $
ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId
$ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $
ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $
ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' )

It can be found in the 50ns-directory.ldif

Post by Hugh

Post by Dmitri Pal
If that does not work it is probably a bug. If it works you will have
the object class right there.
Next step is creating attributes
- ntUserDomainId - I wonder whether it can be auto-populated using
managed entry or CoS configuration in DS. If that works it will be a
config change rather than a code change which means it will survive
upgrades (most likely).
- ntUserCreateNewAccount - should be set to true AFAIU and I wonder if
it can be set to true using same managed entry or CoS mechanism.
I am not saying that would work but that might work and would avoid
doing code changes.

I couldn't find any decent documentation on managed entries or class of
service functionality. Can you point me in the right direction?

http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice.html
http://www.port389.org/docs/389ds/design/managed-entry-design.html

But a quick look does not seem to render what we need to do here.

So here is a workaround.

Create a script that will using CLI. List all the users that have ntUser
object class but do not have ntUserDomainId set.
If you find such entries set proper attributes using ipa user-mod command.

Run it as a cron job every 5 min or so.

You can also make it smarter in future to deal with your special cases.
For example if your special users follow some naming convention you can
instead of adding attributes strip the object class.


This is the best I was able to come up with :-)

Post by Hugh

Post by Dmitri Pal
If you willing to do code changes than it should be possible to just
update the user plugin to autopopulate the entries with these
attributes. But that would definitely blow up during upgrade.

Yeah, that's pretty far down on the list of options for this project.
But, you never know ...
Hugh

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Rob Crittenden]

Post by Dmitri Pal

Post by Hugh

Post by Dmitri Pal
I think you can start with adding ntUser object class into the list of
the object classes in the IPA configuration in UI. That would apply it
to the new entries automatically.

How is that done? I'd rather not have to tweak the package files, since
that will cause upgrades to be problematic, as you and Petr said.

Log into UI. Go to IPA Server -> Configuration.
See default user objectclasses, add a new one: ntUser.
Save configuration. Add a new user in UI or command line. Check his
object classes with --raw using command line. Is should now that an
entry has a new object class applied to it.
But I just checked the schema
objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape
defined objectclass' SUP top MUST ( ntUserDomainId ) MAY ( description $
l $ ou $ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $
ntUserFlags $ ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $
ntUserParms $ ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $
ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $
ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $
ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId
$ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $
ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $
ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' )
ntUserDomainId is a required attribute so IPA will be broken.
To overcome it you might want to make it non mandatory i.e.
objectClasses: ( 2.16.840.1.113730.3.2.8 NAME 'ntUser' DESC 'Netscape
defined objectclass' SUP top MAY ( ntUserDomainId $ description $ l $ ou
$ seeAlso $ ntUserPriv $ ntUserHomeDir $ ntUserComment $ ntUserFlags $
ntUserScriptPath $ ntUserAuthFlags $ ntUserUsrComment $ ntUserParms $
ntUserWorkstations $ ntUserLastLogon $ ntUserLastLogoff $
ntUserAcctExpires $ ntUserMaxStorage $ ntUserUnitsPerWeek $
ntUserLogonHours $ ntUserBadPwCount $ ntUserNumLogons $
ntUserLogonServer $ ntUserCountryCode $ ntUserCodePage $ ntUserUniqueId
$ ntUserPrimaryGroupId $ ntUserProfile $ ntUserHomeDirDrive $
ntUserPasswordExpired $ ntUserCreateNewAccount $ ntUserDeleteAccount $
ntUniqueId) X-ORIGIN 'Netscape NT Synchronization' )
It can be found in the 50ns-directory.ldif

Post by Hugh

Post by Dmitri Pal
If that does not work it is probably a bug. If it works you will have
the object class right there.
Next step is creating attributes
- ntUserDomainId - I wonder whether it can be auto-populated using
managed entry or CoS configuration in DS. If that works it will be a
config change rather than a code change which means it will survive
upgrades (most likely).
- ntUserCreateNewAccount - should be set to true AFAIU and I wonder if
it can be set to true using same managed entry or CoS mechanism.
I am not saying that would work but that might work and would avoid
doing code changes.

I couldn't find any decent documentation on managed entries or class of
service functionality. Can you point me in the right direction?

http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice.html
http://www.port389.org/docs/389ds/design/managed-entry-design.html
But a quick look does not seem to render what we need to do here.
So here is a workaround.
Create a script that will using CLI. List all the users that have ntUser
object class but do not have ntUserDomainId set.
If you find such entries set proper attributes using ipa user-mod command.
Run it as a cron job every 5 min or so.
You can also make it smarter in future to deal with your special cases.
For example if your special users follow some naming convention you can
instead of adding attributes strip the object class.
This is the best I was able to come up with :-)

Post by Hugh

Post by Dmitri Pal
If you willing to do code changes than it should be possible to just
update the user plugin to autopopulate the entries with these
attributes. But that would definitely blow up during upgrade.

Yeah, that's pretty far down on the list of options for this project.
But, you never know ...

I think this would be fairly easily done in a plugin without having to
mess with configuration or changing schema. SEe
http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf slide 17.

Yes, this doc is for 3.3 but the coding part should still apply to 3.0
in this limited case.

I suggest this because:
- you don't mind that the UI doesn't show the fields
- you don't mind that this applies to all new users
- you want it to persist through upgrades

rob