failure adding user in ldap when domain requires custom user_object_classes

[spoore1]

I'm testing with a 389 Directory Server that is setup on Fedora 38 like this:

dnf -y install 389-ds-base cockpit-389-ds

cat > /tmp/instance.inf <<EOF
[general]
config_version = 2

[slapd]
root_password = Secret123

[backend-userroot]
sample_entries = yes
suffix = dc=ldap,dc=test
EOF

dscreate from-file /tmp/instance.inf

I used Keycloak 17 with the Storage Plugin from here:
https://github.com/justin-stephenson/scim-keycloak-user-storage-spi/tree/kc17_test_user_extra_attrs_string

In Keycloak for LDAP User Object Classes, I added:
posixAccount, nsPerson, nsAccount, nsOrgPerson

When I add a user in Keycloak, I'm seeing an error from ipa-tuura and the user account does not appear to be added to LDAP. I see this in the journal:

Sep 26 22:12:06 bridge.ipa.test python3[204]: Unable to complete SCIM call.                              
Sep 26 22:12:06 bridge.ipa.test python3[204]: Traceback (most recent call last):                         
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/www/ipa-tuura/src/ipa-tuura/scim/ipa.py", line 353, in modify
Sep 26 22:12:06 bridge.ipa.test python3[204]:     self._conn.modify_ext_s(dn, mod_attrs)                 
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/lib64/python3.11/site-packages/ldap/ldapobject.py", line 400, in modify_ext_s
Sep 26 22:12:06 bridge.ipa.test python3[204]:     resp_type, resp_data, resp_msgid, resp_ctrls = self.result3(msgid,all=1,timeout=self.timeout)
Sep 26 22:12:06 bridge.ipa.test python3[204]:                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/lib64/python3.11/site-packages/ldap/ldapobject.py", line 543, in result3
Sep 26 22:12:06 bridge.ipa.test python3[204]:     resp_type, resp_data, resp_msgid, decoded_resp_ctrls, retoid, retval = self.result4(
Sep 26 22:12:06 bridge.ipa.test python3[204]:                                                                            ^^^^^^^^^^^^^
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/lib64/python3.11/site-packages/ldap/ldapobject.py", line 553, in result4
Sep 26 22:12:06 bridge.ipa.test python3[204]:     ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
Sep 26 22:12:06 bridge.ipa.test python3[204]:                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/lib64/python3.11/site-packages/ldap/ldapobject.py", line 128, in _ldap_call
Sep 26 22:12:06 bridge.ipa.test python3[204]:     result = func(*args,**kwargs)                          
Sep 26 22:12:06 bridge.ipa.test python3[204]:              ^^^^^^^^^^^^^^^^^^^^                          
Sep 26 22:12:06 bridge.ipa.test python3[204]: ldap.NO_SUCH_OBJECT: {'msgtype': 103, 'msgid': 2, 'result': 32, 'desc': 'No such object', 'ctrls': [], 'matched': 'ou=people,dc=ldap,dc=test'}
Sep 26 22:12:06 bridge.ipa.test python3[204]: During handling of the above exception, another exception occurred:
Sep 26 22:12:06 bridge.ipa.test python3[204]: Traceback (most recent call last):                         
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/local/lib/python3.11/site-packages/django_scim/views.py", line 112, in dispatch
Sep 26 22:12:06 bridge.ipa.test python3[204]:     return super(SCIMView, self).dispatch(request, *args, **kwargs)
Sep 26 22:12:06 bridge.ipa.test python3[204]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/local/lib/python3.11/site-packages/django/views/generic/base.py", line 143, in dispatch
Sep 26 22:12:06 bridge.ipa.test python3[204]:     return handler(request, *args, **kwargs)               
Sep 26 22:12:06 bridge.ipa.test python3[204]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^               
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/usr/local/lib/python3.11/site-packages/django_scim/views.py", line 372, in put
Sep 26 22:12:06 bridge.ipa.test python3[204]:     scim_obj.save()                                        
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/www/ipa-tuura/src/ipa-tuura/scim/adapters.py", line 133, in save
Sep 26 22:12:06 bridge.ipa.test python3[204]:     ipa_if.user_mod(self)                                  
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/www/ipa-tuura/src/ipa-tuura/scim/ipa.py", line 417, in user_mod
Sep 26 22:12:06 bridge.ipa.test python3[204]:     self._apiconn.modify(scim_user)                        
Sep 26 22:12:06 bridge.ipa.test python3[204]:   File "/www/ipa-tuura/src/ipa-tuura/scim/ipa.py", line 357, in modify
Sep 26 22:12:06 bridge.ipa.test python3[204]:     raise LDAPNotFoundException(                           
Sep 26 22:12:06 bridge.ipa.test python3[204]: scim.ipa.LDAPNotFoundException: User testldapuser1 not found

EDIT:

I should note that on the 389 server, I enabled the DNA plugin to handle automatic UID/GID assignment when I was troubleshooting why SSSD could not see the users in LDAP. That's when I also tried adding the custom User Object Classes.

DNA plugin config:

dn: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
objectClass: nsContainer
cn: Distributed Numeric Assignment Plugin
nsslapd-pluginInitfunc: dna_init
nsslapd-pluginType: bepreoperation
nsslapd-pluginEnabled: on
nsslapd-pluginPath: libdna-plugin
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: Distributed Numeric Assignment
nsslapd-pluginVersion: 2.1.8
nsslapd-pluginVendor: 389 Project
nsslapd-pluginDescription: Distributed Numeric Assignment plugin

# UID and GID numbers, Distributed Numeric Assignment Plugin, plugins, config
dn: cn=UID and GID numbers,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: UID and GID numbers
dnaType: uidNumber
dnaType: gidNumber
dnaMaxValue: -1
dnaMagicRegen: 0
dnaFilter: (|(objectclass=posixAccount)(objectclass=posixGroup))
dnaScope: dc=example,dc=com
dnaNextValue: 99999

[spoore1]

Attaching log from ipa-tuura here:

kc_user_not_added_to_ldap.log

[spoore1]

I will also note that if I do not use custom User Object Classes, the user is added to LDAP but, SSSD on the ipa-tuura system cannot resolve the user info because it does not contain the posixAccount object class.

[antoniotorresm]

Looks like ipa-tuura expects a list of objectclasses instead of a single string: https://github.com/freeipa/ipa-tuura/blob/main/src/ipa-tuura/domains/models.py#L82

We need to add further processing for it.

[justin-stephenson]

Looks like ipa-tuura expects a list of objectclasses instead of a single string: https://github.com/freeipa/ipa-tuura/blob/main/src/ipa-tuura/domains/models.py#L82

We need to add further processing for it.

Hi Antonio,

The Keycloak plugin was sending this data as a list originally, but it wasn't working so Scott and I thought to try sending it as a single string.

In that case Scott can you provide the logs/failure of the original issue with the user object classes sent as a list of strings/

[spoore1]

IIRC I never got good debug output from ipa-tuura that showed what we were looking for.

On the Keycloak side though, using the original version of the plugin, I see this:

Sep 28 15:30:00 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:00,882 INFO  [keycloak.scim_user_spi.Scim] (executor-thread-9) Sending GET request to http://bridge.ipa.test:8000/scim/v2/
Sep 28 15:30:00 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:00,929 INFO  [keycloak.scim_user_spi.Scim] (executor-thread-9) Sending DELETE request to http://bridge.ipa.test:8000/domains/v1/domain/1/
Sep 28 15:30:00 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:00,975 INFO  [keycloak.scim_user_spi.Scim] (executor-thread-9) Result is {"detail":"CSRF Failed: CSRF token missing."}
Sep 28 15:30:00 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:00,975 INFO  [keycloak.scim_user_spi.SCIMUserStorageProviderFactory] (executor-thread-9) Delete intgDomains Result is true
Sep 28 15:30:00 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:00,975 INFO  [keycloak.scim_user_spi.Scim] (executor-thread-9) Sending POST request to http://bridge.ipa.test:8000/domains/v1/domain/
Sep 28 15:30:01 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:01,020 INFO  [keycloak.scim_user_spi.Scim] (executor-thread-9) Result is {"user_object_classes":["Not a valid string."]}
Sep 28 15:30:01 keycloak.ipa.test kc.sh[45495]: 2023-09-28 15:30:01,021 INFO  [keycloak.scim_user_spi.SCIMUserStorageProviderFactory] (executor-thread-9) Add intgDomains Result is true

@antoniotorresm How can I enable debug logging on the ipa-tuura side to get more useful info?

[antoniotorresm]

Assuming you're using the ipa-tuura container, you can login into it:

podman exec -it bridge bash

and then get the service logs with systemctl status bridge-devel.

[spoore1]

I'm running quay.io/ftrivino/bridge-fedora-devel but, I don't see a bridge-devel service. I only see bridge:

● bridge.service - SCIMv2 Bridge Server
     Loaded: loaded (/etc/systemd/system/bridge.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Fri 2023-09-29 00:09:41 CEST; 14h ago
   Main PID: 89 (python3)
      Tasks: 4 (limit: 307)
     Memory: 140.3M
        CPU: 14min 5.498s
     CGroup: /system.slice/bridge.service
             ├─ 89 /usr/bin/python3 /www/ipa-tuura/src/ipa-tuura/manage.py runserver 0.0.0.0:8000
             └─122 /usr/bin/python3 /www/ipa-tuura/src/ipa-tuura/manage.py runserver 0.0.0.0:8000

Sep 29 14:54:55 bridge.ipa.test python3[122]: GET
Sep 29 14:54:55 bridge.ipa.test python3[122]: BODY
Sep 29 14:54:55 bridge.ipa.test python3[122]: STATUS_CODE
Sep 29 14:54:55 bridge.ipa.test python3[122]: 501
Sep 29 14:54:55 bridge.ipa.test python3[122]: Not Implemented: /scim/v2/
Sep 29 14:54:55 bridge.ipa.test python3[122]: "GET /scim/v2/ HTTP/1.1" 501 0
Sep 29 14:54:55 bridge.ipa.test python3[122]: Forbidden: /domains/v1/domain/1/
Sep 29 14:54:55 bridge.ipa.test python3[122]: "DELETE /domains/v1/domain/1/ HTTP/1.1" 403 45
Sep 29 14:54:55 bridge.ipa.test python3[122]: Bad Request: /domains/v1/domain/
Sep 29 14:54:55 bridge.ipa.test python3[122]: "POST /domains/v1/domain/ HTTP/1.1" 400 47

Should I be using a different container now?