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

ipa-tuura treats AD users differently due to sssd config #135

Open
spoore1 opened this issue Sep 18, 2024 · 1 comment · May be fixed by #136
Open

ipa-tuura treats AD users differently due to sssd config #135

spoore1 opened this issue Sep 18, 2024 · 1 comment · May be fixed by #136

Comments

@spoore1
Copy link
Collaborator

spoore1 commented Sep 18, 2024

It appears that AD users are treated differently in ipa-tuura than IPA and LDAP users due to how the user is being presented by AD.

[root@bridge httpd]# id aduser1
id: ‘aduser1’: no such user

[root@bridge httpd]# id [email protected]
uid=39401259([email protected]) gid=39400513(domain [email protected]) groups=39400513(domain [email protected])

As opposed to IPA:

[root@bridge httpd]# id ipauser100
uid=1049000376(ipauser100) gid=1049000376(ipauser100) groups=1049000376(ipauser100)

[root@bridge httpd]# id [email protected]
uid=1049000376(ipauser100) gid=1049000376(ipauser100) groups=1049000376(ipauser100)

A lookup for aduser1 returns nothing:

{"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"], "totalResults": 0, "itemsPerPage": 50, "startIndex": 1, "Resources": []}

A lookup for [email protected] returns:

{"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"], "totalResults": 1, "itemsPerPage": 50, "startIndex": 1, "Resources": [{"id": "39401259", "externalId": null, "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"], "userName": "[email protected]", "name": {"givenName": "aduser1", "familyName": "aduser1", "formatted": "aduser1 aduser1"}, "displayName": "aduser1 aduser1", "emails": [{"value": "[email protected]", "primary": true}], "active": true, "groups": [{"value": "39400513", "$ref": "https://localhost/scim/v2/Groups/39400513", "display": "domain [email protected]"}], "meta": {"resourceType": "User", "location": "https://localhost/scim/v2/Users/39401259"}}]}
@spoore1
Copy link
Collaborator Author

spoore1 commented Sep 18, 2024

It looks like the default realm join set this in sssd.conf:

use_fully_qualified_names = True

If I comment that out and restart sssd manually, that resolves the issue.

Now the question is "should" we do that here?

spoore1 added a commit to spoore1/ipa-tuura that referenced this issue Sep 18, 2024
@spoore1
Set sssd use_fully_qualified_names False for AD
d611656 
After a realm join, the sssd.conf by default has this option set to
True.  This causes AD behavior to differ slightly from IPA and LDAP by
requiring AD users be fully qualified with a domain in the username.
Forcing this option to False makes all three behave more alike.

Resolves: freeipa#135
Signed-off-by: Scott Poore <[email protected]>
spoore1 added a commit to spoore1/ipa-tuura that referenced this issue Sep 18, 2024
@spoore1
Set sssd use_fully_qualified_names False for AD
23a69f6 
After a realm join, the sssd.conf by default has this option set to
True.  This causes AD behavior to differ slightly from IPA and LDAP by
requiring AD users be fully qualified with a domain in the username.
Forcing this option to False makes all three behave more alike.

Resolves: freeipa#135
Signed-off-by: Scott Poore <[email protected]>
@spoore1 spoore1 linked a pull request Sep 18, 2024 that will close this issue
Open
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

Successfully merging a pull request may close this issue.

WIP: Set sssd use_fully_qualified_names False for AD spoore1/ipa-tuura
1 participant
@spoore1