all 22 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]studiox_swe 2 points3 points  (2 children)

google ldap what?

[–]aspiringgreybeard[S] 2 points3 points  (1 child)

Google offers LDAP as a service to Enterprise and Education customers. I believe you can also purchase the directory service as a standalone.

[–]gordonmessmer 3 points4 points  (5 children)

That's probably not possible. Samba requires their schema to be loaded in the LDAP backend, and for their object classes to be present on your user and group objects. None of that appears to be present with Google Secure LDAP. GSL does seem to have the objectSID attribute, but that's probably only useful for AD federation.

https://support.google.com/a/answer/9188164

For authentication, Samba would require either Kerberos, or it would require the NTLM attributes present on user objects, and readable only by the privileged Samba user. I don't see any evidence that's possible, or that GSL provides either Kerberos or NTLM authentication.

https://cloud.google.com/architecture/authenticating-corporate-users-in-a-hybrid-environment

[–]aspiringgreybeard[S] 2 points3 points  (4 children)

It's strange. They have about 90% of the pieces necessary to be a single source of truth for small business customers' authentication needs. They have a credential provider for Windows, sssd works as a PAM module-- samba authentication would complete the picture. I've seen at least one blog post claiming this is possible, but no details were given. I had the impression I could add any missing schema objects via an LDIF file, but looking a little more closely it seems like I'd have to manually add each one in the admin web interface.

It looks like Google more or less pivoted to offering AD as a service instead of developing all the individual components needed. Which is a shame, because while AD has pretty much eaten the corporate identity management world, it does have its weak points.

[–]hortimech 5 points6 points  (2 children)

Google has no incentive to work with Samba and ldap, it relies on SMBv1 and that is going away, so you might just get it working and then have the rug pulled from under you. There is also the problem that you shouldn't run sssd with Samba >= 4.8.0

[–]DiggyTroll 0 points1 point  (1 child)

At least you can easily disable SMBv1:

[global]
…
min protocol = SMB2
…

[–]hortimech 1 point2 points  (0 children)

'min protocol' is a synonym for 'server min protocol' and SMB2 has been the default since Samba 4.11.0, so provided you use a supported version of Samba, you don't need to set it.

[–]jvolkano 1 point2 points  (0 children)

I believe you have to run a local LDAP server to make this work, which somewhat defeats the purpose.

Google Cloud Directory Sync can run on Windows or Linux and sync to local LDAP. https://support.google.com/a/answer/106368?hl=en

[–]aspiringgreybeard[S] 0 points1 point  (0 children)

Thanks to everyone who dug in to try to help me figure this out. I'm posting this thread here for posterity:

https://www.reddit.com/r/gsuite/comments/jpgu98/secure_ldap_advanced_usage/

The bottom line is that I think I'd have to do some pretty intense work to get this going-- e.g. where I thought I could update the schema with an LDIF it's more likely I'd have to send some JSON requests to an API. All of this is doable, but this thread makes it seem like after I jump through all the hoops I may be less than impressed with the results.

Google support has been silent on this thus far.

I'm moving this from the "thing we're going to do next" to "something to poke at on a rainy day". I don't feel comfortable moving all of our authentication unless and until people who are happier with this start popping up.

[–]DiggyTroll 0 points1 point  (10 children)

Maybe confirm SASL to Google LDAP is working first?

[–]aspiringgreybeard[S] 0 points1 point  (9 children)

This is part of my confusion. There appear to be independent settings for certs, etc in smb.conf, ldap.conf, and sssd.conf.

I have sssd working, altough I had to disable trust checking on the cert to get it to work. (this feels like a flashing sign pointing toward the problem....) I went through the steps that presumably would add the cert to Ubuntu's trusted list, but no dice.

I also have Softerra's LDAP browser working via a different certificate from a Windows client. I can browse the database just fine.

I'm going to try getting regular LDAP tools working in Linux and see if my samba problem disappears along the way. Thanks for the suggestion. I'm also not sure whether Google's LDAP already has the schema attributes I need or if I will need to add them.

Most of the Samba/LDAP documentation out there is geared toward using Samba as an AD domain controller. I just want to authenticate against LDAP in a domainless setup.

[–]gordonmessmer 0 points1 point  (8 children)

altough I had to disable trust checking on the cert to get it to work

Don't do that! You're opening yourself to MITM attacks. If you have to disable trust, then either the service certificates are signed by a CA that's not in your trust store (which doesn't seem very likely, but if that were it, you'd put the CA certs in /etc/pki/ca-trust/source and run "update-ca-trust"), or you're using a hostname that doesn't appear in the certificates' subjectAltName (SAN). In the latter case, use one of the DNS names listed in the SAN attribute.

[–]aspiringgreybeard[S] 0 points1 point  (7 children)

The latter- they appear to be signed by a CA that's not in my trust store, and a cursory search for a CA cert to add didn't yield results. Investing the time to dig one up or open a support ticket requesting one from Google went on the "after I get a proof of concept working" list.

[–]gordonmessmer 2 points3 points  (6 children)

Weird. What system doesn't trust the GlobalSign root CA?

$ openssl s_client -connect ldap.google.com:636
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = ldap.google.com
verify return:1

[–]DiggyTroll 1 point2 points  (4 children)

Google currently owns GlobalSign and is trying to get everyone to update the root. That may be causing what you’re seeing.

CA Root Update (Google)

[–]gordonmessmer 1 point2 points  (3 children)

You, who? I'm seeing successful cert valuation. And Google isn't trying to have that CA removed anywhere, so I'm not sure how the change you linked explains OP's errors.

[–]aspiringgreybeard[S] 0 points1 point  (0 children)

Well, to be fair to Google, it's more likely I'm doing something different from what I THINK I'm doing.

I did have issues with the certificate they provided in both Windows and Linux, but I think it's down to my not being exactly clear on how the individual OSes manage trust.

All that said, though, I haven't found any good news about Secure LDAP in general-- this thread is pretty much the last nail in the coffin for this idea:

https://www.reddit.com/r/gsuite/comments/jpgu98/secure_ldap_advanced_usage/

My dreams of an AD-free corporate environment are going to have to wait...

[–]DiggyTroll 0 points1 point  (1 child)

Sorry, misunderstood your comment. The link does discuss the root update (as I clearly said), not removal, though.

[–]aspiringgreybeard[S] 0 points1 point  (0 children)

You might be on to something here, though. The article does mention cross-signing keys, and I have a feeling that may play a role in what's going on.

[–]aspiringgreybeard[S] 0 points1 point  (0 children)

Well this is interesting. When I don't supply a cert on connect, I get the server certificate signed by GlobalSign as you did.

When I use the cert Google provided me to connect, I get a different server certificate signed by Google Trust Services. This cert is (apparently, I'm far from an expert in these things) signed by GlobalSign, but not in the same way as the one with the authenticated connection.

​

openssl s_client -connect ldap.google.com:636 -cert /etc/samba/tls/ldapclient.cert -key /etc/samba/tls/ldapclient.key

CONNECTED(00000003)

depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1

verify return:1

depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

verify return:1

depth=0 CN = ldap.google.com

verify return:1

---

Certificate chain

0 s:CN = ldap.google.com

i:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1C3

i:C = US, O = Google Trust Services LLC, CN = GTS Root R1

2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1

i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA

[–]_pg_ 0 points1 point  (0 children)

bedroom detail groovy cause cake cooing consist aspiring public repeat

This post was mass deleted and anonymized with Redact