I launched a new intranet application today. Nothing fancy, just a simple app to address a real need in my organization. Initial feedback has been very positive. Feels good to ship!
To force IE to edge mode (even on intranet sites, where IE would otherwise use compatibility mode), the server needs to send X-UA-Compatible as an HTTP header. Using a meta element in the document head doesn’t work reliably.
I found the answer buried in this Stack Overflow thread.
In my case, I was working on a WordPress theme, so I added
at the top of header.php.
UPDATE 3/13/2014: I have now verified the IIS method linked above.
When I wrote about my experience setting up AD Single Sign-On for Linux, I said the next step was to extend the transparent SSO experience into WordPress. The biggest reason for that—I thought—was so that the WordPress server could then impersonate the logged-in user to pull resources from our SharePoint server (using SharePoint Web Services) and include them on WP pages. Basically a WordPress front-end with SharePoint doing some Digital Asset Management duties on the back-end.
The epiphany I just had is that it wouldn’t be WordPress connecting to SharePoint, it would be PHP, which already knows who the user is, thanks to the Kerberos authentication I already have set up. I don’t need to tackle the WordPress part before I can build the SharePoint part.
Transparent SSO to WordPress is a benefit mainly for content creators, editors, and admins—those are a small percentage of my total user base, and managing their accounts is relatively easy.
I mentioned a while ago that I have a Linux web server set up with Kerberos SSO in our AD domain. Setting it up was a lot more tedious than it seems like it should have been. I found bits and pieces of useful information here and there, and some step-by-step guides to help with specific sub-tasks, but I couldn’t find a good, intranet-specific guide to help me understand the big picture—what pieces I needed (and didn’t need) and how they fit together. So here’s part 1 of my attempt to rectify that situation (part 2 will be the WordPress integration—I’m still working on that part).
Continue reading “Active Directory Single Sign-On for Linux Intranet Servers”
I’ve started a project to move the front-end of our intranet from SharePoint to WordPress (SP is just too icky to do any serious front-end work with). The plan is for WordPress to become the front-end and CMS for news-type content, keep SharePoint for file library and calendar-type stuff (at least for now), and use the SP web services to integrate the SP content into WP. All of the various authentications involved must be transparent to the end-user.
Goal #1 was to get all the Kerberos stuff worked out so that Apache would transparently authenticate users against Active Directory (assuming they’re logged into a Windows client machine with their domain account—a reasonable assumption for an intranet, although a good experience logging on from an iPad or other non-domain client is also disirable). It took a bit of trial-and-error, but I got it working! WooHoo!!!
Goal #2 will be to fire up WordPress and get it to recognize that Apache already knows who the user is, create a new WordPress account if it doesn’t already exist, and log the user into WordPress.
This should be fun…