[ZendTo] Partially Solved: Re: AD/LDAP Authentication Help
Craig Chambers
craig at craigchambers.net
Wed Mar 30 02:12:40 BST 2011
Success! Two things (I think) fixed it.
The first was a bone headed mistake from me changing/looking over things too
much: I had the 'authenticator' => 'AD' line commented out so no
authentication was even attempted (>_<)
After fixing that embarrassing mistake AD authentication worked when SSL was
set to 'false' but no 'true'. It appears thee is still some issue with the
certificate being correctly validated. I have found a partial solution I
thought I would pass on in case anyone else runs into this issue. It may be
something you can add a a switch as well in future versions.
After doing some more digging (I have been searching Google for weeks
looking for AD/LADP solutions but your suggestion to include PHP in the
search is what did it) I found this little gem from
http://php.net/manual/en/function.ldap-bind.php:
> TLS_REQCERT never
>
> The reason is, I think, because it doesn't understand the certificate, so this
> directive tells it to not bother checking it. I guess that could be unsafe in
> some cases, but in my case I'm confident with the server I'm connecting to.
>
Adding that to my ldap.conf file finally allowed SSL AD authentication. In
doing some further reading I found this explanation for that setting from
this site
http://www.openldap.org/lists/openldap-software/200903/msg00148.html:
> "TLS_REQCERT never" actually just disables the client's check that the name
> from the URI matches the cert's subjectAltName values or CN. It'll be
> encrypted, but with no protection from man-in-the-middle attacks, or even
> detection of simple misconfigurations (CNAME pointing at wrong host, etc).
>
> "TLS_REQCERT allow" is only slightly better, doing the name check (so some
> misconfigs will be caught) but still skipping the check for a known CA, so
> it's still vulnerable to MitM attacks. If you're going to go to the trouble
> to use TLS, why not distribute the certs and do it right?
>
Setting TLS_REQCERT to "allow" did not work for me so that implies to me
that there is still a SAN issue. I have added the self-signed public
certificate what includes the SAN name to my Ubuntu server in etc/ssl/certs
folder but it doesn't seem to work. For the time being at least this partial
solution is acceptable. While I am theoretically open to a man-in-the-middle
attack, since it is over a local network the chances of that are small and
at least the authentication traffic is encrypted so that packet sniffing
would be ineffective.
Thanks for all your help, if I decide to tackle the certificate issue and
discover any solutions I will post a followup.
Now to be a masochist and try to build a new Hyper-V VM from scratch to make
sure I know which are the required steps ;-)
On that note, does the new APT repository configure PHP for files greater
than 2GB automatically? I have some problems recompiling my PHP and didn't
know if that would help?
Thanks again,
- Craig
From: Jules <Jules at zend.to>
Organization: ZendTo
Reply-To: ZendTo Users <zendto at zend.to>
Date: Tue, 29 Mar 2011 09:14:25 +0100
To: ZendTo Users <zendto at zend.to>
Subject: [ZendTo] Re: AD/LDAP Authentication Help
1 more thing. Have you got it working over LDAP (rather than LDAPS) first?
If you let your SBS authenticate without SSL connections, then you can at
least test that much first.
Jules.
On 28/03/2011 23:17, Craig Chambers wrote:
>
> First let me apologize for the length of this email. When I get into
> situations like this I find it is best to be as detailed as possible as it is
> usually some assumption or unsaid detail that turns out to be the solution.
>
>
>
>
> Second, I think I am having other, more fundamental issues than just
> certificate/AD authentication errors since I can't seem to add new users using
> the included scripts.
>
>
>
>
>
>>
>> ~$ sudo /opt/zendto/bin/adduser.php /opt/zendto/bin/preferences.php 'MyAdmin'
>> '<password>' '<email address>' 'Administrator' '<organization>'
>>
>> PHP Warning: include(/opt/zendto/bin/preferences.php): failed to open
>> stream: No such file or directory in /opt/zendto/bin/adduser.php on line 28
>> PHP Warning: include(): Failed opening '/opt/zendto/bin/preferences.php' for
>> inclusion (include_path='.:/usr/share/php:/usr/share/pear') in
>> /opt/zendto/bin/adduser.php on line 28
>> PHP Notice: Use of undefined constant NSSDROPBOX_LIB_DIR - assumed
>> 'NSSDROPBOX_LIB_DIR' in /opt/zendto/bin/adduser.php on line 29
>> PHP Warning: require_once(NSSDROPBOX_LIB_DIRSmartyconf.php): failed to open
>> stream: No such file or directory in /opt/zendto/bin/adduser.php on line 29
>> PHP Fatal error: require_once(): Failed opening required
>> 'NSSDROPBOX_LIB_DIRSmartyconf.php'
>> (include_path='.:/usr/share/php:/usr/share/pear') in
>> /opt/zendto/bin/adduser.php on line 29
>>
>>
>>
>>
>>
>
> Is this permissions related? I assume I need to use sudo because I get the
> usage message when trying to add users without and lots of permission errors
> when using the listusers script.
>
>
>
>
>
> Finally let me address the certificate issue.
>
>>
>> "If your AD doesn't have a proper certificate, then you will have all sorts
>> of nasty problems making things work. You really need a proper SSL
>> certificate."
>>
>>
>>
>>
>
> Let me start of by saying that the LDAP server I am authenticating to is SBS
> 2008. As with most SBS boxes, this server has an internal name of
> server.domain.local but also can be reached externally from
> remote.externaldomain.com. For those reading this who may not know, SBS
> creates several certificates when it is set up. First it creates a self signed
> root certificate for all other certificates issued by that server. The
> certificate name is DOMAIN-SERVER-CA. It also creates an Alternative Name
> Certificate (sometimes called SAN or UC) certificate whose trusted root is
> DOMAIN-SERVER-CA. with a cn=remote.externaldomain.com but that includes
> server.doamin.local as an alternative name. This is the certificate that the
> domain uses for LDAP and AD encryption and authentication.
>
>
>
>
> To create a publicly trusted certificate you can run a wizard (which when
> talking to MS SBS support, highly recommends using) which will allow you to
> create a certificate that is signed by a trusted third party (verisign,
> equifax, etc). The only issue with this public certificate is that it is a
> simple SSL web certificate made to validate remote.externaldomain.com and is
> NOT an Alternate Name Certificate. MS support has confirmed that this
> certificate is only used for email and Remote Web Workplace access. It is not
> and cannot be used for LDAP authentication. MS Active Directory support has
> told me that the certificate used for LDAP validation MUST include the server
> name (I.e. SERVER.domain.local and NOT remote.externaldomain.com) This leaves
> an SBS server with three supported certificate options:
>
> 1. Use the DOAMIN-SERVER-CA self-signed cert for authentication and put a copy
> of its public key in the Ubuntu servers list of trusted certificates (can't
> get that to work)
> 2. Obtain an Alternative Name Certificate (expensive relative to the simple
> web certificate. Possible to do would prefer a cheaper alternative)
> 3. Use the self-signed remote.domain.com certificate and have the zendto
> server ignore trust errors, which would allow encryption but in theory would
> expose you to a man in the middle attack. (Not sure if this is possible)
>
>
>
>
> The first and third options are the least expensive except and therefore
> preferable. I have tried installing the certificate on the Ubuntu server in
> several places but the SERVER-DOMAIN-CA certificate is still read as untrusted
> by gnutls-cli. I am not sure if this is a gnutls error or a certificate
> problem. Maybe it doesn't matter since the handshake is occurring internally
> and if encryption is occurring anyway (not sure if it is or not). For now, a
> man-in the-middle attack on my internal network isn't a big concern.
>
>
>
>
> After playing around with the ldp.exe utility and ldapsearch here is a list of
> what works and doesn't. I am including the ldp.exe list because that at least
> lets us know what is working from a windows perspective.
>
>
>
>
> ===LDP.EXE===
>
> Connecting to the server <server.domain.local> with SSL (port 636) = works
> (SSL over 389 does not work but that isn't surprising)
>
> Supported SASL Mechanisms are listed as: GSSAPI; GSS-SPNEGO; EXTERNAL;
> DIGEST-MD5;
>
>
>
>
> Start TLS = failed (I assume this is because am already connected to the
> server via SSL)
>
>
>
>
>>
>> Bind Simple with DOMAIN\LDAP or LDAP at domain.local and < LDAP password> =
>> Authenticated as DOMAIN\LDAP
>>
>>
>>
>>
>> Bind Simple using only LDAP and <password> (no domain) = Failed, Invalid
>> Credentials
>>
>>
>>
>>
>> Bind Simple with no credentials = Authenticated as NT Authority\Anonymous
>> Login
>>
>>
>>
>>
>> Bind with credentials USER:LDAP PASSWORD:<password> DOMAIN:domain =
>> Authenticated as DOMAIN\LDAP
>>
>>
>>
>> Bind Advanced (DIGEST) with USER:LDAP PASSWORD:<password> DOMAIN:domain =
>> Failed Server error: 8009030C: LdapErr: DSID-0C0904D1, comment:
>> AcceptSecurityContext error, data 52e, v1772 Error 0x8009030C The logon
>> attempt failed
>>
>>
>>
>>
>> Bind Advanced (SASL) = Failed. Error <7>: ldap_bind_s() failed:
>> Authentication Method Not Supported.
>>
>>
>>
>>
>
> Connecting to the server <server.domain.local> without SSL (port 389) = works
> same result as above
>
>
>
>
> Start TLS = works ldap_start_tls_s(ld, &retValue, result, SvrCtrls,
> ClntCtrls) result <0>
>
> All the bind results are the same
>
>
>
>
> ===GNUTLS===
>
> Running "gnutls-cli --print-cert -p 636 server.domain.local" from the Ubuntu
> box I get:
>
>
>
>
>>
>>
>> - Successfully sent 0 certificate(s) to server.
>>
>> - Server has requested a certificate.
>>
>> - Certificate type: X.509
>>
>> - Got a certificate list of 1 certificates.
>>
>> - Certificate[0] info:
>>
>> - subject `CN=remote.externaldomain.com', issuer `CN=domain-SERVER-CA', RSA
>> key 2048 bits, signed using RSA-SHA
>>
>>
>>
>>
>> -----BEGIN CERTIFICATE-----
>>
>> <Certificate key>
>>
>> -----END CERTIFICATE-----
>>
>>
>>
>>
>> - The hostname in the certificate matches 'server.domain.local'.
>>
>> - Peer's certificate issuer is unknown
>>
>> - Peer's certificate is NOT trusted
>>
>> - Version: TLS1.0
>>
>> - Key Exchange: RSA
>>
>> - Cipher: AES-128-CBC
>>
>> - MAC: SHA1
>>
>> - Compression: NULL
>>
>> - Handshake was completed
>>
>>
>>
>>
>> - Simple Client Mode:
>>
>>
>>
>>
>>
>
> ===LDAPSEARCH===
>
> And finally some different ldapsearch results:
>
>
>
>
>>
>>
>> ~$ ldapsearch -D LDAP -H ldaps://server.domain.local -b
>> "ou=Users,,dc=doamin,dc=local" sAMAccountName
>>
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>
>>
>>
>>
>>
>> ldapsearch -w <password> -D LDAP at domain.local -H ldap://server.domain.local
>> -b "ou=Users,dc=domain,dc=local" sAMAccountName
>>
>> WORKS! Lists users.
>>
>>
>>
>>
>>
>> ~$ ldapsearch -w X0YnUm7NVHjdGJK0ncSOkAlmmyPHYN15X6oPWOtrvhu1aGEMCm -D
>> LDAPQuery -H ldap://thor.henryv.local -b
>> "ou=SBSUsers,ou=Users,ou=MyBusiness,dc=henryv,dc=local" sAMAccountName
>>
>> ldap_bind: Invalid credentials (49)
>>
>> additional info: 80090308: LdapErr: DSID-0C0903AA, comment:
>> AcceptSecurityContext error, data 525, v1772
>>
>>
>> (I assume this is related to the ldp.exe error using simple bind with no
>> @domain.local)
>>
>
>
>
>
> If you want ssh or vnc access to the server please contact me outside the
> mailing list for login credentials.
>
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.tohttp://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto
>
Jules
--
Julian Field MEng CITP CEng
www.Zend.To <http://www.Zend.To>
Follow me at twitter.com/JulesFM
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
'All programs have a desire to be useful' - Tron, 1982
_______________________________________________ ZendTo mailing list
ZendTo at zend.to http://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20110329/4786effa/attachment-0001.html
More information about the ZendTo
mailing list