Hi,
I observe a weird problem, trying to figure out how it could happen...
On one of my IPA installations, IPA doesn't recognize stage users, UNLESS they include objectClass posixaccount. For example, below output shows a staged user that I've manually added with "ldapmodify", but as you can see, it is not found with "ipa stageuser-find":
``` $ ldapsearch -Y GSSAPI uid=atest SASL/GSSAPI authentication started SASL username: admin@IMS.DCN.EXAMPLE.DE SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=ims,dc=dcn,dc=example,dc=de> (default) with scope subtree # filter: uid=atest # requesting: ALL #
# atest, staged users, accounts, provisioning, ims.dcn.example.de dn: uid=atest,cn=staged users,cn=accounts,cn=provisioning,dc=ims,dc=dcn,dc=ex ample,dc=de objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person uid: atest sn: atest givenName: atest cn: atest
# search result search: 4 result: 0 Success
# numResponses: 2 # numEntries: 1 ``` ``` $ ipa stageuser-find WARNING: yacc table file version is out of date --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ---------------------------- ```
This user will be recognized, if I add the following attributes:
objectClass: posixaccount uidNumber: -1 gidNumber: -1 homeDirectory: /home/atest
But this is not supposed to be so... and in fact, on another IPA installation (totally separate) I don't see this constraint. The same LDIF (just different base DN) gets properly recognized as staged user! I was comparing the entire cn=config and the IPA server configuration section, but I cannot find what setting can possibly affect this...
Can you help with an idea please?
On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote:
Hi,
I observe a weird problem, trying to figure out how it could happen...
On one of my IPA installations, IPA doesn't recognize stage users, UNLESS they include objectClass posixaccount. For example, below output shows a staged user that I've manually added with "ldapmodify", but as you can see, it is not found with "ipa stageuser-find":
$ ldapsearch -Y GSSAPI uid=atest SASL/GSSAPI authentication started SASL username: admin@IMS.DCN.EXAMPLE.DE SASL SSF: 256 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <dc=ims,dc=dcn,dc=example,dc=de> (default) with scope subtree # filter: uid=atest # requesting: ALL # # atest, staged users, accounts, provisioning, ims.dcn.example.de dn: uid=atest,cn=staged users,cn=accounts,cn=provisioning,dc=ims,dc=dcn,dc=ex ample,dc=de objectClass: top objectClass: inetorgperson objectClass: organizationalPerson objectClass: person uid: atest sn: atest givenName: atest cn: atest # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1$ ipa stageuser-find WARNING: yacc table file version is out of date --------------- 0 users matched --------------- ---------------------------- Number of entries returned 0 ----------------------------This user will be recognized, if I add the following attributes:
objectClass: posixaccount uidNumber: -1 gidNumber: -1 homeDirectory: /home/atest
But this is not supposed to be so... and in fact, on another IPA installation (totally separate) I don't see this constraint. The same LDIF (just different base DN) gets properly recognized as staged user! I was comparing the entire cn=config and the IPA server configuration section, but I cannot find what setting can possibly affect this...
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.
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.
Weirdly enough:
[Wed Jun 12 11:03:38.648863 2019] [:error] [pid 17432] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Wed Jun 12 11:03:38.648999 2019] [:error] [pid 17432] ipa: DEBUG: WSGI jsonserver.__call__: [Wed Jun 12 11:03:38.649064 2019] [:error] [pid 17432] ipa: DEBUG: KerberosWSGIExecutioner.__call__: [Wed Jun 12 11:03:38.668898 2019] [:error] [pid 17432] ipa: DEBUG: Created connection context.ldap2_140302443346704 [Wed Jun 12 11:03:38.669013 2019] [:error] [pid 17432] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Wed Jun 12 11:03:38.676281 2019] [:error] [pid 17432] ipa: DEBUG: raw: stageuser_find(None, version=u'2.230') [Wed Jun 12 11:03:38.676646 2019] [:error] [pid 17432] ipa: DEBUG: stageuser_find(None, all=False, raw=False, version=u'2.230', no_members=True, pkey_only=False) [Wed Jun 12 11:03:38.679558 2019] [:error] [pid 17432] ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IMS-DCN-TELEKOM-DE.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f9ab4b82ea8> [Wed Jun 12 11:03:39.016496 2019] [:error] [pid 17432] 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:03:39.019307 2019] [:error] [pid 17432] ipa: INFO: [jsonserver_kerb] admin@IMS.DCN.TELEKOM.DE: stageuser_find/1(None, version=u'2.230'): SUCCESS [Wed Jun 12 11:03:39.020103 2019] [:error] [pid 17432] ipa: DEBUG: Destroyed connection context.ldap2_140302443346704
Somehow the filter is not replaced...??? still (objectclass=posixaccount): [Wed Jun 12 11:03:39.016496 2019] [:error] [pid 17432] ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\70\6f\73\69\78\61\63\63\6f\75\6e\74)
In the code it looks pretty much hardcoded, so how is that possible that it doesn't work...?
Btw part of which package is that particular code? I have ipa-server 4.6.4 everywhere (RHEL distribution), but maybe some other package is wrong..?
--- Regards, Dmitry Perets
Somehow the filter is not replaced...??? still (objectclass=posixaccount): [Wed Jun 12 11:03:39.016496 2019] [:error] [pid 17432] ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\70\6f\73\69\78\61\63\63\6f\75\6e\74)
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@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:
Somehow the filter is not replaced...??? still (objectclass=posixaccount): [Wed Jun 12 11:03:39.016496 2019] [:error] [pid 17432] ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\70\6f\73\69\78\61\63\63\6f\75\6e\74)
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@POC.DCN.TELEKOM.DE: stageuser_find/1(None, version=u'2.230'): SUCCESS
But despite these same lines, the command FINDS the user!
I'm concerned with the binary part (\70\6f\73 ...) -- looks like it is some Python 2/3 incompatibility in 4.6.
On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote:
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.
Weirdly enough:
[Wed Jun 12 11:03:38.648863 2019] [:error] [pid 17432] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Wed Jun 12 11:03:38.648999 2019] [:error] [pid 17432] ipa: DEBUG: WSGI jsonserver.__call__: [Wed Jun 12 11:03:38.649064 2019] [:error] [pid 17432] ipa: DEBUG: KerberosWSGIExecutioner.__call__: [Wed Jun 12 11:03:38.668898 2019] [:error] [pid 17432] ipa: DEBUG: Created connection context.ldap2_140302443346704 [Wed Jun 12 11:03:38.669013 2019] [:error] [pid 17432] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Wed Jun 12 11:03:38.676281 2019] [:error] [pid 17432] ipa: DEBUG: raw: stageuser_find(None, version=u'2.230') [Wed Jun 12 11:03:38.676646 2019] [:error] [pid 17432] ipa: DEBUG: stageuser_find(None, all=False, raw=False, version=u'2.230', no_members=True, pkey_only=False) [Wed Jun 12 11:03:38.679558 2019] [:error] [pid 17432] ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IMS-DCN-TELEKOM-DE.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f9ab4b82ea8> [Wed Jun 12 11:03:39.016496 2019] [:error] [pid 17432] 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:03:39.019307 2019] [:error] [pid 17432] ipa: INFO: [jsonserver_kerb] admin@IMS.DCN.TELEKOM.DE: stageuser_find/1(None, version=u'2.230'): SUCCESS [Wed Jun 12 11:03:39.020103 2019] [:error] [pid 17432] ipa: DEBUG: Destroyed connection context.ldap2_140302443346704
Somehow the filter is not replaced...??? still (objectclass=posixaccount): [Wed Jun 12 11:03:39.016496 2019] [:error] [pid 17432] ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\70\6f\73\69\78\61\63\63\6f\75\6e\74)
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@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
api.Command.stageuser_find()
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': ['foobar1@example.com'], 'sn': ['bar'], 'uidnumber': ['-1'], 'loginshell': ['/bin/sh'], 'nsaccountlock': True, 'krbcanonicalname': [ipapython.kerberos.Principal('foobar1@EXAMPLE.COM')], 'givenname': ['ff'], 'uid': ['foobar1'], 'krbprincipalname': [ipapython.kerberos.Principal('foobar1@EXAMPLE.COM')], 'homedirectory': ['/home/foobar1'], 'gidnumber': ['-1'], 'dn': ipapython.dn.DN('uid=foobar1,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com')}, {'mail': ['tuser@example.com'], 'sn': ['user'], 'uidnumber': ['-1'], 'loginshell': ['/bin/sh'], 'nsaccountlock': True, 'krbcanonicalname': [ipapython.kerberos.Principal('tuser@EXAMPLE.COM')], 'givenname': ['tim'], 'uid': ['tuser'], 'krbprincipalname': [ipapython.kerberos.Principal('tuser@EXAMPLE.COM')], '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.
In the code it looks pretty much hardcoded, so how is that possible that it doesn't work...?
Btw part of which package is that particular code? I have ipa-server 4.6.4 everywhere (RHEL distribution), but maybe some other package is wrong..?
It is part of python-ipaserver (or python{2,3}-ipaserver).
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.
Yes, same output is also in the console... and both on working and on non-working IPA server. The working one - surprisingly - just returns the result, despite having the same bogus filter:
api.Command.stageuser_find()
ipa: DEBUG: raw: stageuser_find(None, version=u'2.230') ipa: DEBUG: stageuser_find(None, all=False, raw=False, version=u'2.230', no_members=True, pkey_only=False) ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-POC-DCN-TELEKOM-DE.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f76360d19e0> ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\70\6f\73\69\78\61\63\63\6f\75\6e\74) {'count': 1, 'summary': u'1 user matched', 'messages': [{'data': {'server_version': u'2.230'}, 'message': u"API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.230", 'code': 13001, 'type': u'warning', 'name': u'VersionMissing'}], 'result': [{'dn': ipapython.dn.DN('uid=atest,cn=staged users,cn=accounts,cn=provisioning,dc=poc,dc=dcn,dc=telekom,dc=de'), u'givenname': [u'atest'], u'uid': [u'atest'], u'nsaccountlock': True, u'sn': [u'atest']}], 'truncated': False}
On both servers I have this one: python2-ipaserver-4.6.4-10.el7_6.3.noarch
On the WORKING server I have _also_ python3 installed, but not sure if it is used... the debug console in both cases seems to use python 2.7.
On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote:
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.
Yes, same output is also in the console... and both on working and on non-working IPA server. The working one - surprisingly - just returns the result, despite having the same bogus filter:
api.Command.stageuser_find()
ipa: DEBUG: raw: stageuser_find(None, version=u'2.230') ipa: DEBUG: stageuser_find(None, all=False, raw=False, version=u'2.230', no_members=True, pkey_only=False) ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-POC-DCN-TELEKOM-DE.socket conn=<ldap.ldapobject.SimpleLDAPObject instance at 0x7f76360d19e0> ipa: DEBUG: stageuser_find: pre_callback new filter=(objectclass=\70\6f\73\69\78\61\63\63\6f\75\6e\74) {'count': 1, 'summary': u'1 user matched', 'messages': [{'data': {'server_version': u'2.230'}, 'message': u"API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.230", 'code': 13001, 'type': u'warning', 'name': u'VersionMissing'}], 'result': [{'dn': ipapython.dn.DN('uid=atest,cn=staged users,cn=accounts,cn=provisioning,dc=poc,dc=dcn,dc=telekom,dc=de'), u'givenname': [u'atest'], u'uid': [u'atest'], u'nsaccountlock': True, u'sn': [u'atest']}], 'truncated': False}
On both servers I have this one: python2-ipaserver-4.6.4-10.el7_6.3.noarch
On the WORKING server I have _also_ python3 installed, but not sure if it is used... the debug console in both cases seems to use python 2.7.
Can you share what queries correspond to these requests in dirsrv access log?
On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote: Can you share what queries correspond to these requests in dirsrv access log?
Yes, mistery continues...
WORKING:
[12/Jun/2019:12:31:25.546759725 +0200] conn=18810 op=2 SRCH base="cn=staged users,cn=accounts,cn=provisioning,dc=poc,dc=dcn,dc=telekom,dc=de" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp ipaSshPubKey uid krbCanonicalName title loginShell uidNumber gidNumber sn homeDirectory mail krbPrincipalName givenName nsAccountLock" [12/Jun/2019:12:31:25.547320288 +0200] conn=18810 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000670253
NOT WORKING:
[12/Jun/2019:12:40:34.215947855 +0200] conn=112355 op=2 SRCH base="cn=staged users,cn=accounts,cn=provisioning,dc=ims,dc=dcn,dc=telekom,dc=de" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp ipaSshPubKey uid krbCanonicalName title loginShell uidNumber gidNumber sn homeDirectory mail krbPrincipalName givenName nsAccountLock" [12/Jun/2019:12:40:34.217107077 +0200] conn=112355 op=2 RESULT err=0 tag=101 nentries=0 etime=0.0001317861
So: (1) In both cases, the filters are wrong (2) In one of the cases, it nevertheless works....
Btw on the WORKING server this manual query does NOT return results, as expected:
ldapsearch -x -D "uid=admin,cn=users,cn=accounts,dc=poc,dc=dcn,dc=telekom,dc=de" -W -b "cn=staged users,cn=accounts,cn=provisioning,dc=poc,dc=dcn,dc=telekom,dc=de" "(objectClass=posixaccount)"
So I have really no idea why the ipa stageuser-find succeeds, despite the wrong filter =(
Dmitry Perets via FreeIPA-users wrote:
On ke, 12 kesä 2019, Dmitry Perets via FreeIPA-users wrote: Can you share what queries correspond to these requests in dirsrv access log?
Yes, mistery continues...
WORKING:
[12/Jun/2019:12:31:25.546759725 +0200] conn=18810 op=2 SRCH base="cn=staged users,cn=accounts,cn=provisioning,dc=poc,dc=dcn,dc=telekom,dc=de" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp ipaSshPubKey uid krbCanonicalName title loginShell uidNumber gidNumber sn homeDirectory mail krbPrincipalName givenName nsAccountLock" [12/Jun/2019:12:31:25.547320288 +0200] conn=18810 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000670253
NOT WORKING:
[12/Jun/2019:12:40:34.215947855 +0200] conn=112355 op=2 SRCH base="cn=staged users,cn=accounts,cn=provisioning,dc=ims,dc=dcn,dc=telekom,dc=de" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp ipaSshPubKey uid krbCanonicalName title loginShell uidNumber gidNumber sn homeDirectory mail krbPrincipalName givenName nsAccountLock" [12/Jun/2019:12:40:34.217107077 +0200] conn=112355 op=2 RESULT err=0 tag=101 nentries=0 etime=0.0001317861
So: (1) In both cases, the filters are wrong (2) In one of the cases, it nevertheless works....
Btw on the WORKING server this manual query does NOT return results, as expected:
ldapsearch -x -D "uid=admin,cn=users,cn=accounts,dc=poc,dc=dcn,dc=telekom,dc=de" -W -b "cn=staged users,cn=accounts,cn=provisioning,dc=poc,dc=dcn,dc=telekom,dc=de" "(objectClass=posixaccount)"
So I have really no idea why the ipa stageuser-find succeeds, despite the wrong filter =(
You might want to look for replication conflicts. Maybe one entry is hung up.
rob
Dmitry Perets via FreeIPA-users wrote:
You might want to look for replication conflicts. Maybe one entry is hung up.
rob
Hi Rob, you mean on the WORKING IPA? Because indeed, now it looks more weird that one is WORKING rather than that the other is NOT WORKING...
I've tested on yet another one, this time running CentOS (!), also freeipa 4.6.4. And I see the same problem:
[13/Jun/2019:18:42:12.013877786 +0200] conn=189796 op=2 SRCH base="cn=staged users,cn=accounts,cn=provisioning,dc=dths37,dc=dcn,dc=telekom,dc=de" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp ipaSshPubKey uid krbCanonicalName title loginShell uidNumber gidNumber sn homeDirectory mail krbPrincipalName givenName nsAccountLock" [13/Jun/2019:18:42:12.015946649 +0200] conn=189796 op=2 RESULT err=0 tag=101 nentries=0 etime=0.0002280480
So definitely it looks like a bug with IPA 4.6.4.
And why one of my IPAs nevertheless works - don't know, but maybe we can ignore it for now...
On 6/13/19 6:46 PM, Dmitry Perets via FreeIPA-users wrote:
Dmitry Perets via FreeIPA-users wrote:
You might want to look for replication conflicts. Maybe one entry is hung up.
rob
Hi Rob, you mean on the WORKING IPA? Because indeed, now it looks more weird that one is WORKING rather than that the other is NOT WORKING...
I've tested on yet another one, this time running CentOS (!), also freeipa 4.6.4. And I see the same problem:
[13/Jun/2019:18:42:12.013877786 +0200] conn=189796 op=2 SRCH base="cn=staged users,cn=accounts,cn=provisioning,dc=dths37,dc=dcn,dc=telekom,dc=de" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp ipaSshPubKey uid krbCanonicalName title loginShell uidNumber gidNumber sn homeDirectory mail krbPrincipalName givenName nsAccountLock" [13/Jun/2019:18:42:12.015946649 +0200] conn=189796 op=2 RESULT err=0 tag=101 nentries=0 etime=0.0002280480
So definitely it looks like a bug with IPA 4.6.4.
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
And why one of my IPAs nevertheless works - don't know, but maybe we can ignore it for now... _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
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.
Thanks flo! I've opened a case with Red Hat on this, pointing to this thread.
--- Regards, Dmitry Perets
For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1721550
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Dmitry Perets -
Florence Blanc-Renaud -
Rob Crittenden