How to Achieve Single Sign On (SSO) in a Day

Hi everyone. I'm pretty excited to tell you about something that's near and dear to my heart. No, not heavy expense cutting, single sign on, but before we get into some of those details, I need to set the stage.

Does this sound familiar to you?

Management is scrutinizing budgets and cutting costs and departments across the entire enterprise. There's few or no conferences, or outside classes to learn about or learn how to use the latest technologies. We're living in the do more with less era. There are higher expectations for productivity and usually with fewer people to share the load. Anyone who can make life easier for the masses and saves the organization time and money is going to be a hero. And that's what we're here for today. We're going to show you how you can be an IT hero. We're going to show you how to impress management, how to bring a smile to the faces of a thinly-stretched staff, how to save time and money across the organization, and we're going to show you how you can eliminate passwords by implementing single sign on.

So how does SSO reduce costs? How much time and money does it cost to manage passwords? And the answer, the short answer to that is, it's a lot more than you think. You can use a simple formula for getting an idea of how much your company spends on just password changes.

The formula includes the number of employees, the time required for the average employee, to change all of their passwords, and this number typically, once you start thinking about it and actually tracking it for yourself, is typically a lot longer than you think it is, if you're like most companies and have three or four passwords or more that you need to change over a certain number of times over the year, every 90 days or four times a year seems to be about the norm. Some organizations are changing passwords every month, but if you take those numbers and you multiply it times the average salary in your organization, you'll get a pretty good idea of how much your company spends on just changing passwords in a year.

So, taking a pretty conservative set of assumptions, if there's 3,000 employees in your company and on average, they each spend about a half hour a year and the average burden rate or salary is about $20 per hour, that’s 120K, right there. For 500 employee organization, it's about 20K a year.

But, importantly, this number doesn't include the help desk cost or admin cost of helping those employees either change their passwords, or when they try to use their password, and they can't log in.

The help desk and administrative costs are typically slightly, if not a much higher, rate depending on the organization than the average salary across the organization. Estimates have been sitting at about 40% of the calls to a help desk in the average organization are password related. So, if you can eliminate passwords, then you can eliminate a lot of the costs associated with passwords.

So how do you eliminate those costs? I'm sorry, before we jump into that, you can get a much more accurate estimate of how much your company is spending on managing passwords by taking a look at the single sign on return on investment calculator at the website shown here. It includes administrator and help desk costs, as well as the formula that I just talked about above.

You provide all of the numbers used to estimate your current password management costs. You provide the estimates of the cost to implement and manage whatever solution you're looking at using for single sign on. Then, the calculator will give you an estimate of your current cost to manage user IDs and passwords, the cost to implement a solution, and your return on investment for that solution.

I think it's a great tool, and it can be used to estimate for any organization if you want some help running it, or figuring out what estimates to use, you can give us a call or contact us, and we'll spend some time going through that with you.

So, what is SSO and how does it reduce cost?

Well, the SSO that I'm talking about is integrating Active Directory or Windows domain authentication with your IBM i and/or AIX or Linux authentication. Using this approach, you don't have to rename user IDs, even if they're different on the different systems. There's no need to change your access control schemes because you're not renaming user IDs, and it allows you to remove passwords for your non-active directory user accounts.

So, just to give you an example, if you implement single sign on, and you have two IBM i partitions in a Windows domain, you can eliminate two-thirds of the cost of managing passwords in your organization. And, probably most importantly, is you can do all of this without purchasing any additional software. You already own the technology that's necessary to make all of this happen.

So how do you enable those technologies?

Well, first of all, the process of implementing SSO, the high-level view of it, is you join a non-Windows server to the Windows domain or active directory. It's the equivalent of joining a workstation to the Windows domain, but because it's not a Windows platform, it's not done the same way.

Get an instant demo of Single Sign On >

Once you join your system to the Windows domain, it means you're using something called the Kerberos authentication protocol, and we're not going get into what that is but suffice it to say that it is nothing like the user ID password protocol that you're used to. In this protocol, your passwords never flow over the system during authentication. They’re still used, but they're used to encrypt pieces of data, and then you prove that you were able to successfully decrypt those pieces of data. It's a fairly complicated protocol, but it was designed at MIT in the early ‘80s for the distributing computing environments that we started living in in the late '80s and early ‘90s.

So, that's the first step.                                           

The second step is to configure and populate something called Enterprise Identity Mapping, and this is the piece that allows you to not have to rename user IDs and passwords.

It's basically a giant cross reference user ID, cross-reference repository, and you want to have one I'll call it a production version of this repository and then point all of your systems to that.

Finally, once you have that configured, now you can configure applications to tell them to use single sign on for authentication. Once you've done that, you can choose to remove your non-Windows passwords from your non-Windows systems.

Now, this is optional, it doesn't have to be done and you don't have to remove everyone's passwords, you can remove some of them and not others. But in order to achieve the best return on investment, we recommend that you do this.

Okay, sorry to interrupt, we have a couple of questions here.

One of them is, are you saying that I can remove the passwords from my IBM i users, and they don't have to have a password anymore on AS400 or IBM i?

That is exactly what I'm saying. Which is why this is such a potentially impactful thing to do for your organization.

So you and I both know how to do that, but that means that you would actually set the password to *NONE, right?

Right, and that's actually coming up here in some of the details, but that's absolutely right.

Okay, so one other question. The IDs are the same on Windows as IBM i, do they still have to populate and configure EIM?

The answer is yes, but there are some shortcuts that you can do to make that faster, using something called group registry definitions. You can essentially make one association per individual, and it will work across all of the systems where that idea is the same.

Thank you.

Sure, thank you.

 Alright, so that was the high-level description of how things work. Taking that down a level, how do you implement those things?

Well, the first thing is, you configure what on the IBM i is called Network Authentication Service, which is really just Kerberos. There are some licensing requirements with MIT that says you can't call your implementation of Kerberos Kerberos, but it is the protocol. On the 400 in the interfaces and stuff that you're looking for in iNav, you’ll be looking for Network Authentication Service (NAS). Much of the documentation and almost all of the time, I will use Kerberos.

So, once you configure your network authentication service on your non-Windows server, then you have to define that non-Windows server to Active Directory, and that's part of the join the domain process. And, again, I get in a little more detail in the next slide, on that.

Then you need to create an EIM repository, and you only need to create that repository on the first system you configure. The rest of the systems, you will just point those systems to that repository.

There are some things that you'll want to do for high availability (HA). How you do that and what you do is going to be dependent to a great extent on how you manage high availability in general and some of your requirements and network segmenting and that sort of thing. But in general, you’ll want to have a single production repository. And once you have a production repository created, then you just add the user ID cross reference information for a single person, a test user, which is typically yourself. So, to configure network authentication or Kerberos protocol, you can do through iNav (iNavigator) or you can also do it with ACS, Access Client Solutions, the new iNav stuff. So, you can get this done through all of the GUI interfaces that IBM supports. Again, you'll be looking for network authentication service, and you'll find that under the security tab. In ACS, they have the All Tasks button, and in order to get to the configuration wizard, you'll want to go through network authentication under the All Tasks tab.

To create and configure an EIM repository, you'll also use iNav, and that's under Enterprise Identity Mapping, which is under the network tab.

And once you have that set up, once you get it created, then you can go into domain management and under domain management, you can add and remove users or see what users are already defined and what identities are associated with them, etcetera. Once those two steps are done, those are the biggest steps, then it's a matter of changing the applications that you use on your PCs or on your workstations to tell them that they can use Kerberos authentication. Now that's going be an application specific sort of task, but for your initial test user, you would just go in and select an application, maybe 5250, that's one that we often use, and see if it works. Once you have done the initial testing with your initial user, then you'll want to enter the identity mapping info for all of the users in your environment.

And begin on whatever schedule you want, changing the applications on their workstations to use Kerberos for authentication. Then, you can start removing passwords.

Now, on the IBM i you set the password to *NONE. On Unix like systems, Linux, AIX, you can just not set the password property. Also, you often run into applications that have application-level passwords, and for those applications there will be specific ways to turn that off.

I'm guessing this is coming. One of the questions that just came in is, the process of mapping those users, or linking those users, is that a manual process or can it be automated?

Yeah, I'm going talk about that in a little bit, but I can address that now. The short answer is yes, from what IBM provides you it is a manual process, and for a large number of users that can be very tedious. And I'll talk a little bit more in just a second, about another option.

One more question because I think it kind of flows right in here, and there's been some other questions, but I'm holding them more towards the end because I think that you might answer some of them.

Okay, but the question was, can the repository, I am assuming that’s the EIM repository, be on AIX or Windows?

Yes, it can be on AIX and Windows, but it’ll be easiest to configure it on the IBM i because it's pretty much an automated process. If you're going to use it on Windows or on AIX, or have the repository hosted on Windows or AIX, you'll get into having to install and configure OpenLDAP, and there are some tools that will help you configure OpenLDAP for EIM, but it's up to you to get that installed.

Okay, thank you.

Okay, great questions. So, to configure an application to use Kerberos, you just have to figure out depending on your application, where the option is that you set for PC 5250. If you go into the property section at the top, you'll see user ID sign on information, and if you scroll to the bottom, you'll see, “Use Kerberos principle name, no prompting”. And that's what you want to use and select that and select Okay and connect. For iNav, if you go into the connection properties again at the top of the screen, you'll see a radio button and that's what you'd select.

There are other emulators, non-IBM emulators, that support, single sign on with Kerberos, and so do all the major web browsers etcetera. So, it turns out there's a large number of non-IBM applications that are able to participate in this single sign on.

So, since you're talking about applications, we've gotten a couple of questions about mapping drives to the IFS or using file shares. So, is this going to cause any problem with that, or can that be enabled, as well?

No, mapping drives is something that can be enabled easily as part of this configuration. It turns out, if I go back to wherever I said for a single test user, then after you get it configured, when you add identity mapping info for all users, you'll want to only add the net server services to active directory, after you get all the identity mapping info for end users that map drives into EIM. That's the only caveat in this whole thing.

So, as part of your configuration when you join a system to the domain, you are actually telling the domain about the various services, one of the services is net server, and you only want to define that service to the domain once you have all your information for people in EIM. And that's due to actually what I think is a bug in the mapped drive process from Microsoft, where instead of following the standard Kerberos behavior, what it does is it says if there's a Kerberos service available for a mapped drive, use that. Don't ask to use it just use it, and also if that doesn't work, don't fall back to a user ID and password prompt. So, the order in which you configure net server is important, but if you follow the order I just said you'll be fine.

So, how hard is it?

Well, there are complexities with SSO, and it primarily has to do with it's new to you. So, it’s more to learn. The Kerberos authentication protocol is pretty complex, and by definition it's a cross-platform sort of solution. So not only do you have to understand how the protocol works on the IBM i and on Windows, you have to understand how it works across all the platforms you're going to support. And that takes some level of what I call cross-platform skills, just knowing how the protocol works in general, isn't enough. You have to know some details about how it's implemented on all the platforms you’re going to support.

And on top of that, there are environmental complexities and with cross-platform comes bureaucracy because typically you have different groups of people supporting IBM i, different groups of people supporting Windows and having somebody on an IBM i or AIX telling the Windows guys that “Well, we're going to add some entries to Active Directory, and it's not going to hurt anything, don't worry about it,” can cause issues.

You also have a number of applications that may run on each of those platforms, and you've got web applications, webserver applications, mobile applications, and typically there is not just one person in the organization that understands each of those. It tends to require skills from a lot of people. You also need to understand high availability to some extent, and then on top of all of that all of these things tend to change at varying times, so you need to be able to understand how all this stuff works across all of these things in order to make sure that that nothing breaks, etcetera.

So, some shops can and actually do implement SSO technologies themselves, but these technologies are complicated to understand, implement, and most importantly, I think, is support.

You don't typically have very many issues with this over time, but at some point, something changes, and if you don't understand how it all works, it can be kind of scary to try and figure out, “Okay, which of all these moving parts changed and how do I fix it?”

So, if you don't have good experience in all of these technologies and across all of your platforms, than the cost to implement and support can rise dramatically.

And again, the big problem is, if something stops working, why did it stop working? You might want to consider getting some sort of outside help with the skills and expertise to implement and to provide that access to ongoing support.

So that brings me to my next item, and that is HelpSystems is providing a new Managed Single Sign On Service. The sign on services is similar to the Managed Security Services, which you may already be aware of, but it's a subscription service, and we will implement Kerberos and EIM in your organization, and we can typically do that in less than a day.

We can train your in-house administrators, and we provide additional hours that you can use for support, not only for single sign on, but for any authentication related questions or issues, and actually any security-related questions.

So, our Managed Single Sign On Service is a subscription service, as I said, and there are no software licenses, there's no maintenance fees, and most importantly, there's no fear. It includes those extra consulting hours, and as part of that we actually will help you do a bulk load of all of the identity mapping information for all of your users.

We provide you a little tool, and we to help you use a CSV file that's just created, usually people create it as a dump from the Active Directory accounts, and then using this tool we can very quickly load all of your information into EIM. One time, this is a while back, but I think it was about 8,000 customers that we did, and that took about 10 minutes, 15 minutes. So, that gives you an idea of how quickly we can help you with that and compare that with trying to add through clicks and typing the information for all 8,000 of those users.

One question that's just come on about the support. We don't need to come on site to do this, do we? Or, do we do this remotely?

No, we can do all of this remotely. And in some ways, I think that's better. Not only because there's no travel cost, but when we work with you over a WebEx or GoToMeeting, we actually are telling you what to click and what to do, but you're doing the work, and I think that helps with the knowledge transfer greatly.

I agree, I think whenever somebody is actually doing the driving themselves, I think it sticks a little bit more. So, another question is that for this managed service, it's not a perpetual connection or anything like that, it's help with set up and then follow on as needed, correct?

Oh, absolutely, yes. It's just the WebEx or GoToMeeting for however long it takes us to get set up and sometimes, we'll do an hour and then continue a couple of days later with another hour in. Those are all just separate connections.

So, SSO is actually a viable option for all shops! Your ability to take advantage of that has been around for a long time, but the complexities, the fear of the unknown, and a number of other things along those lines have mitigated against a lot of shops attempting to do it. But, there have been a lot of shops that have attempted it and have been using it for years. So, you can do it yourself, or you can get expert help, but either way, if you do, your users will feel like this, your management will be like this, and you will be an IT hero.

So, in summary, single sign on can actually significantly reduce the cost of managing passwords, while at the same time making your users really happy. That's an important point. While delighting your users is important from a business point of view, if it costs you a ton of money, additional money, to delight your users, you're probably going do without that.

So the real reason for using single sign on is because it can be used to help you significantly reduce the cost of managing passwords for your end users and to provide your help desk folks with much more time to work on much more important problems. Again, you can do it yourself, or you can use the managed services from HelpSystems, and I encourage you to take a look at the SSO ROI calculator. Most people who go through that are very surprised when they fill in their assumptions at how much time and money they're actually spending on managing passwords.

So, with that, I think I'm done. I think you have more questions for me.

Yes, there's definitely some more questions that have come in.

One of them, do you need iNavigator to create EIM or can it be done with green screen?

So, the short answer is yes, you need, iNav. The long answer is you could do it through green screen, but there's so much you'd have to know and understand that it really isn't feasible.

Okay, and one question is, is this really a secure implementation?

Yes, that comes up a lot, and it's a great question. The answer is absolutely, and if you ask any security expert, the Kerberos authentication protocol is much stronger than the standard user ID password protocol. There's just no getting around it and just one of those reasons is because passwords never actually flow across the system during the authentication. So, there's another aspect to this too and that is its security is a function of risk, and cost. Even if the Kerberos protocol were only as secure as a user ID password protocol, it wouldn't matter because in the end it's much cheaper to manage Kerberos than it is to manage all those multiple passwords.

Okay, one question is, "will it work with IBM i Client Access Solutions?”

And I'm going answer that. Those were the screenshots that were shown, as to you're enabling Kerberos authentication, and that's part of the configuration for either client access and, of course, we're all moving to Access Client Solutions. So yes, answer is unequivocally, yes.

Another question is, what password level system value needs to be set to use this?

It doesn't matter. It doesn't matter because you’re no longer using the passwords on the IBM i for those users that are configured to use Kerberos. So, it doesn't matter.

 Then, does the EIM server run on IBM i?

Yes, it does. The EIM server is really just the LDAP server. The LDAP server is used as a repository to hold the identity mapping information.

There were a couple of questions about HA. Somebody is using Power HA and another person is obviously using some sort of replication software, so they're wondering how EIM works in the disaster recovery mode?

It works really well. You just have to ensure that you're replicating the appropriate libraries and IFS directories, otherwise it works fine. For some of the replication software products, once you add the new libraries to be replicated, you may have to end and restart replication in order for it to take effect, or end and restart the LDAP server, in order for it to take effect.

Okay, then can this be used for ODBC?

Yes, it is ODBC, and it certainly can be used with the IBM ODBC client. There are other clients, some of which do support it, some of which don't.

Okay, what about FTP?

FTP can be configured to use Kerberos, the FTP server. Then you need an FTP client that knows that it can use Kerberos that you can tell it to use Kerberos.

So, then there's been a couple of questions about how difficult is the integration into Windows Active Directory, is it extensive, is it one user? What do you all have to do in Windows AD?

When you run the Network Authentication Service Configuration Wizard, part of what that does in addition to configuring the IBM i, is it creates a Windows batch file. That batch file is run by an active directory administrator on a Windows domain controller, and that defines user accounts for each of the services. Depending on how many services as you define, there will be a different user account for each service.

That's the default way IBM does things. It turns out that you can actually use a computer account for all of those services and if you do it that way, then you end up with a single computer account, which is in my opinion, much tidier, it makes the IBM i look much more like just another participating system in the domain, but you have to really reswizzle that batch file.

I actually have some Qshell script files that can read in the default IBM i batch file and create the necessary commands for using a computer account instead. Now, one reason not to do that is because if you ever end up calling IBM i support and you don't have those user accounts created, their eyes will roll back in their head, and they'll be sure that that’s why whatever you're calling about is not working. So, that would be a reason not to do that. Other than that, it seems to me that the computer accounts actually are a tidier way to do that configuration.

Alright, so one of the questions we've gotten is that I'm not an AD Windows literate person, will my AD admin object to what you're suggesting? And I think, this is one of the things that you were talking about, when you're talking about those environmental concerns. When you have an IBM i guy espousing to your windows guy, or gal, that they should make some changes. So, that's one of those things that we can come along beside and help facilitate that change, correct?

Absolutely. In fact, when I talk to customers about helping them implement SSO, I always tell them that it's very important that you get your active directory administrator on the phone call because once they understand what you're doing and why you're doing it, and that you're not really changing the behavior of the Windows environment, you're just changing the behavior of another server to participate in that environment. They typically are all on board.

Yeah, that I think is the most important thing there. So, glad that somebody asked that question.

And if people don't understand our speaker's background with EIM and the whole SSO, I don't personally think that he has ever gotten the recognition that he deserves. He is the father of the EIM and the SSO implementation on IBM i. Back when I was still at IBM, and before he took over as IBM i security architect, we used to walk the halls of IBM for exercise, and he would be yammering at me for lack of a better action there about, “If we could only have a way to be able to map users that have different names and participate in this active directory domain, it would be so much easier, we could eliminate passwords.” So, this is his brainchild. So, if we've got the expert on board now for the SSO technology, so in case you couldn't tell that by all the things that he's been answering and the way that he's been answering, that is his background. So, we've got the best in the business right here.

We've gotten a few questions about cost, and I am going to refer those to a salesperson, so that they can get back to with the exact cost. We're both techies, and we don't get into that, so we'll make sure to get those answers to you from a sales rep.

I guess I'll give just a little bit of a commercial here for our services. Our speaker has joined the professional security services team, and we do a variety of services. We often start out with a risk assessment that is a very thorough assessment of your environment to come up with a prioritized list of actions that you can take against vulnerabilities that have been derived from security best practices. Our team will often do penetration testing, so this is not at the network level, so we're not coming in and finding out the services that are still active, we actually take results and attempt to get onto your system and attempt to see what we can do from an access perspective to your IBM i system.

We also do things like architecture week. You may have vulnerabilities that you wish to close, and you need to know how to get from here to there.

And we do those services. That's in architecture week. We actually come along beside you if you'd like us to and help you make those changes. And then we have managed security services and now our managed security SSO services, as well, that we do on a monthly basis.

So, with that, we can see if there's any more questions, but why don't you go to the next slide? And put up the contact information if you want to get more information about Single Sign On.

Let's see if there's anything else that we should answer. Some of the questions that have come in are very specific, and so we'll get back to you with those questions. If we didn't get them answered.

Here's a good one, though.

Can this version of SSO with EIM on IBM i be implemented if you're using Azure Cloud Active Directory? And I'm guessing that he has put himself on mute.

Sorry, yes I had.

The short answer is yes. It does work with Azure and depending on your environment and what else you have going on in that environment there are different ways to make it work.

Cool, so then one last question is that somebody has a web app that has been implemented with the CDI programs. Is that something that can be integrated?

Absolutely.

Well, I think, again some of the questions that have come in have been very specific and we'll get back to you with those and we'll also get back to with those questions about pricing. So, with that, I think we'll call it a day. Thank you so much, and again, welcome to the team.

Thank you and thank you everyone.

Alright, have a great day everybody.