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
