[Freeipa-users] IPA winsync replication

Rich Megginson rmeggins at redhat.com
Mon Nov 25 23:57:37 UTC 2013 

On 11/25/2013 11:51 AM, Emil Petersson wrote:
> On 25 Nov 2013, at 17:21, Rich Megginson <rmeggins at redhat.com 
> <mailto:rmeggins at redhat.com>> wrote:
>
>> On 11/25/2013 08:14 AM, Emil Petersson wrote:
>>> Hi,
>>>
>>> I'm running FreeIPA 3.0 under RHEL6.4. I'm seeing some unexpected 
>>> behaviour with winsync replication.
>>>
>>> 1. I have a working winsync agreement, and users are synced correctly.
>>>
>>> 2. If a user already exists in in IPA when I sync it from AD, I'm 
>>> seeing the following in the dirsrv error logs:
>>>
>>>     [25/Nov/2013:14:29:03 +0000] NSMMReplicationPlugin - 
>>> windows_update_local_entry: failed to modify entry 
>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net - error 
>>> 21:Invalid syntax
>>>
>>>     I assume this is because the user already exists in dirsrv? Fine.
>>
>> No.  Error 21 is Invalid Syntax.  This means the format of the data 
>> in the attribute in AD is not correct for the given syntax.  For 
>> example, if the syntax is Integer, this means the data should be a 
>> valid integer.  However, AD allows data that violates LDAP syntax.
>>
>> Can you post the data from the AD entry that corresponds to 
>> uid=username,cn=users,cn=accounts,dc=domain,dc=net?  Please be sure 
>> to obscure any sensitive data.  I'd like to identify the data that is 
>> causing this problem.
>
> Certainly, here goes:
>
> dn: CN=Firstname 
> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=
>  domain,DC=com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> cn: Firstname Lastname
> sn: Lastname
> title: Sysadmin
> description: Employee
> physicalDeliveryOfficeName: XX-XX-XX
> telephoneNumber: +00 00 000 0
> facsimileTelephoneNumber: +00 00 000 0
> givenName: Firstname
> distinguishedName: CN=Firstname 
> Lastname,OU=LDAP,OU=Domain,OU=Users,OU=Domain,OU=O
>  rganization,DC=domain,DC=com
> instanceType: 4
> whenCreated: 20110321122858.0Z
> whenChanged: 20131120104224.0Z
> displayName: Firstname Lastname
> uSNCreated: 76590
>  ngame,DC=com
> memberOf: CN=All,OU=OrgGroups,OU=Organization,DC=domain,DC=com
> memberOf: CN=sysadmins,OU=OrgGroups,OU=Organization,DC=domain,DC=com
> uSNChanged: 66378160
> department: Infrastructure
> company: Company name
> homeMTA: CN=Microsoft MTA,CN=MBX,CN=Servers,CN=Exchange Administrative 
> Group (
>  FYDIBOHF23SPDLT),CN=Administrative Groups,CN=globalmail,CN=Microsoft 
> Exchange
>  ,CN=Services,CN=Configuration,DC=domain,DC=com
> proxyAddresses: SMTP:first.last at domain.com <http://domain.com>
> proxyAddresses: smtp:first.last at domain2.com <http://domain2.com>
> proxyAddresses: smtp:first.last at domain3.com <http://domain3.com>
> proxyAddresses: sip:first.last at domain.com
> proxyAddresses: X400:C=SE;A= 
> ;P=globalmail;O=Exchange;S=Lastname;G=Firstname;
> homeMDB: CN=DB3,CN=SG03 - 
> 2GB,CN=InformationStore,CN=MBX,CN=Servers,CN=Exchang
>  e Administrative Group (FYDIBOHF23SPDLT),CN=Administrative 
> Groups,CN=globalma
>  il,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
> garbageCollPeriod: 1209600
> mDBUseDefaults: TRUE
> extensionAttribute8: Companyname
> mailNickname: username
> protocolSettings:: SFRUUMKnMcKnMcKnwqfCp8KnwqfCpw==
> protocolSettings:: T1dBwqcx
> internetEncoding: 0
> name: Firstnam Lastname
> objectGUID:: pDdL7yY7gEuqRdQLTjLo0w==
> userAccountControl: 512
> badPwdCount: 0
> codePage: 0
> countryCode: 0
> homeDirectory: \\path\to\home <smb://path/to/home>
> homeDrive: H:
> badPasswordTime: 130295283826410995
> lastLogoff: 0
> lastLogon: 130297464093469882
> pwdLastSet: 130294130189116476
> primaryGroupID: 513
> objectSid:: AQUAAAoiadjfojdfojsodijfQkAH5TsrAA==
> accountExpires: 0
> logonCount: 6909
> sAMAccountName: username
> sAMAccountType: 805306368
> showInAddressBook: CN=Default Global Address List,CN=All Global 
> Address Lists,
>  CN=Address Lists Container,CN=globalmail,CN=Microsoft 
> Exchange,CN=Services,CN
>  =Configuration,DC=domain,DC=com
> showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists 
> Containe
>  r,CN=globalmail,CN=Microsoft 
> Exchange,CN=Services,CN=Configuration,DC=domain,
>  DC=com
> legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group 
> (FYDIBOHF23SP
>  DLT)/cn=Recipients/cn=username
> userPrincipalName: first at domain.com <mailto:first at domain.com>
> lockoutTime: 0
> ipPhone: +00 00 00 00
> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=com
> dSCorePropagationData: 20131118102944.0Z
> dSCorePropagationData: 20131118102934.0Z
> dSCorePropagationData: 20130313150036.0Z
> dSCorePropagationData: 20120821144903.0Z
> dSCorePropagationData: 16010101181216.0Z
> lastLogonTimestamp: 130294177442871790
> textEncodedORAddress: c=XX;a= 
> ;p=globalmail;o=Exchange;s=Lastname;g=Firstname;
> mail: first.last at domain.com <mailto:first.last at domain.com>
> manager: CN=Manager Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o
>  ngame,DC=com
> mobile:: KzQ2NzI3mjMEMTEwwqAJ
> thumbnailPhoto:: 
> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkA
>  -snip-
>  uaC3IbWlp5cQtpnwnCmjkd9LrDoNFIUDThZwzyrwJbl21//9k=
> msExchHomeServerName: /o=globalmail/ou=Exchange Administrative Group 
> (FYDIBOHF
>  23SPDLT)/cn=Configuration/cn=Servers/cn=MBX
> msExchMailboxSecurityDescriptor:: 
> AQAUjBQAAAAgAAAALAAAAFwAAAABAQAAAAAABQoAAAAB
>  -snip-
>  AQAAAAAABQoAAAACADAAAgAAAALQFAADAA0AAQEAAAAAAAEAAAAAAtoUAGsBDQABAQAAAAAAAQAAA
> msExchUserAccountControl: 0
> msExchMailboxGuid:: uWv8V7HNHUiyda0z/FRc+w==
> msExchPoliciesIncluded: 
> {A64061C3-9598-43A1-9125-B5C682DEDA40},{26491CFC-9E50-
>  4857-861B-0CB8DF22B5D7}
> msRTCSIP-Line: TEL:+46812136492
> msRTCSIP-DeploymentLocator: SRV:
> msExchUserCulture: sv-SE,en-US
> msExchMobileMailboxFlags: 1
> msExchRecipientDisplayType: 1073741824
> msExchVersion: 4535486012416
> msRTCSIP-FederationEnabled: TRUE
> msRTCSIP-PrimaryUserAddress: sip:first.last at domain.com
> msExchRecipientTypeDetails: 1
> msRTCSIP-InternetAccessEnabled: TRUE
> msRTCSIP-UserPolicies: 0=481565286
> msExchMDBRulesQuota: 64
> msRTCSIP-OptionFlags: 385
> msRTCSIP-UserEnabled: TRUE
> msRTCSIP-PrimaryHomeServer: CN=Lc 
> Services,CN=Microsoft,CN=1:1,CN=Pools,CN=RTC
>   Service,CN=Services,CN=Configuration,DC=domain,DC=com
>
> Please note that the same user would sync OK if I hadn't attempted to 
> sync it earlier when the duplicate IPA entry was in place. This is the 
> strangest part... once a user is synced and there's a duplicate in 
> place, we get error 21 and after that the user will be ignored in 
> future syncs. Even if we recreate the agreement.
>
> Question, if a duplicate entry exists in IPA, what's the expected 
> behaviour? Should the user get synced anyway, or should it fail?

It should get synced - it should try to update the entry with any 
missing or out-of-date information.

>
> Please let me know if you need anything else. Setting 
> nsslapd-errorlog-level: 8192 more or less says the same thing... error 
> 21, and then it just moves on. I could provide you with the debug 
> though, if wanted.

Yes, please.

>
>>
>>>
>>> 3. Then I remove the corresponding user from IPA and force another 
>>> sync from AD, hoping that the user will sync properly this time, and 
>>> thus have its ntUser* attributes created:
>>>
>>>     [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - 
>>> agmt="cn=meToAD.domain.com <http://metoad.domain.com/>" (dc03:389): 
>>> map_entry_dn_inbound: looking for local entry by uid [username]
>>>     [25/Nov/2013:14:29:09 +0000] - Windows sync entry: Adding new 
>>> local entry dn: uid=username,cn=users,cn=accounts,dc=domain,dc=net
>>>     [25/Nov/2013:14:29:09 +0000] NSMMReplicationPlugin - add 
>>> operation of entry 
>>> uid=username,cn=users,cn=accounts,dc=domain,dc=net returned: 21
>>>
>>> It's like something (either AD or IPA) remembers that a user have 
>>> failed once, and then refuse to sync it any more. Removing the 
>>> winsync agreement and recreating it completely doesn't help. The 
>>> user is still not synced, and leaves error code 21.
>>>
>>> Anyone have any idea on why this is, and how I can sync the user 
>>> even though it has failed once?
>
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20131125/e9dedaf2/attachment.htm>

More information about the Freeipa-users mailing list