On 07/30/2013 11:53 AM, Chris Hartman wrote:
Ah. It appears I now have a reason to perform SASL binds over LDAPS.
Active Directory guys are complaining; they say the AD server is
throwing errors that some clients are performing unsigned SASL binds.
When signing is required on the server, bind attempts from SSSD clients
So, I ask again, is there a way I can force my SSSD clients to use LDAPS?
I looked in the trac to see what we have there relevant to your case.
I also found this
But it is to use the actual PKI authentication for the client connection
not to just armor the tunnel.
So it looks like we do not have a RFE to cover what you are looking for.
I wonder if you can override the default configuration and use
certificates anyways on top of GSSAPI.
I think so but we actually want to remove this capability. See
So may be we should not do it and allow for double tunneling for cases
like this? But it is extremely inefficient.
Can AD guys allow SASL GSSAPI binds? I think that would be the simplest
as it has same security attributes as bind over the LDAPS.
On Wed, Jul 24, 2013 at 5:07 PM, Chris Hartman <qrstuv(a)gmail.com
Ah. I did not realize that. I thought some directory information might
over in plaintext as with normal LDAP binds. Since this is not
the case, I'm happy!
On Wed, Jul 24, 2013 at 4:39 PM, Stephen Gallagher <sgallagh(a)redhat.com
On 07/24/2013 03:50 PM, Chris Hartman wrote:
> Hi guys!
> Is there anyway I can force my SSSD clients running 1.9.5 (Ubuntu
> 12.04) and 1.9.2 (CentOS 6) to bind to LDAPs (port 636) instead of
> LDAP (port 389) when my providers are all set to "ad"?
Why would you want to do this? The GSSAPI communication provided by
the Kerberos keytab is already encrypting all communication you send
on port 389.
sssd-users mailing list
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?