Dmitri Pal wrote:
> On 02/25/2015 05:39 PM, Hugh wrote:
>> On 2/25/2015 3:11 PM, Dmitri Pal wrote:
>>> 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
> 
>>
>>> 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 :-)
>>
>>> 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

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to