[Freeipa-users] IPA winsync replication

Mon Nov 25 18:51:22 UTC 2013

On 25 Nov 2013, at 17:21, Rich Megginson <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
proxyAddresses: smtp:first.last at domain2.com
proxyAddresses: smtp:first.last at 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
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
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
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?

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.

> 
>> 
>> 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" (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?

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