[ZendTo] Re: Partially Solved: Re: AD/LDAP Authentication Help

Jules Jules at Zend.To
Wed Mar 30 11:24:29 BST 2011



On 30/03/2011 02:12, Craig Chambers wrote:
> Success! Two things (I think) fixed it.
Well done! I will add a page mentioning you ldap.conf tweak.
>
> 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?
The APT repo does not attempt to recompile PHP, no. For now I have just 
set the defaults to only allow 2GB uploads in preferences.php so it's 
not an issue when you're first installing it. If you want to crack the 
2GB nut, you can come back later and fix it yourself.

The snag is that the libphp5.so binary would need recompiling after 
every time it is patched by an Ubuntu/RedHat update, which is beyond my 
control to do automatically.

Jules.

P.S. If you are interested in beta-testing the new user interface, 
please let me know.
>
> Thanks again,
>
> - Craig
>
> From: Jules <Jules at zend.to <mailto:Jules at zend.to>>
> Organization: ZendTo
> Reply-To: ZendTo Users <zendto at zend.to <mailto:zendto at zend.to>>
> Date: Tue, 29 Mar 2011 09:14:25 +0100
> To: ZendTo Users <zendto at zend.to <mailto: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
>>     <mailto: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
>>     *B**ind Advanced (DIGEST)* with USER:LDAP PASSWORD:<password>
>>     DOMAIN:domain = Failed Server error: 8009030C: LdapErr:
>>     DSID-0C0904D1, comment: AcceptSecurityContext error, data 52e,
>>     v1772Error 0x8009030C The logon attempt failed
>>     *
>>     *
>>     *B**ind 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* = worksldap_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
>
> 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 <mailto:ZendTo at zend.to> 
> http://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto
>
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto

Jules

-- 
Julian Field MEng CITP CEng
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/zendto/attachments/20110330/640a09b8/attachment-0001.html 


More information about the ZendTo mailing list