Bug 1356163

Summary: migrate-ds is not completely ignoring attributes.
Product: Red Hat Enterprise Linux 9 Reporter: German Parente <gparente>
Component: ipaAssignee: Florence Blanc-Renaud <frenaud>
Status: NEW --- QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: high    
Version: unspecifiedCC: gparente, pasik, pvoborni, rcritten, tscherf
Target Milestone: betaKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description German Parente 2016-07-13 14:06:32 UTC 
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.
Comment 5 Petr Vobornik 2016-07-21 16:12:14 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/6105
Comment 9 Petr Vobornik 2019-09-16 12:16:14 UTC 
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.