[ZendTo] Re: AD/LDAP Authentication Help

[Craig Chambers]

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. Here is the message I get when I try to add a
user with the adduser.php script:

> ~$ 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20110328/c7c16e8d/attachment.html