-
Notifications
You must be signed in to change notification settings - Fork 247
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.
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
Add support for ldapi:// URLs #6484
Conversation
Make sssd aware of unix domain sockets, allowing connections to local LDAP servers. Make use of struct sockaddr and socklen_t consistent across the code.
This was developed for, and backports cleanly to, the v2.7 branch. |
At this point RFEs target v2.9 |
Hi, thank you for your patience. Please have a look at the
is missing. In general I'm fine with the removal of And if the size is important it still might be easier to move the bye, |
Thank you for catching this. I've just submitted the fix and it appears to have worked.
Alas the length is important, as the length indicates the type of unix domain socket. Different lengths indicate whether the socket is anonymous, a file, etc. You need to keep the length it gives you, otherwise you get all sorts of headaches. |
In general, looks good to me. |
Hi, if I understand it correctly the length is only important for anonymous/unnamed and abstract (Linux only) sockets which both are most probably not relevant here. But I'm fine with keeping the length for completeness. Can you enhance the bye, |
Hi @minfrin, besides addressing recent comment from Sumit, could you please also add a release note to the commit message, following template: Line 13 in fc4f039
Those are used to automatically generate upstream release notes. And there seems to be another one issue.
(we didn't check other LDAP servers but quick search hints this also might be the same with OpenLDAP). There is undocumented SSSD config options |
@minfrin, hi, do you plan any additional work on this? |
Yes - been a little snowed under though. |
Hi @minfrin, JFYI: we plan 2.9.0 upstream release "soon". After 2.9.0 is out, RFEs will target 2.10.0 |
This week is mad, let me look at this next, maybe over this weekend. |
Add support for printing AF_UNIX paths.
I spent quite a while trying to find a constant that could be reliably used to avoid passing around the length of the sockaddr, and eventually concluded there isn't a safe one. You need to use what was given to you, or it doesn't work.
Done in 5818ac0 |
Done.
I am testing with 389ds and don't see this - can you give more detail as to how to trigger this? |
My config looks like this:
|
Did you use user auth (like ssh user@localhost or su)? |
I do yes, but I'm probably configured differently to you, which is why everything just works for me. Can you share your exact configuration so I can reproduce what you're seeing? |
Is there 'START TLS' in sssd logs in your setup? Does it succeed? I talked to 389ds maintainers and TLS isn't supported for local unix sockets... @aborah-sudo, could you please share sssd.conf you used? |
[root@fedora37 sssd]# cat sssd.conf [domain/example1] [pam] Below commands works well . Only the ssh part does not work. [root@fedora37 sssd]# systemctl stop sssd ;rm -rf /var/log/sssd/* ; rm -rf /var/lib/sss/db/* ; systemctl start sssd[root@fedora37 sssd]# systemctl stop sssd ;rm -rf /var/log/sssd/* ; rm -rf /var/lib/sss/db/* ; systemctl start sssd SSSD nss user lookup result:
SSSD InfoPipe user lookup result:
testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment:
|
I wonder if this line is bouncing the TLS on:
TLS makes no sense for unix domain sockets, as if your unix domain socket is compromised your kernel is compromised and your TLS will be too. Is there a place in the TLS code where this can be forced off for ldapi connections? Let me follow the ldap_auth_disable_tls_never_use_in_production path and see where that is set. ldapi should just be off. |
Digging some more, I see TLS is switched on in two different places, firstly in a function called decide_tls_usage(): sssd/src/providers/ldap/sdap_async_connection.c Line 1489 in 0a9c00c
Then a second time TLS is forced on using the ldap_auth_disable_tls_never_use_in_production option, which artificially forces TLS to be on when not explicitly turned off, overriding decide_tls_usage() above. sssd/src/providers/ldap/ldap_auth.c Line 554 in a1af9be
I am assuming the fix is to move the ldap_auth_disable_tls_never_use_in_production code into the decide_tls_usage() function? |
I eventually found TLS was being forced on in the auth section, and have added a code path that bypassed that when ldapi is present. I am struggling to test this, as in my case sssd appears to refuse to check the password. It complains the password is wrong, but there is nothing in the LDAP access log to show any attempt to bind to check the password:
Standard access is for me using ssh keys, not passwords, and those are working great. I've also noticed the sssctl tool refuses to install on RHEL9, complaining that "/usr/bin/python33 is needed by sssd-tools". |
[root@fedora37 sssd]# cat sssd.conf [pam] [domain/example1] [root@fedora37 sssd]# systemctl restart sssd Looks like auth is working this time |
Perfect, thank you for confirming. |
Hi, it looks like you have to modify your PAM configuration so that pam_sss is tried as well for authentication. bye,
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
thanks, my tests with ldapi were successful and I haven't see a regression with ldap or ldaps, ACK.
bye,
Sumit
Hi @minfrin,
It should be in the commit message of one of patches, not in the PR description. Otherwise ACK. |
Hi @minfrin, could you please also rebase and resolve a trivial conflict in 'util.h'? |
I resolved the conflict and added release note so we can push it.
|
Thanks for this - been up to my eyeballs in apr-util, this was on my todo list. |
Make sssd aware of unix domain sockets, allowing connections to local LDAP servers.
Make use of struct sockaddr and socklen_t consistent across the code.
Resolves: #1651
:feature: Add support for ldapi:// URLs