On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote: Yes, this should not happen. 'ipa stageuser-find' actually replaces a search filter that a baseuser object is using '(objectclass=posixaccount)' by the following one: (|(objectclass=posixaccount)(objectclass=inetOrgPerson)) https://pagure.io/freeipa/blob/ipa-4-6/f/ipaserver/plugins/stageuser.py#_447 If 'ipa stageuser-find' doesn't find it, you can enable server-side debugging and retry, then you should see debug output in error_log. Create /etc/ipa/server.conf [global] debug = True and restart httpd, then retry. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

Sorry, looks like this debug output is not representative. I tested on the working IPA server, and I see the same lines in error_log: [Wed Jun 12 11:19:00.953636 2019] [:error] [pid 3550] ipa: DEBUG: raw: stageuser_find(None, version=u'2.230') [Wed Jun 12 11:19:00.953938 2019] [:error] [pid 3550] ipa: DEBUG: stageuser_find(None, all=False, raw=False, version=u'2.230', no_members=True, pkey_only=False) [Wed Jun 12 11:19:00.957529 2019] [:error] [pid 3550] ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\\70\\6f\\73\\69\\78\\61\\63\\63\\6f\\75\\6e\\74) [Wed Jun 12 11:19:00.959717 2019] [:error] [pid 3550] ipa: INFO: [jsonserver_session] admin(a)POC.DCN.TELEKOM.DE: stageuser_find/1(None, version=u'2.230'): SUCCESS But despite these same lines, the command FINDS the user!

On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote: The print above shows binary values. May be that's the problem -- it is not matching unicode and non-unicode and thus failing? Can you try the following on IPA master itself: # kinit admin Password for admin(a)EXAMPLE.COM: # ipa -e in_server=True -e debug=True console [... some debug output ...] ipa: DEBUG: Created connection context.ldap2_139989835691680 ipa: DEBUG: raw: console(None, version='2.233') ipa: DEBUG: console(None, version='2.233') (Custom IPA interactive Python console) api: IPA API object pp: pretty printer ipa: DEBUG: raw: stageuser_find(None, version='2.233') ipa: DEBUG: stageuser_find(None, all=False, raw=False, version='2.233', no_members=True, pkey_only=False) ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f51ec6db7b8> ipa: DEBUG: stageuser_find: pre_callback new filter=(|(objectclass=posixaccount)(objectclass=inetOrgPerson)) {'result': [{'mail': [&#39;foobar1(a)example.com&#39;], 'sn': ['bar'], 'uidnumber': ['-1'], 'loginshell': ['/bin/sh'], 'nsaccountlock': True, 'krbcanonicalname': [ipapython.kerberos.Principal(&#39;foobar1(a)EXAMPLE.COM&#39;)], 'givenname': ['ff'], 'uid': ['foobar1'], 'krbprincipalname': [ipapython.kerberos.Principal(&#39;foobar1(a)EXAMPLE.COM&#39;)], 'homedirectory': ['/home/foobar1'], 'gidnumber': ['-1'], 'dn': ipapython.dn.DN('uid=foobar1,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com')}, {'mail': [&#39;tuser(a)example.com&#39;], 'sn': ['user'], 'uidnumber': ['-1'], 'loginshell': ['/bin/sh'], 'nsaccountlock': True, 'krbcanonicalname': [ipapython.kerberos.Principal(&#39;tuser(a)EXAMPLE.COM&#39;)], 'givenname': ['tim'], 'uid': ['tuser'], 'krbprincipalname': [ipapython.kerberos.Principal(&#39;tuser(a)EXAMPLE.COM&#39;)], 'homedirectory': ['/home/tuser'], 'gidnumber': ['-1'], 'dn': ipapython.dn.DN('uid=tuser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com')}], 'count': 2, 'truncated': False, 'messages': [{'type': 'warning', 'name': 'VersionMissing', 'message': "API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.233", 'code': 13001, 'data': {'server_version': '2.233'}}], 'summary': '2 users matched'} Basically, I'm looking at seeing if Python interactive console will show you the same garbage in the filter text or not. If yes, then it looks like there is a bit of uncleaned unicode/str code checks in 4.6. It is part of python-ipaserver (or python{2,3}-ipaserver). -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote: Can you share what queries correspond to these requests in dirsrv access log? -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

Dmitry Perets via FreeIPA-users wrote: You might want to look for replication conflicts. Maybe one entry is hung up. rob

On 6/13/19 6:46 PM, Dmitry Perets via FreeIPA-users wrote: Hi Dmitry can you open a ticket for this issue? I reproduced on RHEL 7.6 and it happens because of the following code: container_filter = "(objectclass=posixaccount)" # provisioning system can create non posixaccount stage user # but then they have to create inetOrgPerson stage user stagefilter = filter.replace(container_filter, "(|%s(objectclass=inetOrgPerson))" % container_filter) We should rather use container_filter = ldap.make_filter_from_attr('objectclass', 'posixaccount') because the filter has been hexlified previously. On Fedora the same code works because we are using python3 instead of python2. In python2 isinstance('posixaccount', bytes) evaluates to True (and the filter is hexlified) but to False in python3 (and the filter is not hexlified). flo

For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1721550