Alert icon Keyboard navigation enabled.
Alert icon TAB or Shift+TAB to navigate across. Down ↓ to open menu. ESC to close menu.
Alert icon Down ↓ to select section. Right → to activate. Up ↑ / Down ↓ / Tab to traverse all. ESC to exit.
BeyondTrust
Skip to content Use space or enter to skip.

What can we help you find today?

Instant Results
  • Website Results
  • Technical Documentation

Filter Options

Focus your search

Filtering by

Your recent searches:

Contact Us Chat with Sales Get Support
  • English
  • Deutsch
  • français
  • español
  • 한국어
  • português
  • Home
  • Resources
  • Blog
  • Active Directory Bridging – a Simplified Access Control Story current page
Link copied

Active Directory Bridging – a Simplified Access Control Story

Nov 16, 2017
Author:
Pharper
Paul Harper
Product Manager, BeyondTrust
Blog banner default
Active Directory Bridging – a Simplified Access Control Story
Pharper
Paul Harper
Product Manager, BeyondTrust

blog-powerbroker-identity-services-8-5-5.jpg

When it comes to managing users and passwords on non-Windows systems, an Active Directory bridge solution goes a long way in simplifying things for Unix and Linux admins – one place to create users, one place to change passwords, and one place to go when it is time to deprovision an account. Life is made even easier by the fact that Microsoft produces some pretty nice graphical tools to ease centralized management, as well as making their directory manageable with both command-line and API style interfaces. However, when it comes to controlling who can log on to what servers, the story can become a little more complicated.

In the Windows world, where you are typically dealing with basic users and locked down workstations that don’t house much in the way of sensitive or business critical data, the default of every domain user can logon to every domain joined workstation continues to work well for many people, and so it should.

For those servers that have been bolted into your Active Directory, to simplify user administration there is an initial safety net. Each user needs some ‘Unix’ information added to their account before a Unix or Linux server is going to let you get down to the shell prompt. Known as POSIX attributes, a user must have a uid, gid, and home directory and default shell before their Active Directory username and password can be used to access a *nix style server. But a simple true/false type access control is nowhere near good enough.

With PowerBroker Identity Services Enterprise there were still local controls that could be managed on each server, or for a more centralized approach, you could use Microsoft Group Policy to manage those same settings and tie ‘who can logon’ type settings to groups of machines. However, now you are using two different administration tools to control two items that are intrinsically linked, i.e. the credentials that are used to access a sever and what servers those credentials should be accepted on.

PowerBroker Identity Services version 8.5.5 – new Host Access Control Groups

With the introduction of PowerBroker Identity Services version 8.5.5, a new feature called Host Access Control Groups has been added which allows access control to be defined by simply adding users and/or groups of users, along with computer accounts and/or groups of computer accounts to an appropriately named native Active Directory Group. The Access Control group in Active Directory is matched using the Access Control Template system, which in turn automatically applies those access control rights to all the server in a given PowerBroker Identity Services Cell (essentially an OU containing one or more *nix servers). This allows the Active Directory administrator that creates and manages users and groups to also control what systems those users can logon to.

Example scenario

In a database environment, access control is required on a set of hosts running database applications that include the following:

  • Group of database server hosts DatabaseServers: dbsrv1, dbsrv2, dbsrv3
  • Group of database client hosts DatabaseClients: dbcli1, dbcli2, dbcli3
  • Group of database administrator accounts: DatabaseAdmins: dbadm1, dbadm2, dbadm3
  • Group of database application user accounts: DatabaseUsers: dbusr1, dbusr2, dbusr

Database administrators can access all database hosts—create a DatabaseAdmins-ACL group that includes the following groups as members: DatabaseServers, DatabaseClients and DatabaseAdmins.

Database users can access only database client hosts—create a DatabaseUsers-ACL group that includes the following groups as members: DatabaseClients and DatabaseUsers

Access Control in Action

Assigning groups in the Active Directory Users and Computers GUI is as simple as identifying PowerBroker Identity Services Access Control List type groups by name or using wildcards in the Access Control Group template section for any given Cell as shown below:

ss-pbis-8-5-5.jpgss-pbis-8-5-5-b.jpg

Here you can easily see how an Access Control Group that has been set on a PowerBroker Identity Services cell links to Host User Access Control groups using a simple template style naming convention, along with a simple check showing from a Linux server how easy it is to verify by what method a user has been granted access to any given host:

ss-pbis-8-5-5-c.jpg

This new capability provides a single location for user, group and access control administration, thereby simplifying management as well as providing a vastly simplified way of reporting exactly who has access to which hosts.

PowerBroker Identity Services (AD Bridge) is BeyondTrust’s solution to extend Microsoft Active Directory authentication, single sign-on capabilities and Group Policy configuration management to Unix, Linux and Mac systems, to improve efficiency, simplify compliance and reduce risk. For more on how we can simplify Unix and Linux security, contact us today!

Latest Posts
  • Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta
    Jun 12, 2026 Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta
    Blog
    7m
  • Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
    Jun 9, 2026 Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
    Blog
    6m
  • Joining Project Glasswing: Securing the Privilege Backbone of the AI Era
    Jun 8, 2026 Joining Project Glasswing: Securing the Privilege Backbone of the AI Era
    Blog
    5m
  • The Most Common & Most Dangerous Types of Shadow IT
    Jun 5, 2026 The Most Common & Most Dangerous Types of Shadow IT
    Blog
    19m
  • 14 Password Management Best Practices
    May 28, 2026 14 Password Management Best Practices
    Blog
    12m
Related
  • Shelter from the Storm – What Midnight Blizzard’s Attack on Microsoft Tells Us about Modern Identity-Based Attacks
    Jan 24, 2024 Shelter from the Storm – What Midnight Blizzard’s Attack on Microsoft Tells Us about Modern Identity-Based Attacks
    Blog
    1m
  • Technology Alliance Tuesday's Team Feature - Jackeline Tabares
    Mar 7, 2023 Technology Alliance Tuesday's Team Feature - Jackeline Tabares
    Blog
    1m
Share this Article
  • Link
Stay up to Date
Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

Keep up with BeyondTrust

Customer Support Get Started
  • LinkedIn
  • X
  • Facebook
  • Instagram
  • Add BeyondTrust as a preferred source on Google
  • Privacy
  • Security
  • Manage Cookies
  • Do Not Sell My Data
  • WEEE Compliance

Copyright © 2003 — 2026 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.

Prefers reduced motion setting detected. Animations will now be reduced as a result.