On 26/11/13 01:05, Rich Megginson wrote:
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.
Hey Rich,

You are correct!

All "mobile" entries in our AD is base64 encoded and ends with "\xc2\xa0\t". Removing the junk characters from the mobile entry makes the user sync correctly, regardless of if the user pre exists or not. Issue solved, thanks alot for pointing this out!
Freeipa-users mailing list

Reply via email to