On 11/25/2013 04:57 PM, Rich Megginson wrote:
On 11/25/2013 11:51 AM, Emil Petersson wrote:
On 25 Nov 2013, at 17:21, Rich Megginson <rmegg...@redhat.com <mailto:rmegg...@redhat.com>> wrote:

On 11/25/2013 08:14 AM, Emil Petersson wrote:

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=
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
instanceType: 4
whenCreated: 20110321122858.0Z
whenChanged: 20131120104224.0Z
displayName: Firstname Lastname
uSNCreated: 76590
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
proxyAddresses: SMTP:first.l...@domain.com <http://domain.com>
proxyAddresses: smtp:first.l...@domain2.com <http://domain2.com>
proxyAddresses: smtp:first.l...@domain3.com <http://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 <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
showInAddressBook: CN=All Users,CN=All Address Lists,CN=Address Lists Containe r,CN=globalmail,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,
legacyExchangeDN: /o=globalmail/ou=Exchange Administrative Group (FYDIBOHF23SP
userPrincipalName: fi...@domain.com <mailto: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 <mailto:first.l...@domain.com>
manager: CN=Manager Name,OU=Domain,OU=Users,OU=Domain,OU=Organization,DC=o
mobile:: KzQ2NzI3mjMEMTEwwqAJ

I think this may be the problem.  mobile contains non printable characters:
$ python
>>> import base64
>>> base64.b64decode('KzQ2NzI3mjMEMTEwwqAJ')

Looks like the mobile phone number contains utf8 characters.  It must not:
    /* Per RFC4517:
     * TelephoneNumber = PrintableString
     * PrintableString = 1*PrintableCharacter

Unfortunately, AD syntax checking leaves a lot to be desired, so it allows this and other bogus data. IPA/389 is much stricter.

msExchHomeServerName: /o=globalmail/ou=Exchange Administrative Group (FYDIBOHF
msExchUserAccountControl: 0
msExchMailboxGuid:: uWv8V7HNHUiyda0z/FRc+w==
msExchPoliciesIncluded: {A64061C3-9598-43A1-9125-B5C682DEDA40},{26491CFC-9E50-
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

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 mailing list

Freeipa-users mailing list

Reply via email to