Allowing User Profiles Without Passwords to Sign On
April 26, 2006 Hey, Joe
|
In your article about Setting Up User Profiles Without Passwords, you said that when you set up a user profile to have a password of *NONE, this configuration ” . . . essentially disables a user from performing any type of interactive work on the system.” In my shop, we have implemented Network Authentication Service (NAS), along with Enterprise Identity Mapping (EIM) and a Kerberos server, to create a true Single Sign-On environment. My profile has a password of *NONE and the Kerberos-NAS-EIM configuration handles the authentication to the AS400. I log into a 5250 session multiple times a day and perform interactive work all day long. Typically, this just means that my user profile only needs to authenticate to the Windows Active Directory Domain in order to access i5 services. –Mike While I’ve covered Single Sign-On (SSO) and its relationship to users without passwords in earlier columns (see the Related Stories section below), I neglected to mention SSO in the story about no-password users, and several readers have emailed to remind me about it during the last few weeks. This week, I would like to set the record straight. This omission was an oversight on my part, since I was touting the use of password-free users for securing group profiles and running batch jobs, but the fact remains that users without passwords can use SSO to start an interactive 5250 session without signing on. This does not mean that there isn’t security for these users. The security is there when you implement SSO; it’s just implemented in a different way. There are several procedures and requirements that prevent password-free users from having a free ride for unlimited 5250 sessions or to automatically use ODBC to upgrade i5/OS data inside a Windows program. Here’s how it works and why you may want to consider it for your shop. SSO is a technique where i5, or iSeries servers are configured as part of a Windows domain, the same as any other Windows file, print, or application server. Once users sign in to the domain at large, they are eligible to access i5/OS applications and data without entering another password for i5/OS access, the same way they are eligible to access Windows file shares, print servers, and applications on other Windows domain servers without entering a password. When an SSO user requests access to an i5-related application program, the request is reviewed and authorized by a Kerberos server; when that user is authenticated, the program and the i5/OS partition allow him to access data without having to sign-on. SSO is available for users running i5/OS V5R2 and above. But SSO access does not automatically happen, as it requires two separate configurations to allow users to access the system password-free. First, an i5/OS administrator must add any new SSO users to an Enterprise Identity Mapping table that tells the Kerberos and Network Authentication servers which i5/OS user profiles Windows users should be mapped to when they are automatically signed on to the system. So, just like fans trying to go backstage at a concert, no one gets a free shot at i5/OS applications and data without being on the list. The second configuration occurs on the individual user’s Windows desktop, which must be configured correctly to allow them to take advantage of SSO access. iSeries Navigator and some other Windows-to-i5 applications must be set up to request Kerberos authentication when the user wants to use that application. So there’s a desktop component that must also be set up correctly to allow no-password users to start a 5250 session or to run Windows applications that access i5 and iSeries data. Between these two configurations, Windows domain security sets the stage for enabling system access through an i5/OS user profile that is automatically mapped to the user’s Windows ID. Once configured, SSO access happens seamlessly beneath the covers, and the user will seldom have to think about signing on again. The only knock some administrators have against SSO is that they feel uncomfortable knowing that any user who happens to stumble across an unlocked Windows desktop can automatically start a 5250 session, an ODBC or JDBC session, or another i5-related application without signing on. They may feel that SSO presents a potential security violation, especially when their shop has already taken precautions to automatically disconnect or end inactive jobs in order to prevent unauthorized users from accessing the system. If Windows desktop security is an issue in your shop and you want to implement SSO, it might be prudent to require all machines to include a password-protected screen saver that automatically activates when the user’s keyboard has not been touched for a short amount of time, say five to ten minutes. That way, you can limit the amount of time a Windows desktop (and its SSO-enabled i5 applications) will remain open when a user steps away from her desktop. Regardless of this potential problem, SSO is a solid i5/OS feature that I recommend most shops consider implementing, as long as they thoroughly understand the configuration and any possible security issues. RELATED STORIES
Getting Ready for Single Sign-On Configuring i5/OS and a Windows Network Server for SSO Configuring an i5/OS-based EIM Table for Single Sign-On Configuring Windows Desktops to Use SSO |
