[Freeipa-users] IPA winsync replication

Rich Megginson rmeggins at redhat.com
Tue Nov 26 00:05:07 UTC 2013 

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

I think this may be the problem.  mobile contains non printable characters:
$ python
 >>> import base64
 >>> base64.b64decode('KzQ2NzI3mjMEMTEwwqAJ')
'+46727\x9a3\x04110\xc2\xa0\t'

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.


>> 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
>
>
>
> _______________________________________________
> 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/526467b0/attachment.htm>

More information about the Freeipa-users mailing list