As part of a project to standardise our network I’ve needed to change our authentication source from Novells eDirectory to Microsofts Active Directory and along with this change, standardise our user naming scheme. There are a number of challenges in doing this, but due to the flexibility that seems to be inherent in most LDAP based authentication implementations, I was able to make that change without staff being any the wiser.

So I have a couple of challenges

• Usernames in AD are different to the M3 usernames in MNS150
• Deadline to remove eDirectory
• Limited hours of work – I work part time at IFL, and tend to be booked pretty solidly with other customers.

With a relatively compressed timeline we go with my favourite methodology, multiple minimal changes for minimal disruption.

The usernames in AD are different to the M3 usernames in MNS150. To reduce impact and due to some other more visible changes for staff, I don’t want to have to rebuild the security in M3 as part of this technical change – I want them to authenticate with their old usernames until I have capacity to deal with anything that might get missed from a security or output perspective within M3.

As I mentioned in my opening paragraph, most LDAP authentication implementations I’ve come across are pretty flexible – you can usually define the LDAP attribute that will be used to define the ‘username’ – often you can also check multiple fields, so for our reverse proxy I used to check the CN and Mail attributes for the ‘username’.
The LDAPSession Provider is no exception, we have the User ID Attribute field which defines which LDAP Attribute we will look for

And as you can see I’ve nominated the comment LDAP attribute, typically you would use the sAMAccountName in an AD environment.

Against the AD user, I just populate the comment field with the MNS150 name as below

For some users, the sAMAccountName will be the same as the comment, for others they will be different until I embark upon cleaning up the MNS150 users – but at that point I can do it on a user by user basis over however long I choose.

Note: that while this works for a traditional M3 software stack, I haven’t investigated the impact of peripheral products like DAF, and Mingle – so though I would expect to be able to do something similar with those products, it may not work.

My plan becomes

1. Populate the Comment attribute for all M3 users in AD with their MNS150 username
2. Point the authentication at AD rather than eDir
   For staff whose MNS150 records don’t match their AD username
   1. Set up a new user in MNS150 matching their AD username
   2. Set up their M3 rights for the new MNS150 username
   3. Set up their outputs
   4. Quietly ask them to log in with the same username they log in to their computers
3. Once all staff have transitioned, change the LDAPSession Provider to point back to SAMAccountName, and clear the comment field from each user

From an IFL perspective, this meant the cutover happened one evening and people logged in the following morning without knowing anything had happened. It also meant that I could easily swap between the two authentication sources with a couple of changes to settings on the LDAP Session Provider – rollback becomes an easy 5 minute job.

When I embark on step 3, I will be able to change an individual users ‘Comment’ attribute to be the same as their AD Username and ask them to use that to log in to M3 going forward.