If you’re a busy person like me, then there’s a good chance you read the title of this article and thought to yourself, “Why does this guy want to waste my time? Everyone knows the benefit of SSO: The users no longer need to remember passwords. Case closed!” Although that is one very good reason to use SSO, there are several other, less obvious reasons to implement an SSO strategy for your IBM i environment that I have discovered in my time working on the platform.
The first benefit is that regulatory compliance becomes much easier. Many regulatory bodies require governed companies to demonstrate adherence to specific password requirements. Depending on the size of the environment, this can become a cumbersome task when repeated over and over again. Reducing the number of places you need to show compliance eases the pain greatly. If you use *NONE for your user’s passwords in combination with an SSO implementation, you can put the burden of proving compliance on your Active Directory environment, which is required anyway.
The use of *NONE for passwords similarly means that when you need to remove access for a user, disabling the Active Directory account immediately removes the ability to sign in to the IBM i system.
And while we’re on the topic of using *NONE for your passwords, I should also add that using this configuration prevents users from accessing methods of system entry that could subvert operating system level security, such as FTP (unless of course you have SSO for that service enabled).
Another thing that becomes much less frustrating when using SSO is the use of mapped drives. Anyone who has administered an environment where the users have mapped drives understands the misery of dealing with the countless tickets from users who have locked themselves out of their mapped drives. Rectifying these situations usually involves resetting the user’s IBM i NetServer account (a separate authorization on the IBM i server) and possibly even deleting and recreating their mapped drive entirely. With SSO, on the other hand, this issue is a moot point, and even the process of mapping the drive becomes much easier since there’s no need to connect using different credentials.
Obviously, as I stated at the beginning of this post, all of the previously mentioned benefits are in addition to users never needing to remember a password for IBM i again and freeing up time for IT support staff. But there are a few caveats to consider before SSO set up on IBM i. For one, because IBM i has an object-oriented security architecture, you will still need a local account on the server for each user on each partition. However, this is transparent to the user. Second, the Enterprise Identity Mapping database will need to be maintained — although additions and deletions for users can be automated, and the added overhead pales in comparison to the time saved on password reset administration.
Whatever you choose to do, it is important to have a clear understanding of all the potential benefits and pitfalls before implementing anything. I hope I’ve given you some reasons to entertain using SSO for IBM i authentication that may not have been readily apparent.
Posted on behalf of Dana Boehler and previously shared on the Rocket Blog.