[Freeipa-devel] Please review: Bug 459729 - Windows sync support in IPA - account disable and force sync

[Rob Crittenden]

Rich Megginson wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=459729
> Resolves: bug 459729
> Bug Description: Windows sync support in IPA - account disable and force 
> sync
> Reviewed by: ???
> Files: see diff
> Branch: HEAD
> Fix Description: Add support for account disable sync and force sync
> * Account disable sync - AD uses the userAccountControl attribute 
> ACCOUNTDISABLE value http://support.microsoft.com/kb/305144
> We have to sync that with the nsAccountLock attribute used by DS.  In 
> IPA, nsAccountLock is a virtual attribute generated by the membership of 
> the user or group in the cn=inactivated group (or enabled if in the 
> cn=activated group or not in any group - the account is enabled if 
> nsAccountLock is not present).  The sync can be done in 1 of 4 ways, 
> with the config attribute ipaWinSyncAcctDisable:
>    *  none - no account disable sync occurs
>    * to_ad - account disable is only synced from IPA to AD, not from AD 
> to IPA
>    * to_ds - account disable is only synced from AD to IPA, not from IPA 
> to AD
>    * both - account disable is synced in both directions
> I added some code to let the plugin find the cn=inactivated and 
> cn=activated groups dynamically
> * Force Sync - by default, the DS will only sync existing IPA users if 
> they have the ntUser objectclass, and the ntUserDomainID set to the 
> Windows user ID (e.g. the samAccountName).  With the config attribute 
> ipaWinSyncForceSync set to "true", any IPA user that has a matching 
> account in Windows will be forced to be in sync - the IPA user will have 
> the ntUser objectclass added automatically, and the ntUserDomainID set 
> to the matching account samAccountName value.  The existing winsync code 
> already handles adding ntUserDomainID, so the ipa winsync plugin just 
> has to add ntUser.
> Platforms tested: Fedora 9
> Flag Day: no
> Doc impact: no
> https://bugzilla.redhat.com/attachment.cgi?id=317807&action=diff

Assuming I'm reading this properly, you don't need to add users to the 
activated group in order to activate them. This group is for override 
purposes (has a lower cosPriority).

We have it so that if a group is inactivated but you want one or more 
members to be active you can add them to the activated group. This will 
override the group membership in an inactivated group.

By putting unlocked users into activated you will be preventing them 
from being inactivated.

Is parse_acct_disable() called for each request or only during 
initialization? It is a little hard to tell in the context of this 
patch. I mention it because you end up doing 4 string compares every 
time it runs though.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20080930/d9bda838/attachment.bin>