Description of problem: if we use migrate-ds with --user-ignore-attribute=attr is checking anyway the attribute syntax of the ignored attribute. Version-Release number of selected component (if applicable): ipa-python-4.2.0-15.el7_2.3.x86_64 How reproducible: Always. ipa migrate-ds --user-ignore-attribute=seeAlso --continue ldap://server:389 and define a seealso that attribute that is not a dn breaking syntax. For instance, in the server from which migrate users: [root@ipaserver ~]# ldapmodify -D "cn=directory manager" -w secret12 dn: uid=gparente,cn=users,cn=accounts,dc=example,dc=com changetype: modify add: seeAlso seeAlso: notadn modifying entry "uid=gparente,cn=users,cn=accounts,dc=example,dc=com" Then, ipa migrate-ds --continue --with-compat ldap://10.12.211.42:389 --user-ignore-attribute=seealso --user-container=cn=users,cn=accounts,dc=example,dc=com ipa: DEBUG: migrate_ds(u'ldap://10.12.211.42:389', u'********', binddn=ipapython.dn.DN('cn=directory manager'), usercontainer=ipapython.dn.DN('cn=users,cn=accounts,dc=example,dc=com'), groupcontainer=ipapython.dn.DN('ou=groups'), userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=(u'seealso',), groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=True, compat=True, use_def_group=True, scope=u'onelevel', version=u'2.156', exclude_groups=None, exclude_users=None) ipa: INFO: Forwarding 'migrate_ds' to json server 'https://ipaserver.example.com/ipa/session/json' ipa: DEBUG: Destroyed connection context.rpcclient_56917840 ipa: ERROR: an internal error has occurred If I delete seeAlso attr. from the entry, the user is migrated.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/6105
A root cause is being indicated by an error message: """ ValueError: unable to convert the attribute u'seeAlso' value 'Standard' to type <class 'ipapython.dn.DN'> in LDAP entry $ENTRY_DN """ As it is saying, the problem in behavior happens when the attribute contains an invalid value - a value which is not a distinguishedName as defined by rfc4519 https://tools.ietf.org/html/rfc4519#page-15 """ 2.30. 'seeAlso' The 'seeAlso' attribute type contains the distinguished names of objects that are related to the subject object. Each related object name is one value of this multi-valued attribute. (Source: X.520 [X.520]) ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName ) Example: The person object "cn=James Brown,ou=employee,o=Widget\, Inc." is related to the role objects "cn=Football Team Captain,ou=sponsored activities,o=Widget\, Inc." and "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". Since the role objects are related to the person object, the 'seeAlso' attribute will contain the distinguished name of each role object as separate values. """ migrate-ds command is ignoring the attribute correctly. But the issue happens a bit sooner. migrate-ds command by default searches for all user (or group) records and queries all attributes ('*'). The error happens in library which processes the output and creates an internal representation of the entry. The library does types conversions and it correctly checks if the content matches the definition. In this case, it does not and thus it fails. Thus the right thing is to correct the values of such attributes in the source LDAP server. A workaround can be the one suggested by German Parenty in comment 4 (create ACI so that the user doing migration cannot read the attr). A next workaround is to delete the value. This issue might not be easily fixed. Basically, the migrate-ds command would need to query only the attrs which we need for the migration (to not use attr definition '*'). I don't know right now, how easy that would be - it would need more investigation (e.g. if it would not break some other use case). Another possible 'fix' - not failing when it occurs is IMO, not the right thing and should be avoided as such issue might be also in attributes which are critical for the migration and in such case it is good to fail. In either case, I think that the error message can be better, saying what is happening.