External website, authenticates against Active Directory using LDAPS. Website is coded in PHP, and runs on IIS on Windows Server 2008 R2 x64.

In the rest of the world, this is an Apache deal, but limited by internal support, it has to be IIS and Windows.

Requirements to make this work:

• Active Directory domain controller (DC), configured as an Enterprise Certification Authority
• Firewall opened from web server to DC on either TCP port 636 or 3269 (3269 is the LDAPS port for a Global Catalog)
• Windows Server (I’d say any of the 2003/2008 versions will work)
• IIS (6 or 7)
• PHP (I’m using version 5.3.6) with the php_ldap extension

Getting there:

1. Configure AD OU’s / security groups to suit your application
2. Generate a Root CA certificate for your domain/domain controllers
3. Export the Root CA in Base64 X.509 format
4. Copy Root CA certificate to the webserver (C:\OpenLDAP\sysconf\webcert.crt)
5. Create C:\OpenLDAP\sysconf\ldap.conf with the following lines:
   TLS_REQCERT never
   TLS_CACERT c:\openldap\sysconf\webcert.crt
6. Install PHP on the webserver, using the IIS FastCGI installer option, and enabling the LDAP extension (if you use the installer, that is. If you do a manual install, you have to install/configure these manually.)
7. Use ldap_connect(“ldaps://servername//”) to connect – if using the global catalog, specify the port in the URL, i.e. servername:3269

Code:

<?php
$ds=ldap_connect("ldaps://servername/");
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);
$ldapbind = @ldap_bind($ds, "username@contoso.msft", "password");
if($ldapbind) {
// do some stuff
} else {
echo ldap_error();
}
ldap_close($ds);
?>

Final Notes:

Provided all is done as above, should be able to connect to LDAPS perfectly. Use “ldp.exe” to check LDAP connectivity using SSL (use port 636 or 3269 – not 389 as is the default), or any other LDAP tool that supports LDAP with SSL.

I got caught out exporting the Root CA certificate from the certificate store as a DER Encoded X.509 certificate, instead of Base64. Yes, it matters.

There is very little documentation for this solution – specifically the certificate requirements. LDAPS in generally is supported quite well, as is configuring Active Directory to serve up LDAPS. Even the PHP coding is well supported. The Windows/IIS/PHP/LDAPS combination as a whole, however, is best documented…right here, of course

Lastly – there’s a bug in some versions of the PHP LDAP module (5.3.3 I believe fixed it), which required you to place the ldap.conf file at the root of every drive that hosts an IIS website – or, just the one that utilises the LDAP file. I haven’t tested this, but it is discussed very briefly on some of the PHP threads I found.

Important links:

• adldap.sourceforge.net/
• php.net/manual/en/function.ldap-start-tls.php

As part of the TeamViewer package, we have a logon account which lists our “partner connections”, i.e. a list of our clients computers, aliasing their respective “partner ID’s”. The partner ID is a “permanent” ID number which is assigned to your computer by TeamViewer’s servers, (which I believe it is only permanent in the sense it creates a registry entry to remember your ID number). This allows us to connect to the same machine over and over again without messing about trying to find out the client’s IP address and getting their username and password to otherwise connect via Remote Desktop or something similar.

In addition to being able to service individual clients, we have been able to roll out the TeamViewer app via group policy to entire workgroups. It also enables us to have “one click” access to our client’s servers via the TeamViewer host application.

This is where the fun starts. We had an interesting call this morning from a client who had advised that their iPhone was no longer syncing with their Exchange server. I connected up to their server, and low and behold, the Default Website had been stopped. I thought this was a bit odd, but have seen similar cases recently as a result of Windows Updates.

Upon closer inspection, this was a little more sinister. Trying to start the service resulted in IIS telling me to find something better to do. I ran a “quick” `netstat -a -b`, which overwhelmed the command line buffer… Changing this to something more suitable, I noticed something, peculiar…

TCP    server:http             server.domain.local:0      LISTENING       12464

[TeamViewer.exe]

Why was TeamViewer listening for HTTP requests??? How could we stop it, without stopping TeamViewer?

It turns out this was a problem for more then just a few people, but I gave up searching Google and looked instead in the Windows Registry.

I ended up making the following change, killing the TeamViewer host, and starting it again:

HKEY_LOCAL_MACHINE\Software\TeamViewer\Version4\ListenHTTP = 0

This seemed to fix everything, and I was able to start up IIS again. Hooray. Crisis averted