cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Best practices for managing high volumes of local server accounts

Best practices for managing high volumes of local server accounts

 

Overview

One of the challenges of large enterprise environments is managing the elevated user (system administrator) access to servers and databases. System administrators generally need elevated access to each server to perform IT functions. As the environment's requirements change, new servers are added, and the footprint grows from dozens of servers to hundreds or perhaps thousands of standalone servers. Over time, without a standard policy and practice for managing the accounts, the environment can become disjointed and decentralized. When local authentication/authorization is used, each server must be managed separately, which increases cost and risk and reduces the overall security of these servers.

A typical scenario might be:

"Our system administrators have accounts across all the UNIX servers. When a new admin joins, we need to be able to add their account to a thousand UNIX servers, a thousand Oracle instances, and some Local Windows Servers. When an admin needs to change their password, it should propagate out across all these servers. We don’t use centralized authentication/authorization services such as NIS, PAM, LDAP, or Kerberos.”

This is not the traditional “service account” use case, such as managing “root” or “Administrator” across all the servers, although it is similar. In this case, the customer is actually giving “Joe User” a “joeuser” account on all the servers. This can cause major scale issues in IdentityIQ when all of these “links” are correlated to a single identity. There are examples from the field where customers have used IdentityIQ for this use case up to the 100 link per Identity scale, with only minor difficulties. However, the scale limits vary based on the environment. When the use case goes beyond hundreds into the thousands of links per Identity Cube, any operations managing the Cube can become effectively unusable.

To compound the problem, these environments often require the role model to also scale out to these thousands of applications per role. When a role with thousands of applications is assigned to one Identity, the provisioning plan is very large and it is provisioned serially. This can cause provisioning times for a new user to be hours or days. Any operations managing these large Cubes is often in the order of minutes to hours.

 

SailPoint best practices

Background

The industry standard practice introduced in the late 1990s is to use a centralized service for authentication, authorization and local account settings. This practice started with UNIX-specific services such as NIS and evolved over time into modern directory services solutions such as LDAP and Microsoft Active Directory. Several vendors in this market provide packaged LDAP server solutions specifically to provide centralized authentication and authorization services to many types of systems and applications. Most companies managing more than a few hundred servers internally have adopted this industry standard best practice.

Central authentication/authorization for local server administrator access in useful even with a handful of servers. For example, in the POSIX world, additional account information is typically associated with a directory entry. This can include the user's preferred shell, home directory (typically also centralized), etc. In the Microsoft world, there are similar benefits. It is convenient to have this information stored and consumed from a single location. This standardization also improves security, usability and productivity in the enterprise.

This paradigm also greatly reduces the administrative overhead of standing up a new server. When the new server is built, it is added to the directory, and storage server and authorized users are able to authenticate to the new server with all their files and settings already in place. There is no ongoing user management on these servers. There are also benefits when making changes to accounts (for example, changing the user’s display name), since these changes do not need to be propagated or synced to hundreds of servers, but is instead managed in a central location. Synchronizing passwords and enforcing standard password policies across all the servers in an environment is simple using centralized authentication and authorization services

Finally, one of the biggest benefits is that once a centralized authentication/authorization repository is established, a multitude of external applications can leverage the directory information without the need for establishing additional accounts or syncing data. For example, many enterprise applications are able to tie to LDAP or Active Directory for account information, in addition to supporting their own local native account formats. This can greatly reduce the overhead associated with deploying a new application.

Overall, nearly all IT organizations in medium to large companies have recognized the benefits of centralized authentication and authorization services to reduce cost, improve security and improve the productivity of their large server infrastructure.

 

SailPoint's recommendations

IdentityIQ is designed to manage local server access through common directory services solutions provided by standard LDAP servers and Active Directory. IdentityIQ can also be used to manage local server access through a master NIS server in the enterprise. Access to these servers is generally granted through elevated groups in each server. This approach allows the customer to leverage SailPoint's Lifecycle Management features to on-board new users, request access, change passwords and terminate access through one application. This allows each solution to combine their strengths to provide the most secure and efficient Identity and Access Management solution for the customer's environment.

  • Implement one or more centralized authentication and authorization services solutions to control access to these servers and local administrator accounts. This could be an LDAP based solution, Microsoft Active Directory, or other solution where the authentication and authorization of local accounts is centralized within a single service. The management of these accounts is also centralized within this service.
  • Integrate IdentityIQ with the centralized authentication and authorization service to provide the enterprise Identity and Access Management features. IdentityIQ can be used for the Lifecycle Management of these user Identities including new hire, terminations, access requests, and password management. Groups and permissions which grant administrator access to the local servers can be managed by IdentityIQ through Role definitions and assignments. Access to these elevated permissions can also be audited through IdentityIQs Access Review interfaces.
  • SailPoint does not recommend using IdentityIQ to manage a single administrator's access across thousands of local servers.  Although functionally the product could be used for this use case, from a usability standpoint the amount of time and system resources required are not practical.

 

Legacy identity management solutions

Some companies using legacy Identity Management solutions have leveraged these products to manage the administrator accounts across distributed servers. While functionally these solutions may meet the basic requirements of elevated user access provisioning, they are not designed to manage large numbers of distinct servers. Customers may find themselves spending more time managing the legacy Identity Management product then they do leveraging the business purpose of these decentralized servers. These solutions are also very fragile, hard to upgrade and support. They also don't provide a cost-effective method to migrate from one Identity Management solution to new one.

 

Evaluating your organization's needs

These questions can help you determine how best to manage elevated user access to a high volume of servers and databases.

  1. Do you have multiple local servers in your environment that are using local authentication / authorization (/etc/passwd, Windows local)?
    • How many, and what type?
    • How are you managing these local accounts today?
  2. Have you considered a centralized authentication/authorization service such as Active Directory, Kerberos, NSS, LDAP PAM?
    • Why not? Were there limitations of a centralized service that prevented deploying in your environment?
    • Was cost a factor?
  3. Do you create user accounts across all the servers in this environment with the same level of access? (DBA, IT Staff, Developers, etc)
    • What type of user populations and the breakout?

 

Frequently asked questions

What about migrating my existing accounts on these servers?

Most solutions provide migration tools to automatically add existing user IDs to the directory or to quickly migrate servers.

 

I have servers in a secure zone in my network; how will this work?

These services are provided over secure ports which can be routed into and out of a secure zone. Some products also provide the ability to distribute their services to different network zones and synchronize with a master server.

Labels (2)
Version history
Revision #:
2 of 2
Last update:
‎Aug 01, 2023 07:56 PM
Updated by:
 
Contributors