First off, let me say that while I know my way around PHP pretty well I haven't dealt with any of the following yet, so I'll probably say some dumb stuff...

I'm adapting a PHP CMS I've developed to deploy on a client's intranet. It will be running on an Apache server they configure for this project. They requested being able to use Active Directory and/or Samba and/or LDAP to allow users to be identified by this CMS using their already-logged-in Active Directory identity, and not have to authenticate again in the CMS.

In other words (as I am beginning to grasp it) they're already logged in to the intranet, and when they go to my CMS, it recognizes that logged-in status and says "ok, you're Bruce, you get to see this particular content".

As I've started to explore this, I find solutions that require a second login, but do query the Active Directory database rather than a second db of user credentials. What I'd like is a solution that just "knows" the person is logged in, what their clearance level is, and doesn't force them to log in again. I believe this is called "SSO".

Of course I'd love to find a canned solution to this that's implementable by someone without a lot of networking smarts (I DO know PHP and SQL, and have done a little CURL, but I know there's a lot more in the networking world).

Or, just some good resources to educate myself about how this would actually work.

Anyone have experience with this sort of thing?

Thanks 🙂

  • Bob

    We had specified a Linux box but I'm sure they could run it on Windows if we ask. I just know a tiny bit about Linux so that's my own preference.

    There doesn't seem to be any info about this mod_auth_sspi, at least not where you directed me. I'm hesitant to hang this project on something without a fairly robust support network.

      The other option would be to go with a complete Microsoft solution; since you're integrating with a Microsoft server product (Active Directory), you might look into using a Microsoft web server, namely IIS.

      With IIS, you simply tick a box that says "Integrated Windows Authentication" and uncheck "Allow Anonymous access." That would cause all requests hitting that page to authenticate via NTLM; for intranet users (if the domain is trusted by the client's browser; I've had to do a config tweak on Firefox and IE in the past) this results in a seamless login using the domain credentials they authenticated with to log onto the Windows computer.

      Note that depending upon how you're setting up access to this web server internally, that configuration tweak I mentioned is probably still applicable even if you went with the Apache route.

      In a nutshell, I used the external DNS name (e.g. http://mycompany.com) to log intranet users onto intranet applications, rather than using the internal DNS name (e.g. [url]http://server_name[/url], letting server_name get translated into server_name.our_AD_domain.net transparently by our internal DNS servers). The latter of the two should be recognized by both browsers (can't speak for Firefox without doing some testing) as an internal (and thus trusted) domain. The former, however, was treated as an "Internet" zone website; I had to apply a GPO (and deploy a simple .js script for Firefox) rule on all domain computers to move the external DNS name of our website into the Intranet zone (or as a "trusted" site when doing NTLM authentication in Firefox).

      Heh.. I said "in a nutshell," thinking I could briefly describe what I've done in the past, but I guess it turned out to be a little lengthy. Sorry! :o

        I'm assuming you're still thinking we can go with PHP/MySQL. In the past I've done a PHP/MySQL site on IIS without any real issues, so I imagine it's relatively straightforward.

        So is this something we set on the files on the IIS server - like setting permissions on Apache files? Select the file, say "accessible to Group 'alpha' only". Or something we include in code in the PHP files that's parsed by the server and then displayed or denied?

        What I'm hoping to do is include certain nav items if the person is authorized, otherwise not. So I'm hoping there is some way to access the user's info (group membership or whatever) from within PHP - rather than simply allowing or denying certain pages based on membership.

        Also we're going to be using an implementation of phpBB (or similar). Dream #2 is that the user will automatically be identified by phpBB and not have to log in independently. So being able to access the user's actual identity - or internal username in AD - would be necessary I think.

        Sorry, I realize I'm being kinda slow - this is all new territory for me 🙂

        • Bob

          Ah, now that you've explained it all I'm starting to understand what you plan to implement.

          To answer your question, yes, it's possible to use PHP to pull group membership information from AD using a SSO approach (e.g. no login is necessary - just the logon to the Windows desktop itself). Once you get the group name into PHP, obviously, the ball's in your court whether you plan on storing group names + access control information in a SQL DB or hardcoded into your PHP scripts.

          Getting the group info, however, is probably going to be the tricky part. Right now, I use this SSO-type approach to get the username to my PHP script (e.g. "MYDOMAIN\brad"); I can then use this username (just "brad", also called the sAMAccountName property in Active Directory IIRC) to connect to a domain controller via PHP's [man]ldap[/man] functionality, bind to that server (using hardcoded domain credentials - I didn't want to open up anonymous permissions and instead chose to store domain credentials in a config file guarded by a very restrictive ACL), query the domain based on the sAMAccountName I got above to select the user object I'm after, and then retrieve certain details from AD that I need (e.g. e-mail address and display name - though you could also probably pull group membership information, I just haven't researched how to do so).

          Can it be done? Yes - I've done most of it personally, sans looking up group membership information. Did it take an hour or so of tinkering with the script, permissions, LDAP syntax (mine was rusty, dunno bout you :p), and an undying thirst (trust me, I tried! 🙂) for Mountain Dew? Definitely.

            Write a Reply...