On 25 Nov 2013, at 17:21, Rich Megginson <rmegg...@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.l...@domain.com
proxyAddresses: smtp:first.l...@domain2.com
proxyAddresses: smtp:first.l...@domain3.com
proxyAddresses: sip:first.l...@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: fi...@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.l...@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.l...@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?

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to