-
Notifications
You must be signed in to change notification settings - Fork 45
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
macOS build isn't usable #237
Comments
Refer to #235 and I cc-spam: @jborean93 (sorry!) |
I meant that macOS +11.* was fixed in #235 but really it was #236. Since no code was changed maybe it's Kerberos or SSL or possibly the combination that is broken in macOS 11.*? Since I hit it in Python with ldap3 and gssapi I could easily reproduce it. I'll try something else also like Net::LDAP and GSSAPI. I'll report back! |
The issue mentioned was really just an issue with building the library where the extension detection wasn’t working. Your error comes from calling the C functions and it returning this error. Maybe there is some ABI/data marshalling issue but that’s outside the realms of my expertise. From a basic look at the error I wouldn’t classify this as a problem in gssapi but I could be wrong. |
One idea, maybe - do the versions of every python package you're using match on Arch and MacOS? If they don't, that points at something; if they do, maybe it's Heimdal-specific or (hopefully not) macOS specific. |
Heh wouldn’t be the first time macOS’ Heimdal implementation has an issue. |
On Fri, 2021-01-08 at 13:20:57 -0800, Jordan Borean wrote:
> maybe it's Heimdal-specific or (hopefully not) macOS specific
Heh wouldn’t be the first time macOS’ Heimdal implementation has an issue.
Is it possible to use the heimdal from Homebrew somehow? When I looked
at it it looks like you don't use krb5-config at all (which would have
been easy to just point to the Homebrew one).
|
It looks like it is possible you just need to specify these 3 things manually when installing as well as ensure the
This is not tested at all and in the past I've had to manually edit the |
Well well well, what do you know.. It's broken again = D
|
So if your Heimdal brew version is working then I don’t think the bug exists in python-gssapi but rather the GSS framework that Apple provides. I could still be wrong though but I’m not sure what else it could be. |
Just as an FYI I've tried out your code on macOS Big Sur using the built-in Heimdal implementation. The script was slightly tweaked as my test domain didn't have LDAPS enabled. #!/usr/bin/env python3
import sys
from ldap3 import Server, Connection, SASL, KERBEROS
server = Server(sys.argv[1], use_ssl=False)
c = Connection(server, authentication=SASL, sasl_mechanism=KERBEROS)
c.bind()
print(c.extend.standard.who_am_i()) $ ./search.py dc01.domain.test
u:DOMAIN\vagrant-domain It worked without any issues although I'm getting a different format for the user compared to yours. I'm just running this after doing |
That's correct. Like I stated in my OP: With macOS 11.1's builtin Heimdal:
|
Oh sorry I did not read that initial part. I'll have another check tomorrow after setting up LDAPS on my test domain. I remember having problems with LDAPS and GSSAPI before https://github.com/jborean93/ansible-lookup-laps_password#known-issues but that was with a different LDAP library and way before Big Sur came into the picture. |
What are you testing this against ? |
Just as an FYI I've tried out LDAPS and it works just fine on my box. I've also made sure I've enable LDAP signing and CBT enforcing on AD to see if that's the case. |
On Tue, 2021-01-12 at 05:57:16 -0800, Simo Sorce wrote:
> That's correct. Like I stated in my OP:
>
> With macOS 11.1's builtin Heimdal:
>
> * GSSAPI over LDAP works white_check_mark
>
> * NO AUTH/PLAIN over LDAPS works white_check_mark
>
> * GSSAPI over LDAPS doesn't work x
What are you testing this against ?
If it is AD it may be because AD now enforces channel bindings when you use GSSAPI on LDAPS
OpenLDAP. "It worked before"™ the upgrade to macOS 11.
|
On Tue, 2021-01-12 at 11:46:56 -0800, Jordan Borean wrote:
Just as an FYI I've tried out LDAPS and it works just fine on my box. I've also made sure I've enable LDAP signing and CBT enforcing on AD to see if that's the case.
Well, OK then. Now I feel like I have to go full DEBUG = S
I'll reconfigure our test OpenLDAP to use RSA so I can decrypt the SSL.
I've already looked at the Kerberos trafic before and it looks normal
(and it looks the same with or without SSL).
|
I've debugged with my co-worker @eest and when we looked at the decrypted LDAP communication we found that the LDAP bindRequest -> SASL -> GSSAPI -> Kerberos -> authenticator size is the same (242 bytes) when using Homebrew Heimdal no matter if SSL or plain is used. But with macOS 11 Heimdal the size of the authenticator value differs (it's 461 bytes when it fails with SSL and it's 421 bytes when it works with plain). Also maybe worth noting, when using macOS 11 Heimdal and using plain, in the AP-REQs AP-options the reserved field is set to True. There is no documentation what this field does (well, it's reserved) and @eest looked in Heimdals code but couldn't see that it was used or at least changed in the recent years (right @eest?).
1.5.1 is from 2011 but apple has probably added patches. I can't remember what version of Heimdal 10.14 (which I used before) had. I can send you the .pcap off Github if you want. Well not the .pcap because that would require you to have our RSA key to decrypt it but I see that Wireshark can export to JSON. |
Possibly it's lib/krb5/build_auth.c that populates authticator. |
What went wrong?
Tried to use ldap3 with gssapi and I can't get SASL GSSAPI auth over LDAPS to work.
GSSAPI over LDAPS works on Linux (I tried ArchLinux but should work on any)
How do we reproduce?
That should yield an LDAP dn which should match your Kerberos principal.
With macOS 11.1 I get:
Component versions (python-gssapi, Kerberos, OS / distro, etc.)
The text was updated successfully, but these errors were encountered: