Google Secure LDAP

[CoreyAbels]

Good evening gents,

Does anyone have experience setting up a Kyocera (specifically a 6054ci) to use Google Secure LDAP as an external address book? I have spoken to the client, and according to the screenshots and Google documentation, it appears to be setup correctly. However, when the client tests the LDAP connection he gets a 0X1102 error. My assumption, based on other communication errors is that it is a user name/password error. Based on my research into Google Secure LDAP setup, when you setup the LDAP client in the Google Admin Console, there is a Certificate generated for authentication and this is my question, can that certificate be loaded onto the copier for authentication purposes or is there some other method of setup to get the Secure LDAP to function properly? Thank you!

[slimslob]

Re: Google Secure LDAP

THe following thread from kyocera-mita-copystar, where you should have posted in the first place may help. Error 1102 scanning to email with local authentication - Kyocera m2040

[PrintWhisperer]

Re: Google Secure LDAP

Is your LDAP port set to 636(LDAPS) rather than 389(LDAP)?

Secure LDAP is wrapped in SSL/TLS encryption.

At this point you are bound to TLS compatibility with the server. The device should have it's Network Security options set to the SHA level of the Server. (Which should NOT be allowing SHA1/TLS 1.0)

If SHA 1 is disabled on the device (per Cloud Email rules) but allowed on the Server, this has been seen to cause a TLS negotiation error.

P.S. Any device TLS setting changes are to be made in the CLIENTSIDE section, not the Server-Side section as the MFP is acting as a Client here.

[CoreyAbels]

Re: Google Secure LDAP

THe following thread from kyocera-mita-copystar, where you should have posted in the first place may help. Error 1102 scanning to email with local authentication - Kyocera m2040

While I appreciate the response, the forum post you referenced has nothing to do with what I am trying to accomplish. We're talking about connecting the Kyocera MFD to a Google Secure LDAP server. I can fix scan to email issues all day long LOL.

[CoreyAbels]

Re: Google Secure LDAP

Is your LDAP port set to 636(LDAPS) rather than 389(LDAP)?

Secure LDAP is wrapped in SSL/TLS encryption.

At this point you are bound to TLS compatibility with the server. The device should have it's Network Security options set to the SHA level of the Server. (Which should NOT be allowing SHA1/TLS 1.0)

If SHA 1 is disabled on the device (per Cloud Email rules) but allowed on the Server, this has been seen to cause a TLS negotiation error.

P.S. Any device TLS setting changes are to be made in the CLIENTSIDE section, not the Server-Side section as the MFP is acting as a Client here.

Thank you for the response, however we seem to be dealing with a bit of a different beast than a traditional, on-site LDAP server. Google Secure LDAP is initiated in the Google Workspace Admin Console. You create an LDAP client, you select a few options, turn the client on, it CREATES a certificate and you go on about your business. The problem is this, the certificate is required (NOT a user name/password combo) to access the Google LDAP client, and if this was an app (think PaperCut) you'd be able to install the certificate in the app and go on your merry way. My question is this, if you install the certificate on the Kyocera MFD directly will it work as an authentication certificate and allow the machine to access and authenticate to the Google LDAP client?

[PrintWhisperer]

Re: Google Secure LDAP

Alright, yes not typical but the LDAP protocol is what it is, even if Google is using it. They just have an extra step of not trusting the device cert and making you install theirs.

Apparently their Port 389 invokes StartTLS, and Port 636 invokes SSL/TLS. I cannot say which is correct for your case.
Both must use a certificate for the SSL/TLS wrapper.

You may upload the certificate to the device (CommandCenterRX - Security Settings - Certificates) although I do not see anything about a key file.


This has been the 'rub' with cloud connections lately. Overly complicated connectivity requiring advanced methodolgies not fully fleshed out from the MFP interface standpoint.

The LDAP client app using the Google Cert is the MFP's API (firmware)

Last time I messed with Certificates, we could not delete the default device cert or ensure the added cert was used as the primary. Aside from that I have never had to deal with device cert modifications.

[CoreyAbels]

Re: Google Secure LDAP

Alright, yes not typical but the LDAP protocol is what it is, even if Google is using it. They just have an extra step of not trusting the device cert and making you install theirs.

Apparently their Port 389 invokes StartTLS, and Port 636 invokes SSL/TLS. I cannot say which is correct for your case.
Both must use a certificate for the SSL/TLS wrapper.

You may upload the certificate to the device (CommandCenterRX - Security Settings - Certificates) although I do not see anything about a key file.


This has been the 'rub' with cloud connections lately. Overly complicated connectivity requiring advanced methodolgies not fully fleshed out from the MFP interface standpoint.

The LDAP client app using the Google Cert is the MFP's API (firmware)

Last time I messed with Certificates, we could not delete the default device cert or ensure the added cert was used as the primary. Aside from that I have never had to deal with device cert modifications.

Ok, that is some of the information that I have been searching up and down the interwebs for LOL.

So here is the standard form for accessing Google LDAP:

Port: 389 or 636
Security Protocol: STARTTLS or SSL/TLS

There is no distinction or required setting from what I can tell.

The Google generated certificate must me loaded into the application accessing Google LDAP, and if you cannot load the certificate you must Stunnel to provide the certificate and then point the client to Stunnel.

Now, in my estimation a proper configuration would include the following:

Creating and saving the Certificate/Key on a Server
Installing/Configuring Stunnel on said Server
Pointing the MFP back to said Server via the LDAP section of the Command Center RX (inputting a server username/password) to gain access to the Server.

If I am understanding you correctly, I could theoretically install the certificate on the device itself but an MFP does not make a distinction between certificates and likely would not store the key required to use the certificate? Is that accurate? TIA

[slimslob]

Re: Google Secure LDAP

While I appreciate the response, the forum post you referenced has nothing to do with what I am trying to accomplish. We're talking about connecting the Kyocera MFD to a Google Secure LDAP server. I can fix scan to email issues all day long LOL.

The second in that thread tells you exactly what the error code you are getting means. 0X1102 error is an authentication error. It makes no difference if you are logging in toe an SMTP server or a LDAP server. It is a standard searchable error code. Check the damned spelling on the user name and password. If I remember correctly LDAP authentication is case dependent.

[CoreyAbels]

Re: Google Secure LDAP

The second in that thread tells you exactly what the error code you are getting means. 0X1102 error is an authentication error. It makes no difference if you are logging in toe an SMTP server or a LDAP server. It is a standard searchable error code. Check the damned spelling on the user name and password. If I remember correctly LDAP authentication is case dependent.

Yes sir, I understand that 1102 is a username/password problem on SMB, SMTP, etc. I know that it is an authentication issue, but Google LDAP uses a certificate to authenticate, not a username/password. That is the issue I am trying to work around. If this was a traditional on-site LDAP server, I'd have the user check, double check, and triple check the username/password they're entering to make sure that it is not fat fingered, or typed with caps lock on, or whatever other silly reason for it to be entered incorrectly. 👍🏻

[slimslob]

Re: Google Secure LDAP

Yes sir, I understand that 1102 is a username/password problem on SMB, SMTP, etc. I know that it is an authentication issue, but Google LDAP uses a certificate to authenticate, not a username/password. That is the issue I am trying to work around. If this was a traditional on-site LDAP server, I'd have the user check, double check, and triple check the username/password they're entering to make sure that it is not fat fingered, or typed with caps lock on, or whatever other silly reason for it to be entered incorrectly. 👍🏻

Most likely the Certificate is a device Certificate. It identifies the device, i.e. the Kyocera, but not the user. You need to have a user specified that is valid on the LDAP server.

[PrintWhisperer]

Re: Google Secure LDAP

Ok, that is some of the information that I have been searching up and down the interwebs for ....

If I am understanding you correctly, I could theoretically install the certificate on the device itself but an MFP does not make a distinction between certificates and likely would not store the key required to use the certificate? Is that accurate? TIA

That is my fear, that the MFP certificate system doesn't support the direct method so the stunnel fallback option must be used.

I am interested in seeing you get this to work because someone is going to ask me to do it someday soon I fear, so I may run it up the chain for an opinion.
As for your checklist, I want to be sure we are talking the same method which is the stunnel fallback when you cannot make the needed LDAP Client modifications.

You cannot make these modifications because the LDAP Client is embedded in the MFP Operating System (A certain Linux version running OPEN_SSL) and you have no Operating System file access outside of the Command Center API options for Certificates.
It would be interesting for you to go through the Command Center and see what happens if you do try and upload the cert file. Specifically, whether there is a provision for the key file upload.


SO for stunnel your steps (4. Connect LDAP clients to the Secure LDAP service - Google Workspace Admin Help) match up but the difference at the MFP is that stunnel communicates with the client (MFP) on port 1636 by default.

The instructions there are for a client on the server so all configuration IP addresses are set to loopback (127.0.0.1), you need to modify that in 2 places from what I see.

1) In stunnel config:
[ldap]
client = yes
accept = 127.0.0.1:1636 127.0.0.1 should be replaced with MFP device IP address (client)
connect = ldap.google.com:636 Note stunnel IS connecting on port 636 to google
cert = ldap-client.crt
key = ldap-client.key

2) Configure your application (read as 'MFP') to point to ldap://127.0.0.1:1636. 127.0.0.1 should be replaced with Server IP running stunnel.
This is accomplished at the MFP LDAP section by entering the server IP and specifying the port as 1636. Whether you would need a username and password to connect to stunnel is not specified, so I am thinking you do not even though fields are provided for their entry on the MFP.
If that is not accepted then, as pointed out, it would be an account local to the server, as the stunnel-to-google connection is authenticated by the certificate but with the LDAP Security set to OFF I think not.

Additionally the instructions note:
You can replace “1636” with any unused port if you also change the accept line in the configuration file above. You'll need to use plaintext LDAP without StartTLS/SSL/TLS enabled between the client and stunnel, since they are communicating locally So in the MFP ensure LDAP Security is set to OFF

The port information I referred to and link to stunnel config settings were found further UP the page in the hyperlink above.



I look forward to your results!

[rthonpm]

Re: Google Secure LDAP

1) In stunnel config:
[ldap]
client = yes
accept = 127.0.0.1:1636 127.0.0.1 should be replaced with MFP device IP address (client)
connect = ldap.google.com:636 Note stunnel IS connecting on port 636 to google
cert = ldap-client.crt
key = ldap-client.key

2) [SIZE=1]Configure your application (read as 'MFP') to point to ldap://127.0.0.1:1636. 127.0.0.1 should be replaced with Server IP running stunnel.
[SIZE=2]

This is entirely incorrect.

Client mode for STunnel means that it is forwarding data onto a source that will add the encryption. The opposite mode is Server where STunnel is passing through data that is already encrypted.

Accept is the IP on the host running STunnel that will accept connections. Generally it will be set to the loopback address or the device's actual IP as well as the port that STunnel should listen on.

Connect is where it will forward the data it collects to.

Cert and key are the public certificate and private key for the STunnel server, not all services need this.

For LDAP, you would configure all of the information on the MFP in terms of your BaseDN, search attribute, and BindDN for the end LDAP server from Google. The only change is that you use the IP or hostname of your STunnel server as the LDAP server as the data will be passed onto Google.

If installing on a Windows machine it will create a self signed certificate on its own. Linux installs will have to create one using OpenSSL.

Sent from my Pixel 6 Pro using Tapatalk

[PrintWhisperer]

Re: Google Secure LDAP

This is entirely incorrect.

.....

First, find a better way to word your disagreement, you are being disrespectful.

Calm down, have another drink in whatever bar your probably still in and re-read that Google page. The instructions are rather clear.

You of all people should be able to see your mistake here, I am not bothering to correct you.

[slimslob]

Re: Google Secure LDAP

First, find a better way to word your disagreement, you are being disrespectful.

Calm down, have another drink in whatever bar your probably still in and re-read that Google page. The instructions are rather clear.

You of all people should be able to see your mistake here, I am not bothering to correct you.

The remarks is red text that apparently you added are what you added are what are not correct. You also failed to specify the name of the configuration file. Below is the actual text from the Google Support document,

Create a configuration file /etc/stunnel/google-ldap.conf with the following contents (assuming ldap-client.crt is the cert, and ldap-client.key is the key):

[ldap]
client = yes
accept = 127.0.0.1:1636
connect = ldap.google.com:636
cert = ldap-client.crt
key = ldap-client.key

Of course since Google's instruction are actually for a client application running on the same server as Stunnel, the MFP will need to point to the actual address of the server on the LAN. Additional information from Google for when the app is not on the same server:

If you choose to run stunnel on a separate server, you must configure your firewalls so that only the necessary applications can access your stunnel server.

A firewall setting should be added to allow traffic form the IP address of the MFP to the internal IP address and port number of the accept line. The accept line will allow Stunnel to monitor that port through the internal IP address 127.0.0.1 with the firewall now being the app that is sending to it.

[CoreyAbels]

Re: Google Secure LDAP

The remarks is red text that apparently you added are what you added are what are not correct. You also failed to specify the name of the configuration file. Below is the actual text from the Google Support document,


Of course since Google's instruction are actually for a client application running on the same server as Stunnel, the MFP will need to point to the actual address of the server on the LAN. Additional information from Google for when the app is not on the same server:

A firewall setting should be added to allow traffic form the IP address of the MFP to the internal IP address and port number of the accept line. The accept line will allow Stunnel to monitor that port through the internal IP address 127.0.0.1 with the firewall now being the app that is sending to it.

Again, we're not talking about using Stunnel for SMTP. We're talking about using Stunnel (per Google) to setup an External Address Book, using Google Cloud Directory (Google Secure LDAP). Per Google setup instructions: if the device that is accessing Google Secure LDAP CANNOT store the necessary authentication certificate, than Stunnel must be used to access a device that CAN store said certificate.

This is a brand new TASKalfa 6054ci and while it does have the ability to store both Device Certificates AND Root Certificates, I see no way to enable/choose those certificates for the LDAP protocol. You can enable them for OTHER protocols, but that is NOT helpful for this particular application.

There are OTHER solutions to this problem, such as using PaperCut and MyQ (both applications that allow for the storage of the authentication certificate), but I'm simply trying to find out if we can avoid using either application and connect to Google Secure LDAP directly. It would appear as though that is not YET possible, without additional configuration and network gymnastics.