Pat Patterson, from Sun Microsystems, has released a quick proof of concept of an OpenSSO authentication plugin for MediaWiki. This could be a really useful plugin for any organization that has decided to go the Web SSO route. If you aren’t familiar with OpenSSO, and you maintain a number of applications with some form of cookie trusted mess, or multiple logins, I highly recommend checking it out.

I was actually planning on writing this extension, and haven’t had time to get to it. I’ve asked Pat if I can test, clean up, and maintain his extension in Wikimedia’s SVN.

Share:

Recently, I deployed OpenSSO as a web single sign on service for a number of web servers, one of which was running MediaWiki. I haven’t yet written a SAML2 plugin for MediaWiki, so I am running an OpenSSO web agent for Apache, with the LDAP plugin doing auto-authentication.

After deploying the web agent, MediaWiki started parsing things incorrectly. Wiki-syntax like:

== Test ==
== Test2 ==
=== Test 3 ===

Was being corrupted, and turning into something like:

Share:

In part 1 of this series, I discussed basic password authentication for Active Directory (AD). In this article I will discuss enabling group restrictions and synchronization, and retrieving preferences for AD. I’ll first discuss group restrictions, then synchronization, then retrieving preferences.

Group restrictions and synchronization will require you to somewhat understand the LDAP structure that your AD environment is built upon. Don’t worry, this isn’t as scary as it sounds, and I’ll explain how to find all of the information you’ll require.

Share:

If, like me, you have had issues with replication in Sun Directory Server, maybe this post will help.

The dsadm list-certs -C command will show you what CA certificates you are trusting, but it won’t show you how it is trusting a certificate. If you are getting an error like “Bind failed with response: Failed to bind to remote (900).”, and you know SSL should be working properly, you probably want to check to see exactly how your CA certificates are being trusted.

To do this, use the certutil command:

Share:

For some corporate wikis, it is beneficial to allow anonymous edits; however, anonymous edits in MediaWiki track IP addresses, and in most corporate environments, it is simple to identify a user simply by knowing what IP address they came from. Also, most corporate environments are opposed to allowing non-authenticated write-access to any resource (for good reason).

So, if you wanted to have a wiki, like a wiki for polls, that needed some form of anonymity for users to trust using it, using the LDAP Authentication extension in a clever way can allow you to do this.

Share:

In part 1 of this series, I discussed basic password authentication for Active Directory (AD). In this article, I will discuss basic password authentication for LDAP domains with the posix schema.

For basic password authentication against an LDAP domain with the posix schema, you need to configure three or four things:

1. Domain name
2. Server names
3. How to bind to the LDAP servers
4. The proxy user used to find your user accounts (optional depending on your environment)

Prerequisites

Please see and complete the “Create a local sysop”, and “Enabling the plugin” sections of part 1 before proceeding.

Share:

Configuring the LDAP Authentication plugin for MediaWiki can be a daunting task. In this series of posts, I’ll go over the basics of configuring the plugin for common environments. In a later series of posts, I’ll go into each environment in detail.

Part 1 will discuss basic password authentication for Active Directory (AD). Part 2 will discuss basic password authentication for LDAP domains with the posix schema. Part 3 will discuss enabling group restrictions and synchronization, and retrieving preferences for AD. Part 4 will discuss group restrictions and synchronization, and retrieving preferences for LDAP domains with the posix schema.

Share:

In part 1 I discussed how to configure NSS and OpenSSL. In part 2, I discussed how to configure pam_pkcs11 and how to test a smartcard against the NSS database we set up. In this part, I’ll discuss how to add pam_krb5 into the mix to automatically get a Kerberos ticket from an Active Directory domain using PKINIT.

Notice that this post will discuss a package that is yet to be officially released by Red Hat. Whenever this is officially released, it may have different configuration options, or different functionality. I’ll update this post at that time.

Share:

In part 1 I discussed how to configure NSS and OpenSSL. In this part, I’ll discuss how to configure pam_pkcs11 and how to test a smartcard against the NSS database we set up.

What does pam_pkcs11 do for me?

The pam_pkcs11 module will do a couple things for us:

1. Allow/Require smartcard login
2. Map an attribute from the card to a login name

For a basic configuration, we’ll have to edit three files; /etc/pam_pkcs11/pam_pkcs11.conf, /etc/pam_pkcs11/cn_map, and /etc/pam.d/system-auth.

Configuring pam_pkcs11 and testing smart card access

Edit /etc/pam_pkcs11/pam_pkcs11.conf; this file is kind of long, so I’ll just touch on specific configuration lines, and only the basic configuration lines needed to get the authentication working.

Share:

Starting with Red Hat Enterprise Linux version 5 (RHEL 5), Red Hat added native support for PKI with pam_pkcs11, NSS, ccid, coolkey, and pcsc-lite. RHEL 5 also added rudimentary support for PKINIT in their Kerberos client, mostly based upon the CITI and Heimdal implementation (in pkinit-nss). Coming in a future update to RHEL 5 (maybe 5.3 or 5.4) you can expect better PKINIT support, with more MIT based PKINIT support.

This series of articles will cover how to configure a RHEL 5 system to allow users to log in with a smartcard, while also getting a Kerberos ticket from an Active Directory domain.

Share: