Servers such as file and print servers would be located on-premises within a server closet, and if the organization was large enough, their server farm for applications and data would be within their own data center or a colocation facility. It was generally straightforward to make those directories talk to their servers since everything was \u201clocal\u201d or within the domain through VPNs and MPLS infrastructure.<\/p>\n\n\n
![\"light](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/lightbult-white-and-black.png\")
<\/figure><\/div>\n\n\nOver the last decade, though, cloud infrastructure or Infrastructure-as-a-Service has gained tremendous popularity. The 2018 State of the Cloud<\/a> survey discovered the following from their participants:<\/p>\n\n\n\n Many sysadmins and DevOps engineers choose perhaps the simplest way out of this predicament \u2013 manually create, manage, and delete users on their cloud servers. Sysadmins will somehow be notified of who requires what access to the cloud servers, and they will manually provision and manage those users on the cloud servers. <\/p>\n\n\n\n This entails logging into the servers themselves and managing the user creation, modification, or termination process. As the number of servers and users grow, this presents some significant challenges around tracking access. <\/p>\n\n\n\n Also, adding security features such as\u00a0multi-factor authentication<\/a>\u00a0becomes problematic to enforce at scale without a central directory or user store. Finally, many sysadmins in AWS simply leverage a single ec2-user account for access largely because it\u2019s easier, but losing any on-host auditing capability in the process.<\/p>\n\n\n Another option often considered by sysadmins is to expose LDAP or AD to the Internet and let the servers talk directly to the directory service. Note that this requires that the cloud servers have Internet access and the ability to talk to the user directory. <\/p>\n\n\n\n Through additional security and configuration, the LDAP <\/a>or AD servers can be locked to only talk to certain servers or through VPNs<\/a>. Depending upon the network architecture and growth of servers this may or may not be an option. If it isn\u2019t, then the user directory store is available to be queried by anybody on the Internet.<\/p>\n\n\n For some organizations, a viable option is to create another directory store. Generally this involves standing up a new instance of Active Directory or OpenLDAP in the cloud<\/a>. This works well if the cloud setup is logically in a \u201cVLAN\u201d or equivalent enclave where the directory server can talk to each of the servers.<\/p>\n\n\n\n Additionally, the cloud directory will either need to be synchronized with the main directory service or will need to be manually updated. This creates an extra layer of work for sysadmins but does give them the ability to manage users for their cloud servers via either OpenLDAP or Active Directory.<\/p>\n\n\n While one of the methods mentioned above may be the quick fix that you need for cloud server user management, none of them will enable you to remain agile and competitive in the long term.<\/em><\/p>\n\n\n\n It is critical for organizations to have only one source of truth for users on the network. As you can imagine, multiple directories or manual management can easily cause conflicts and issues. The manifestations of problems in this category can be catastrophic such as a terminated employee still having access to a number of critical servers because there wasn\u2019t an in-sync directory of users. <\/p>\n\n\n\n The less catastrophic and more mundane consequences of multiple directories is a layer of additional work and complexity. As the organization grows, the complexity will increase. Multiple, disparate directory services is never a good idea.<\/p>\n\n\n The move to the cloud for many companies is an acknowledgement that networking and network related configuration isn\u2019t an effective use of their time. Unfortunately, exposing your directory service to the Internet or standing up an additional directory service in the cloud each come with their network configuration requirements. <\/p>\n\n\n\n You\u2019ll need to be careful to walk through the right access controls to make sure that all of your machines can talk to each other properly \u2013 and, over the right ports and protocols. While not impossible, it is an added task and one that most organizations moving to the cloud would rather not have.<\/p>\n\n\n A number of these solutions can have reliability issues. Manually managing user access is subject to human error. Did every person get the access that they needed or did they get too much access? Creating additional directory servers in the cloud starts a whole additional chain of work.<\/p>\n\n\n\n Directory services<\/a> need to be highly available and downtime can mean your users can\u2019t do their work. Exposing your directory service to the Internet can invite DoS attacks or cause you to be subject to Internet connectivity issues between your cloud servers and your identity provider. You\u2019ll need to address those issues either through load balancing or increased capacity.<\/p>\n\n\n Every one of these options can be expensive for organizations. While some may be expensive from a monetary standpoint, others may be expensive from a time and resources perspective. Either way, managing users<\/a> across your organization is often not a core competency. It needs to be done well and securely, but the costs of having resources focus on this task versus core tasks can be expensive.<\/p>\n\n\n One option to solve this problem is to fix a central directory service with either OpenLDAP or Active Directory internally. This directory service becomes the identity provider of record. <\/p>\n\n\n\n From this central directory store, organizations create a secure identity bridge<\/a> to their cloud server infrastructure. That infrastructure may be at one or a number of different IaaS players.<\/p>\n\n\n The other option is to centralize the entire identity management infrastructure with a cloud directory service<\/a>. This modern cloud directory will connect user identities to cloud servers, on-prem systems, web applications, file servers, networks, and more. <\/p>\n\n\n\n There is no requirement for VPNs, networking, operational management, and the other heavy lifting of managing your own directory service. In fact, sysadmins and DevOps engineers<\/a> outsource the work and infrastructure of a directory service, yet they get the benefit of centralized access control, especially over their cloud servers.<\/p>\n\n\n Smart organizations will leverage a SaaS-based cloud directory service because there are numerous benefits to this modern approach.<\/p>\n\n\n\n Agents installed on each server talk back securely to the cloud-based, SaaS directory service.<\/p>\n\n\n\n You don’t have to expose your central directory to the Internet, and user access to your server infrastructure is tightly controlled. Because 81% of data breaches have been the result of weak or stolen passwords*, the number one risk for any organization is compromised user accounts. Knowing for certain who has access to what is crucial in fighting this attack vector.<\/p>\n\n\n\n * 2017 Verizon Data Breach Investigation Report<\/p>\n\n\n\n IT admins and DevOps engineers simply load their users into the cloud identity provider and provision the appropriate access without having to deal with infrastructure and management.<\/p>\n\n\n\n Consider reading one of the case studies<\/a> above and see how JumpCloud has enabled many organizations to achieve centralized user management across all IT resources. The Tamr Case Study<\/a> in particular is a great example of an organization using JumpCloud to centralize user access to 300 remote servers, G Suite, LDAP, SAML apps, WiFi, and systems. Additionally, you can find more information on our blog<\/a>, YouTube Channel<\/a>, and Knowledge Base<\/a>, or you\u2019re more than welcome to drop us a note.<\/p>\n\n\n\nExploring Traditional Solutions to a Complex Problem<\/h2>\n\n\n\n
Manually managing cloud server accounts<\/h3>\n\n\n\n
![\"Google](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/manual-work.png\")
<\/figure><\/div>\n\n\nExpose LDAP or AD to the Internet<\/h3>\n\n\n\n
![\"globe](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/internet-globe.png\")
<\/figure><\/div>\n\n\nStand up an entirely new LDAP or AD instance in the Cloud<\/h3>\n\n\n\n
![\"Cloud](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/cloud.png\")
<\/figure><\/div>\n\n\nCommon Problems with Traditional Solutions<\/h2>\n\n\n\n
Decentralized Identities<\/h3>\n\n\n\n
![\"Remote](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/users.png\")
<\/figure><\/div>\n\n\nNetwork configuration\/security exposure<\/h3>\n\n\n\n
![\"FreeRADIUS\"](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/wifi.png\")
<\/figure><\/div>\n\n\nReliability Concerns<\/h3>\n\n\n\n
![\"two](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/reliability.png\")
<\/figure><\/div>\n\n\nHigh Costs<\/h3>\n\n\n\n
![\"stacks](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/high-costs.png\")
<\/figure><\/div>\n\n\nTwo Modern Solutions for Cloud Server User Management<\/h2>\n\n\n\n
Solution 1: An On-prem Directory Service with an Identity Bridge<\/h3>\n\n\n\n
![\"jumpcloud](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2018\/10\/ad_bridge-1030x657.png\")
<\/figure><\/div>\n\n\nSolution 2: Cloud Directory Service<\/h3>\n\n\n\n
![\"directory-as-a-service\"](\"https:\/\/jumpcloud.com\/wp-content\/uploads\/2017\/12\/4-spoke-diagram-for-darkbackground-1030x1030.png\")
<\/figure><\/div>\n\n\nA Closer Look at the Benefits of a Modern Approach<\/h2>\n\n\n\n
No Network Configuration Required<\/h3>\n\n\n\n
Increasing Security<\/h3>\n\n\n\n
Little to No Additional Administration<\/h3>\n\n\n\n
Looking For More Information?<\/h2>\n\n\n\n