Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

failure adding user in ldap when domain requires custom user_object_classes #67

Open
spoore1 opened this issue Sep 26, 2023 · 7 comments
Open

failure adding user in ldap when domain requires custom user_object_classes #67

spoore1 opened this issue Sep 26, 2023 · 7 comments

Comments

@spoore1
Copy link
Collaborator

spoore1 commented Sep 26, 2023 •
edited
Loading

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
Copy link
Collaborator Author

spoore1 commented Sep 26, 2023

Attaching log from ipa-tuura here:

kc_user_not_added_to_ldap.log

@spoore1
Copy link
Collaborator Author

spoore1 commented Sep 26, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator Author

spoore1 commented Sep 28, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator Author

spoore1 commented Sep 29, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@spoore1 @justin-stephenson @antoniotorresm