H2FY20 Securely Managing Your UNIX Environment

energy to education, and from manufacturing to retail. The reason for the high costs? Simply put, it’s expensive to perform the same action, again and again, across systems that are not sharing the same basic identity infrastructure. Managing identities and access for multiple UNIX systems is complex and inefficient because each system is unconnected and each is a disjointed island unto itself. Let’s examine the specific issues with each of the four A’s for UNIX. Authentication in UNIX No native single sign-on burdens users with multiple accounts and passwords Not all AD bridge solutions are created equal. Be sure to choose one that gives you all the authentication convenience you require—without adding complexity for authorization, administration, and audit. 3 For organizations with multiple UNIX systems, authentication is a box-by- box process. Each user must have an account on each system he or she needs to access. There is no easy way to ensure that the accounts are the same. Due to the errors that creep in over time, inconsistency of the timing of deployment, and the fact that practices and support staff change over time, a single physical user may be represented by dozens (or even hundreds or thousands) of separate accounts that bear no connection with each other. The user names may be different, the user IDs (UIDs) may be different, and the passwords will most certainly be different, expiring at different times and possibly requiring different security policy. In other words, natively UNIX does not provide any sort of single sign- on environment for users. Users who must access multiple UNIX systems are required to remember many passwords and must spend large amounts of time simply logging in and out of each system. Early efforts to consolidate logins and identities in UNIX (such as NIS), unfortunately, do not live up to modern security and compliance standards. For example, NIS sends passwords over the wire in clear text, an obvious violation of virtually every compliance regulation. Administrators have to provision each account separately UNIX accounts present issues for administrators as well as end users. Natively, it is not possible to provision all UNIX accounts for a user in one action. The account must be set up individually (even if it represents the same person) on each box. That’s not much of a problem with one, two, or even 10 UNIX boxes and a handful of users. But what about when the UNIX install stretches into the hundreds or thousands and the number of users grows as well? Active Directory bridge solutions extend authentication and administration to UNIX Since the early part of the 21st century, technologies have existed that overcome the shortcomings of both native UNIX authentication and NIS. Active Directory (AD) bridge solutions extend the authentication security, manageability, and single sign-on capabilities of Microsoft Active Directory—and specifically its enterprise-class implementation of the Kerberos and LDAP protocols—to UNIX, Linux, and Mac OS X systems. With an AD bridge solution, a single logon to AD can authenticate and grant access to the entire range of UNIX systems that have “joined” the AD trusted realm. And a single account in AD is all that must be provisioned, managed, and terminated. Be sure to choose your AD bridge solution carefully, so as not to complicate other A’s However not all AD bridge solutions are created equal. If authentication were the only concern, any solution would do. But the implications of joining a UNIX system to AD extend beyond simply authentication to authorization, administration, and audit. The right AD bridge solution for your environment would be the one that gives you all the authentication convenience you require, without adding complexity for authorization, administration, and audit. In other words, the more transparent your AD bridge is, the better off you are. Authentication Services is the most mature, and most robust AD bridge on the market. It pioneered the AD bridge market and has been providing unified authentication for UNIX-based systems since 2004. Multiple deployments of Authentication Services exceed 100,000 users and tens of thousands of servers. In fact, the top 10 largest Active Directory bridge deployments all use Authentication Services (with one deployment nearing 100,000 4 servers). For a discussion of the important issues to consider when selecting an AD bridge solution see the One Identity white paper “Choosing the Right Active Directory Bridge Solution.” Authorization for UNIX Similar to authentication, each UNIX system requires its own authorization. The challenges of box-by-box authorization can be overcome by using an AD bridge. Basing authorization rights on AD group membership overcomes the administrative, security, and compliance challenges of natively building and enforcing authorization individually on each UNIX-based server. It’s important to choose an AD bridge solution that enables AD-based authorization without introducing additional complexities and more layers of management or infrastructure. Authentication Services provides the most seamless integration between AD and UNIX and leverages familiar and established AD administrative practices and interfaces. Identity administration for UNIX Provisioning is timeconsuming for administrators Neither authentication nor authorization for UNIX systems can adequately occur if identity administration is not under control. Again, the challenge with UNIX is the fact that identity must exist on every box. Therefore, provisioning user accounts for a new employee could involve manually setting up accounts on dozens, hundreds, or even thousands of UNIX servers. It is nearly impossible to maintain consistency of username and UID. And the negative impact on productivity can be crippling, as all the provisioning work on UNIX systems typically must be performed by administrators whose primary jobs are not user support. Manual de-provisioning processes entail significant risks As troublesome as provisioning is, de- provisioning is downright dangerous. Delays in terminating access to UNIX systems present compliance violations, at best, and an open door to malicious activity, at worst. The highly publicized breach at Fannie Mae was a direct result of delays in terminating access to UNIX systems. With the high number of servers involved, the manual nature of UNIX identity administration, and the lack of centralized oversight available natively in UNIX, it’s a miracle that we haven’t had more Fannie Mae’s. Password management is a drain on users and administrators alike Finally, there’s the issue of passwords. Every box requires an account, which means every box requires a password. Again, the administrative tasks associated with managing those passwords— enforcing complexity rules, requiring periodic changes, and resetting forgotten passwords— are an incredible drain on operatio
Please complete the form to gain access to this content