Transcript
the rise of single sign-on, why IBM shops are scrapping passwords. I'll be your host today. My name is Steve Sisk, Principal Security Services Consultant here at FORTRA, primarily specializing in the IBM iPlatform. Today, we're going to be sharing some information with you on IBM iSingleSignOn and hopefully it will answer many questions you might have. If not, we can certainly follow it with you and answer those questions in a future date. The initial question may be, why single sign-on? Well, if you're like me, I have probably 50 or more accounts and passwords that I have to manage just in my work here at FORTRA. That can be quite taxing, especially when it comes to managing the passwords for them, resetting them all the time if I forget one, which I do from time to time, and also just having to change them periodically and come up with new passwords that are strong. But yet somehow easy to remember. That can be a hard thing to achieve is complex passwords that have good security qualities, but at the same time making them so they're not easily forgotten. That's just one of the many things that single sign-on can provide to the users of your IBM iSystems. The ability to reduce the number of passwords that a user has to remember is a win-win both for the user as well as for the help desk personnel or administrators that have to manage those passwords for those users. The simple objectives for single sign-on is to streamline and simplify the authentication process. We all realize that having to enter credentials every time you access a system can be a time impact. Depending on the number of times you access the system, but I know in my own case, I have had to enter a user and a password several times over and over again, or in a critical juncture in a process, and having to enter credentials to access a particular system, once again, can cause breaks in concentration and all sorts of things that can impact our ability to get our work done. Of course, the overarching objective is to reduce the operating costs of passwords and user accounts in the environment. Because any amount of costs that's expended on managing passwords could be reallocated to activities that would mean that the business can leverage those funds to achieve something more directly attributable to the bottom line versus an operational cost such as managing passwords. What's wrong with passwords? Are there problems that are inherent with passwords that may not be directly noticeable? Because we've been using passwords for so long in our environments, they may not be really apparent to the negative side of passwords. I'll share a few of them with you today just to get your mind thinking about what those could be. This is certainly is not an exhaustive list, but they're the ones that came to me as the majority of the issues that might be encountered with passwords. We need, obviously, complex passwords to ensure that the passwords that we do use are not compromised and give bad actors an entry point into our environments or into our systems. In doing so, complex passwords are not easily remembered. Often, they're difficult. I mean, usually, they're a mishmash of letters and numbers and symbols, capital letters and lowercase letters, and to we humans, they don't make much intuitive sense. A good randomly generated password is anything but English-like. Now, are there opportunities to use things like passphrases? Absolutely, and those are a good counter to the normal random password that are generated. However, having to remember many of those passphrases can pose the same impediments as just randomly generated passwords, especially when you're having to remember many of them. Often, when we do come up with a good password, and we do have that password memorized, we usually do a very bad thing, and that is to use that password on multiple systems or multiple sites. And the disadvantage of that approach is that should one of our passwords get compromised, then the password on all the remainder of those systems is compromised, which gives the bad actor a relatively easy entry point into those other systems. And it's always a good practice to never reuse a password on different systems, to generate or use unique passwords on each individual system. And the way we as humans, we use passwords, and it's more natural for us is to make things simple for us to remember. As we often use weaker passwords, things that are more English-like, that are not structured well. And we do that to be able to remember them more readily, and to be able to access our systems without looking up a password that we've written down somewhere, which is, you know, any time a password is written down, it's always more likely to be compromised when someone finds where we've written it down. And, you know, the most common thing I think of is passwords that are written on a Post-it note and stuck on the bottom of a keyboard. And often those individuals that do physical penetration testing, that's one of the first places they look for those passwords is on that sticky note underneath the keyboard. Passwords must be managed. And by managed, we mean that when a user forgets a password, it has to be reset. And often we misjudge the level of effort or the level of potential effort that we have in our organizations for password resets. And, you know, it's a multiplier effect in that, you know, in some environments, users may have 20 or 30 or 40 accounts and passwords that go along with them. However many accounts each individual user has, those, the potential effort to manage those passwords is a multiplier of the number of users times the number of accounts that they have. And the other thing that we, that may not be really apparent is not only is the user that must have their password reset impacted by the actual process of needing the password reset. We also impair other resources within the organization that must be involved in that password reset process. And usually it's a minimum of two. It's the user that needs the password reset. And then the resource that is assisting that user with the reset. And, of course, that password is usually sent through some means of communication, hopefully not SMS. Email is often the case because, well, the best practice is if we don't exchange the user profile or the user ID and the password in the same conversation, we want to keep those always split. So, again, there's effort there in just making sure that the protocols that we follow for the password reset doesn't lead to compromise in and of itself. Passwords are often vulnerable. In many organizations that Fortra works with, IBMI customers, we often see that communication between the IBMI and the user are not encrypted. So data, meaning user IDs and passwords and even data is flowing over the network in a way that can be clearly seen. And that provides a means of compromising a password and ID as well. And as we mentioned earlier, not only do users use profiles, passwords that are weak, they often use passwords that are already in passwords lists of cracked or compromised passwords. In other words, a password dictionary that a bad actor can use to access systems using those commonly used passwords that aren't well structured or they're just so common, everyone knows about them. So in those two situations, the passwords themselves are vulnerable. There is a password alternative and that password alternative, as we had mentioned in the title, is single sign on on IBMI. And there are some distinct advantages of using single sign on on IBMI that provide remedies to these things we discussed that are. Issues with having passwords in your environment. But first of all, I want to talk briefly about single sign on itself, the technology it's based upon and how it works in particular on IBMI. So in the. The underpinning technology for single sign on on IBMI is Kerberos and Kerberos is a well-known authentication mechanism. It was developed by a third party, particularly MIT. And it is in almost every operating system that's common in the business environment. The advantages of Kerberos is allows the user to authenticate. But they don't have to enter a user and a password. The authentication is actually performed by the authentication mechanism in the Kerberos authentication protocol, and that being the Kerberos ticket. It can be used for authentication from the client to the server. And from the server to client, and it was initially designed to be able to authenticate users. Across untrusted networks. And. The default authentication mechanism within the Windows environment is Kerberos. Now, that's changing, changing with Azure, but if you have native. Domain controllers in your environment on premise and as yours, not Bob, then. Kerberos is being used by all the users in your Windows network. And the. Nice thing about Kerberos and IBMI is that Kerberos can be used for many different functions within. Um, the IBMI environment, uh, and some of those that come to mind are ACS access client solution. So all the functions within ACS, including ODBC and JDBC can leverage Kerberos technology for authentication. Um, and also HTTP as well as. Authentication during the mounting of shares from the desktop to the IBMI system. So those shares that are provided by IBMI can be. Access through Kerberos authentication. And that makes Kerberos an excellent candidate. Uh, in the scheme of IBMI single sign on to eliminate passwords for the vast majority of users on your IBMI systems. Now, in this chart, we're going to walk through, uh, how. Single sign on works on IBMI using Kerberos. Now, you'll notice in the lower left of the pane, there's a Windows user, Jay Smith with his password, Windows password, um, my password and on the IBMI. Jay Smith has a profile that Smith J and interestingly enough, the password for that profile is set to star none, which is not a null password. The password with that special value, it does not exist. So there is no password to compromise or a password to use by the user to access the IBMI system. And in this case, uh, we'll use a telnet or 50 to 50 session, whichever, uh, that, you know, it by as an example of how single sign on IBMI would work. So the first thing we have to have is we have to have a 50 to 50 session on the IBMI system that is defined to use single sign on. The user would open that 50 to 50 session and would not be prompted with any for any credentials to establish that 50 to 50 session. And the reason being is, is that ACS uses APIs on the Windows desktop to request a Kerberos ticket from the Windows domain controller. Now, the controlling factor is that the user has to be authorized to the service, the service principle on the domain controller before the domain controller would issue that Kerberos ticket. Um, but once the domain controller verifies that the user that's making the request has access to the resource, then the domain controller will issue what's called a service ticket. And that service ticket is valid for a one service on one particular system. And in this case, it would be the service that's facilitating the 50 to 50 emulation Kerberos session. So that ticket is then sent back down to the to the desktop and the desktop can peer into that Kerberos ticket and see that it needs that ticket needs to be forwarded on. To the IBMI system. Now, once the IBMI system receives that ticket, Kerberos on the IBMI decrypts that ticket. So the ticket that's being transported around the network is encrypted and cannot be read by anyone or anything except the Windows domain controller and the IBMI. So. And once Kerberos on the IBMI system decrypts the ticket, then the user is authenticated. Now, the user is not authorized to anything, so they, in essence, have been verified that they are who they say they are at this point in the process. So one of the things that we need to do. Once we've been authenticated is we need to be authorized. And the challenge we have at this point is that even though we've logged on with the Windows ID, IBMI does not know which IBMI user profile should be used to authorize this Windows ID. This Windows user to objects and other functions on the IBMI system, and if we go back to our example, we had our user Windows user of Jay Smith and his the IBMI profile for Jay Smith is Smith Jay. But there's not a mechanism at this point that can tell IBMI that Smith Jay should be used when Jay Smith accesses and is authenticated to the IBMI system. And that's where we have enterprise identity mapping. Otherwise known as EIM. You can think of enterprise identity mapping as a cross-reference matrix for a user profile on a particular IBMI system being mapped to a particular Windows ID on that particular system. And that is exactly what what EIM facilitates is enabling IBMI to know that when Jay Smith logs on with his Windows ID, that Smith Jay is the user profile that should be used to authorize Jay Smith to objects and functions on the IBMI system. As I mentioned, there is a restriction in that there can only be one mapping of a Windows ID to one IBMI user profile per partition. So the mappings can be different for different partitions, but within the same partitions, only one mapping is allowed. All mappings are usually contained in one repository. There are some exceptions, but suffice to say that the vast majority of implementations use one repository and that's just for ease of management, primarily. And also for ease of management, systems can be grouped within EIM. So that if there's a lot of group of users within the enterprise uses eight systems, A, B, C, D, E, F, G, and H, a group of users within the enterprise uses eight systems, A, B, and C, and another group of users use systems, D, E, and F, that those systems can be grouped together to eliminate the number of entries that are required inside the EIM domain for each user. So now we're going to look at how accessing IBMI works with Kerberos and EIM. So again, our Windows user is JSmith, and the IBMI user for JSmith is SmithJ. And again, SmithJ does not have a password at all. So as we mentioned before, we got to the point where Kerberos and IBMI had decrypted the ticket. And up to that point, up to and including that point, Kerberos is behaving exactly the way it would in the Windows environment. So there's no difference. This additional step is that when the Kerberos ticket is decrypted, Kerberos passes on information to Enterprise Identity Mapping. And Enterprise Identity Mapping uses that information to correlate that SmithJ should be used as a profile for JSmith when he logs on to this particular IBMI partition. And in this case, since we were using a 5250 session, SmithJ would be passed along to the Telnet server to instantiate a job for SmithJ so that JSmith can start up his 5250 emulation session. So there are single sign-on benefits, and we've talked about some of those already. But just to re-summarize them here is that there are costs associated with password management, especially in the area of password resets. There are also security risks associated with password resets in that that password has to be communicated to the user. And if done improperly or using the wrong mechanisms, that can inject risk into the environment regarding that password. And as we mentioned earlier as well, there's streamlining of the IBMI authentication process in that when I start, in this case, a 5250 session, I'm not prompted for any additional credentials. And the next thing I would see is the windows, I mean, the IBMI menu or screen that I would normally see when I entered my user profile and password. And again, we mentioned that there are fewer passwords to remember, and anytime we can lessen that burden on our users, then it's good for the user as well as for the enterprise. And by implementing single sign-on, we also reduce the overall passwords in the environment. So in that occasion, when we were talking about the amount of potential resource that we expand in managing passwords, that that's directly correlated to the number of users and the number of credentials that each one of those users has in that environment. And additionally, there's no periodic password changes. Now, the interval that is different based upon which framework or standard that you follow. But nonetheless, the periodic password changes are strongly suggested. And that is eliminated with single sign-on in that I don't have to change my password every 90 days or six months or a year, etc. Because there are no passwords on the IBMI system for user profiles. Now, the question may have entered your mind, well, if I have service accounts or if I have some users that don't have AD accounts, does everyone does everyone still have a password or can other users that don't have AD accounts use passwords? And certainly that is the case. You can have a mixed environment where those users that don't have AD accounts can continue to use passwords to access the IBMI system. And often we have customers that have personnel in warehousing and that kind of thing where the functions that they use on IBMI are from a business application perspective is severely restricted by those users in the warehouse. In other words, they're doing only one or two functions. So it may not make sense from a cost perspective to have AD accounts for those users, for example. So in the single sign-on implementation solution that Fortra offers, there are benefits, and that is that for the base implementation, there's no additional software that needs to be purchased. All that software is already licensed to you on your system, and though it may not be installed, it is indeed licensed. Password resets are not required in that we have already eliminated passwords for the user accounts that are going to participate in single sign-on. So without passwords assigned to the profiles, there's not the potential of needing to do a password reset. And, you know, we see that in two flavors. One is that the system profile, in other words, the IBMI user profile password needs to be reset. But also for, you know, environments where users are mounting shares on IBMI, that is another password, another account that needs to be reset when the maximum number of attempts has been exceeded. The other advantages are the user experience is like Windows. So as you're doing things in the Windows environment, for example, you mount the share that's on a Windows file server, you're not prompted for credentials again. And again, that's Kerberos at work underneath the covers providing that authentication. We are leveraging infrastructure that's already in your environment and that we're leveraging the Kerberos underpinnings that are already active in your environment. We also have the ability to recover single sign-on on IBMI should you need to failover to your HA or DR environment as a normal periodic failover or in the case of a catastrophic event. And the other is our objective when we implement single sign-on is to convey that knowledge to your staff so that the day-to-day operations of single sign-on can be facilitated and managed by your staff. There's some additional add-ons that we have. So we do have ongoing support of SSO. We have automated management of the EIM entries. And we also have a hot, warm environment for the EIM domain for you that may be concerned about having a single EIM domain in your environment. And I'll talk about more of those in a future slide. On-premise IBM SSO environment. The primary underpinning for this implementation is that the Windows domain controllers are on-premises in your data center or in a data center co-location that you use and that the Kerberos services are provided by those on-premise domain controllers. IBMI can be on-premises or it can be in the cloud as well as DNS. This particular implementation does facilitate both of those variables. And also, this same infrastructure can facilitate a hybrid Azure environment. And it requires synchronization with Active Directory on-premise to the Azure AD in the cloud, Azure Entrez. Sorry, I forgot they changed the name recently. The next potential implementation is where it's a pure Azure environment. And Fortra has done the research to identify how to facilitate IBMI SSO in this particular environment. The domain controllers reside in the Azure cloud and these are the same implementation as an on-premise Active Directory domain controller. And those Kerberos services are provided by those domain controllers located in Azure. Again, IBMI can be on-premise or in the cloud as well as DNS. And there's many DNS options that are available in Azure, be it roll your own or using some of the built-in DNS services in Azure. Primarily here, the difference is that Azure authentication is used as the primary authentication mechanism. But we can still facilitate single sign-on using Kerberos to IBMI. So, a general overview of the implementation services for IBMI performed by IBM with your staff is we configure Kerberos on each of the IBMI systems. In essence, we're joining the IBMI system to the Windows domain. And we're configuring those systems so that they can have service principles defined to them so the domain controller can issue those Kerberos tickets. We then configure enterprise identity mapping on your IBMI system. And then we help you to build input files to a tool that we have that will enable us to mass load users, whether there be 100 in your environment or as one customer of ours had 7,000. And that will greatly reduce the amount of time it takes to populate the enterprise identity mapping domain as opposed to mainly having to enter in those, all that data. We also then configure other additional services, including the ability of shares to use Kerberos to access clients. I'm sorry, to use Kerberos to access shares provided by IBMI, as well as HTTP and other services that you might need. We also provide strategies for modifications needed by access client solutions. And also how to streamline the distribution of access client solutions to as IBM is continuing to evolve that product very rapidly. We also will provide strategies on recovering SSO in your HA or DR environment, including a mock walkthrough of the recovery process so it can be added to your recovery runbook. And then once we have the implementation complete, then we'll do a comprehensive review with your staff so that they have that base understanding of the components of single sign-on on IBMI and how those all interoperate and the interdependencies so that they can do effective troubleshooting and problem diagnosis and resolution. I want to talk a moment about the additional SSO options that I briefly mentioned on a previous slide and to give you a little bit more information about those. So we offer single sign-on managed services, and this is the subscription service where as a part of that subscription, you get 12 hours of consulting for SSO. And that may be if you want to add a Windows domain, remove a Windows domain, rename a Windows domain, add or remove systems into your EIM environment, or other things related to single sign-on that you may need to do, but not have that experience on your staff to do yet. However, those hours that are provided to you are not locked in for single sign-on only. You can use those hours for anything that's IBMI security related. So, for example, changing the level of the key password level and what would need to go into that or how to secure particular objects to achieve a certain objective. Those are just some of the examples of things that you can use for the IBMI managed services hours. As I mentioned in that previous slide, we do have an automated means of managing the content of the EIM domain, and we do that through a bot that we have developed. That bot uses Automate, which is the Fortra RPA, Robotic Process Automation solution, along with Access Client Solutions and PowerShell to automate the management of the content of the EIM domain. Now, one of the things you do get with the bot is a full license of the Automate product that you can use to automate other repetitive processes, both in your business and environment and in the IT environment to build a free resources to do things that are more valuable to the organization or to minimize the number of human errors that are injected into repetitive processes. The basic way that the EIM bot works is it retrieves the entries from the EIM domain. Firstly, secondly, it retrieves the members of a specific AD security group and it compares those to the contents of those two lists. If a user is in Active Directory security group, but not in the EIM domain, then the bot will add all the necessary entries for that user in the EIM domain. And if the user is in the EIM domain, but not in Active Directory, then it will remove that user from the EIM directory. This can be run as often as you'd like. Some customers run it once a day, some customers run it four times a day, some customers run it one time a week. It really depends on how frequently that you need to run it for it to effectively manage the single sign-on users in your particular environment. We also have an EIM domain high availability offering, which uses the bot to maintain two copies of the EIM domain on two different partitions. And one of those is the active copy and the other is a warm secondary copy. And through the manipulation of DNS entries, systems through a very short manual intervention on each participating partition can be transitioned over to the second warm copy of the IBM EIM domain. And once that primary copy comes back online and is re-synchronized, then the transition back to the primary can occur whenever that is convenient for you and your environment. So, Fortra offers a number of professional services regarding IBMI security, and one we just talked about today is a single sign-on managed services. We also offer risk assessments, which is a comparison of the security configuration of your system to well-known standards, one of those being PCI DSS or CIS. And we provide a comprehensive report to the customer as well as a session to review that report to ensure that the customer understands how that the risks we've identified in categories of critical to low apply to their particular environment. Then we provide architecture services where the findings that are identified in the risk assessment, a defined approach on how to remediate those particular findings is produced and provided to the customer to give a better understanding of the risks that are identified in the risk assessment. Produced and provided to the customer to give a pathway on how to remediate those particular findings. Then we also provide remediation services where we walk through the remediation process, data collection and analysis, alternative strategies and implementation of those changes in the environment side-by-side with the customer, as well as during that process, conveying our knowledge to the user. The customer's admin team so that they can manage that security going forward. We also provide managed security services, which provides ongoing reporting on security metrics to enable you to be aware of potential security management items that need to be resolved to maintain the compliance posture that you need for your particular business. And then lastly, we provide penetration testing, which is specific to IBMI. This is performed as if we already an evildoer is already inside your network and on one of your desktops, and we take that image and demonstrate to you what we can do on your IBMI system and then provide recommendations on how to resolve those findings in the future. We also have best of breed Powertech security products, everything from native antivirus to policy control and compliance and data encryption and secure managed file transfer. So there's many options there that can address your particular security needs in your environment. As a part of that Powertech set of offerings, there is a free complimentary security scan that we can perform on your system in just a matter of moments and provide you back with a colorful summary of the security posture on your system. To give you an idea where you stand on some metrics, security metrics on your system in comparison with best practices. Also, at Fortra.com, we have more demo videos, trial downloads, additional webinars, such as this particular one on a variety of topics. There's also white papers and technical articles that may assist you with implementing and maintaining security on your IBMI system. Most of all, I want to thank you for taking time out of your busy day, and we all know we have limited quantities of time, and I want to say thank you for investing your time in listening to and viewing this webinar. Take care and have a great day. Okay.
