PBIS Installation and Administration Guide

June 21, 2013
Installation and Administration Guide
Release 7.5

Revision/Update Information: June 21, 2013
Software Version: PowerBroker Identity Services Enterprise Edition 7.5
Revision Number: 2
COPYRIGHT NOTICE
Copyright © 2013 BeyondTrust Software, Inc. All rights reserved. Use of this software and/or document, as and when applicable, is
also subject to the terms and conditions of the license between the licensee and BeyondTrust Software, Inc. (“BeyondTrust”) or
BeyondTrust’s authorized remarketer, if and when applicable.
TRADE SECRET NOTICE
This software and/or documentation, as and when applicable, and the information and know-how they contain constitute the
proprietary, confidential and valuable trade secret information of BeyondTrust and/or of the respective manufacturer or author, and
may not be disclosed to others without the prior written permission of BeyondTrust. This software and/or documentation, as and when
applicable, have been provided pursuant to an agreement that contains prohibitions against and/or restrictions on copying,
modification and use.
DISCLAIMER
BeyondTrust makes no representations or warranties with respect to the contents hereof. Other than, any limited warranties expressly
provided pursuant to a license agreement, NO OTHER WARRANTY IS EXPRESSED AND NONE SHALL BE IMPLIED,
INCLUDING WITHOUT LIMITATION THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR USE OR FOR A
PARTICULAR PURPOSE.
LIMITED RIGHTS FARS NOTICE (If Applicable)
If provided pursuant to FARS, this software and/or documentation, as and when applicable, are submitted with limited rights. This
software and/or documentation, as and when applicable, may be reproduced and used by the Government with the express limitation
that it will not, without the permission of BeyondTrust, be used outside the Government for the following purposes: manufacture,
duplication, distribution or disclosure. (FAR 52.227.14(g)(2)(Alternate II))
LIMITED RIGHTS DFARS NOTICE (If Applicable)
If provided pursuant to DFARS, use, duplication, or disclosure of this software and/or documentation by the Government is subject to
limited rights and other restrictions, as set forth in the Rights in Technical Data – Noncommercial Items clause at DFARS 252.227-
7013.
TRADEMARK NOTICES
PowerBroker, PowerPassword, and PowerKeeper are registered trademarks of BeyondTrust. PowerSeries, PowerADvantage,
PowerBroker Password Safe, PowerBroker Directory Integrator, PowerBroker Management Console, PowerBroker Desktops,
PowerBroker Virtualization, PowerBroker Express, PowerBroker Databases, PowerBroker Windows Servers, PowerBroker Windows
Desktops, and PowerBroker Identity Services are trademarks of BeyondTrust.
ssh® is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. The SSH
logo, Tectia and tectia logo are trademarks of SSH Communications Security Corp and may be registered in certain jurisdictions.
This application contains software powered by PKAIP®, the leading solution for enabling efficient and secure data storage and
transmission. PKAIP® is provided by PKWARE, the inventor and continuing innovator of the ZIP file format. Used with permission.
FICTITIOUS USE OF NAMES
All names of persons mentioned in this document are used fictitiously. Any resemblance to actual persons, living or dead is entirely
coincidental.
OTHER NOTICES
If and when applicable the following additional provisions are so noted:
The PowerBroker Identity Services Open software is free to download and use according to the terms of the Limited GPL 2.1 for
client libraries and the GPL 2 for daemons. The licenses for PowerBroker Identity Services Enterprise and for PowerBroker Identity
Services UID-GID Module are different. For complete information on the software licenses and terms of use for BeyondTrust
products, see www.beyondtrust.com.

Contents
I. Preparing for PBIS Deployment 1
Introduction to PBIS Enterprise 2
PBIS Overview 2
PBIS Components 3
Task Road Map 4
PBIS Feature Review 6
PBIS Agent 6
Services 6
PBIS Registry 12
Ports and Libraries 12
Caches and Databases 12
Time Synchronization 14
Using a Network Time Protocol Server 15
Automatic Detection of Offline Domain Controller and Global Catalog 15
UID-GID Generation in PowerBroker Cells 16
Cached Credentials 16
Trust Support 16
Integrating with Samba 19
Supported Platforms 19
SELinux Support 19
Storage Modes 20
Directory Integrated Mode 20
Schemaless Mode 21
Key Differences 23
Pros and Cons of the Modes 24
PowerBroker Cells 25
Types of Cells 26
How Cells Are Processed 27
Cell Design 28
Using Multiple Cells 30
Linking Cells 30
Managing Cells with Cell Manager 31
Migrating Users to Active Directory 31
Migrating NIS Domains 31
Finding Orphaned Objects 32
Planning Your Installation and Deployment 33
Installation and Provisioning Overview 33
Planning Your Deployment 34
Best Practices for Modes, Cells, and User Rights 35
Number of Cells 35
PBIS Enterprise Installation and Administration Contents
BeyondTrust® June 21, 2013 3

Storage Mode 35
Migrating Cells 35
User Rights 35
Pre-stage Unix Computer Accounts 36
Best Practices for Windows 36
PBIS Enterprise Tools Best Practices 36
Active Directory Best Practices 37
Reporting Tools Best Practices 37
Group Policy Best Practices 38
Best Practices for Unix, Linux, and Mac OS X 40
AIX Best Practices 40
Linux Best Practices 40
Mac OS X Best Practices 41
Solaris Best Practices 41
Unix Applications Best Practices 42
Account Management Best Practices 42
Best Practices for Operations 43
SSH Logons 43
Lookups and Configuration 43
Operating System Patching and Upgrades 43
II. Installing and Provisioning PBIS 44
Installing the Management Console 45
Requirements 45
Microsoft Management Tools 45
Administrator Privileges 46
Active Directory Requirements 46
Windows Requirements for the Console 46
Requirements to Run PBIS in Directory Integrated Mode 47
Networking 47
Replication 47
Supported Platforms and Applications 48
Install the BeyondTrust Management Console 48
Run the Initialization Wizard 50
Configuring Clients Before PBIS Agent Installation 51
Configure nsswitch.conf 51
Configure resolv.conf 52
Configure Firewall Ports 52
Extend Partition Size (IBM AIX) 52
Increase Max User Name Length (IBM AIX) 53
Installing the PBIS Agent 54
Install the Correct Version for Your Operating System 54
Checking Your Linux Kernel Release Number 55

Package Management Commands 55
Requirements for the Agent 55
Environmental Variables 55
Patch Requirements 56
Other Requirements for the Agent 57
Additional Requirements for Specific Operating Systems 58
Install the Agent on Linux or Unix with the Shell Script 58
Install the Agent on Linux in Unattended Mode 59
Install the Agent on Unix from the Command Line 59
Install the Agent on a Mac OS X Computer 60
Install the Agent on a Mac in Unattended Mode 61
Install the Agent in Solaris Zones 62
Upgrading Your Operating System 64
Configuring SELinux 64
Installing SELinux on Unsupported Platforms 64
Configuring SELinux After Installing 65
Configuring Clients After PBIS Agent Installation 66
Modify Settings with the Config Tool 66
Add Domain Accounts to Local Groups 67
Configure Entries in Your sudoers Files 68
Check a User's Canonical Name on Linux 69
Set a sudoers Search Path 69
AIX: Create Audit Classes to Monitor Events 70
Joining an Active Directory Domain 72
Privileges and Permissions 73
Creation of Local Accounts 73
Join Active Directory from the Command Line 75
Before Joining a Domain 75
Join a Linux or Unix Computer to Active Directory 75
Join a Mac Computer to Active Directory 76
Join a Linux or Unix Computer to an Organizational Unit 76
Join a Linux or Unix Computer to a Nested Organizational Unit 76
domainjoin-cli Options, Commands, and Arguments 77
Basic Commands 77
Advanced Commands 78
Configuration and Debugging Commands 83
Join Active Directory Without Changing /etc/hosts 84
Join a Linux Computer to Active Directory 85
Join a Mac Computer to Active Directory 87
Turn Off OS X Directory Service Authentication 89
Files Modified When You Join a Domain 89
Logging on with Domain Credentials 92
Log on with AD Credentials 93

Log on with SSH 93
III. Administration 94
Using the Management Console 95
Start the BeyondTrust Management Console 95
Connect to a Domain 97
Run the Directory Integrated Mode Wizard 97
Running the Directory Integrated Mode Wizard 97
Changes Made by the Directory Integrated Mode Wizard 98
Replication in a Large Forest or in Multiple Domains 99
Add a Plug-In 99
Working with Cells 100
Create a Cell and Associate it with an OU or a Domain 100
Moving a Computer to Another Cell 102
Create a Default Cell 102
Associate a User with Cells 103
Add a Group to a Cell 103
Add a User to a Cell 104
Modify PowerBroker Cell Settings in ADUC 106
Link Cells 106
Delegate Control to Create Container Objects 108
Administering Cells with Cell Manager 109
Start Cell Manager 109
Delegate Management 110
Change Permissions of a Cell, Group, or User 111
Add a Cell 111
Give a User Access to a Cell 112
Give a Group Access to a Cell 113
Filter Cells 113
Connect to a Different Domain 113
Managing Users, Groups, and Computers 114
Create a User 114
Finding Users and Groups in ADUC 116
Provision a User with Linux or Unix Access 117
Provision a Group with Linux or Unix Access 119
Specify a User ID and Unix or Linux Settings 120
Apply Unix or Linux Settings to Multiple Users 122
Set a User Alias 123
Set a Group Alias 124
Set the Default Home Directory 124
Set the Home Directory for a Cell 125
Set the Home Directory for Multiple Users 125
Set the Home Directory for a Single User 126

Set the Default Login Shell 126
Set the Login Shell for a Cell 126
Set the Login Shell for Multiple Users 127
Set the Login Shell for a Single User 127
Assign a Group ID 128
Disable a User 129
Improve MMC Performance When Accessing Settings in ADUC 129
Extend File Mode Permissions with POSIX ACLs 130
Prerequisites 130
Example 131
Using POSIX ACLs to Grant AD Accounts Access to Subversion 133
Using the Domain-Join Tool 134
Use PBIS with a Single Organizational Unit 134
Rename a Joined Computer 135
Rename a Computer Using the Command-Line Tool 136
Rename a Computer by Using the Domain Join Tool GUI 136
Removing a Computer from a Domain 138
NetworkManager: Use a Wired Connection to Join a Domain 138
Migrating Users to Active Directory 139
Migrate Users to Active Directory 140
Before Running the Migration Tool 140
Run the Migration Tool 140
Find Orphaned Objects 143
Migrate a User Profile on a Mac 143
Migrate a User Profile from the GUI 144
Migrate a User Profile from the Command Line 145
Customize the Migration Script 145
Leaving a Domain and Uninstalling the PBIS Agent 146
Leave a Domain 146
Remove the Computer Account in Active Directory 147
Remove a Linux or Unix Computer from a Domain 147
Remove a Mac from a Domain 147
Remove a Mac from a Domain from the Command Line 148
Uninstall the Agent on a Linux or Unix Computer 148
Using a Shell Script to Uninstall 148
Using a Command to Uninstall 148
Uninstall the Agent on a Mac 148
Using Smart Cards with PBIS 150
Smart Card Setup 150
Supported Linux Platforms 150
Prepare Active Directory for Smart Card Logon 150

Prepare a Linux Computer for Smart Card Logon 151
Log on with a Smart Card 152
Smart Card Group Policy Settings 155
Managing PBIS Licenses 157
Create a License Container 160
Turn on Automatic Licensing 161
Import a License File 162
Assign a License to a Computer in AD 162
Manage a License Key from the Command Line 163
Check the License Key 163
Set a License Key 164
Release a License Key 164
Change the Type of License 165
Delete a License 165
Revoke a License 165
PBIS Reporting 166
Overview of the PBIS Reporting System 166
PBIS Data Collectors 166
Reporting Setup Preview 167
Requirements for the PBIS Reporting System 167
Configuring SQL Server 168
Install and Configure SQL Server 169
Create the LikewiseEnterprise Database 172
Install the PBIS Database Utilities 173
Planning SQL Server Database Security 174
Configuring MySQL 176
Create the LikewiseEnterprise Database 177
Install the PBIS Database Utilities 178
Customize Your MySQL Security Settings 179
Connecting the PBIS Console to the Database 180
Connect the PBIS Console to the Database 180
Verify That the Collector Processes Are Running 181
Run the Database Update Script 182
Run the Database Update Script from the Command Line 184
Configuring Computers to Forward Events to BTCollector 185
Configure Event Forwarding with Group Policy 186
Configure Event Forwarding with Local Settings 187
Cull Events from Syslog 187
Generate a Sample Report 188
Entitlement Reporting 189
Access Privileges by User 190
Access Privileges by Computer 190
Access Privilege Changes 190
Access Privilege Daily Changes 191

Account Attribute Inconsistencies 191
Monitoring Events with the Operations Dashboard 191
Start the Operations Dashboard 192
Connect to a Database 193
Change the Refresh Rate 193
Configuring the PBIS Data Collectors 193
Configuring BTCollector Using the Shell Prompt 194
Configuring BTEventDBReaper Using the Shell Prompt 196
Using the Enterprise Database Management Plug-in 198
Connect to a Database 199
Change the Parameters of the Collectors 199
Configure the ACL for RPC Access 200
Archiving Events 200
Archive Events with the Console 200
Archive Events with the Command Line 201
Monitoring Events with the Event Log 202
View the Local Event Log 203
Event Types 205
Event Sources 207
Event Source IDs 207
Single Sign-On Using PBIS 211
How PBIS Makes SSO Happen 211
How to Implement SSO with PBIS 212
Enable PAM for SSH 213
Configure PuTTY for Windows-Based SSO 215
Configure PuTTY 216
Configure the Base Linux Computer in Active Directory 216
Configure Apache for SSO 218
Prerequisites 219
Configure Apache HTTP Server 2.2 for SSO on RHEL 5 221
Control Group Access with mod_authz_unixgroup 225
Configure Firefox for SSO 225
Configure Internet Explorer for SSO 227
Examples 229
Command-Line Reference 230
Manage PBIS Services (lwsm) 230
Modify Settings (config) 231
Start the Registry Shell (regshell) 231
Export the Registry to an Editor (edit-reg) 232
Change the Host Name in the Local Provider (set-machine-name) 232
Find a User or a Group 232
Find a User by Name 232
Find a User by UID 233

Find a User by SID 234
Find a Group by Name 234
Find a Group by ID 234
List Groups for a User (list-groups-for-user) 235
List Groups (enum-groups) 235
List Users (enum-users) 235
List the Status of Authentication Providers (get-status) 236
List the Domain 237
List Domain Controllers (get-dc-list) 237
List Domain Controller Information (get-dc-name) 238
List Domain Controller Time (get-dc-time) 238
List Computer Account Information (lsa ad-get-machine) 238
Dynamically Update DNS (update-dns) 238
Manage the AD Cache (ad-cache) 239
On Mac OS X 240
Join or Leave a Domain (domainjoin-cli) 240
Display NIS Map (ypcat) 240
Display the Value of a Key in an NIS Map (ypmatch) 240
Modify Objects in AD (adtool) 241
Using the Tool 243
Options 245
Examples 246
Copy Files Across Disparate Operating Systems (lwio-copy) 249
Modify Local Accounts 249
Add a Local User (add-user) 250
Add a Local Group Member (add-group) 250
Remove a Local User (del-user) 250
Remove a Local Group (del-group) 250
Modify a Local User (mod-user) 250
Modify the Membership of a Local Group (mod-group) 251
Kerberos Commands 251
Destroy the Kerberos Ticket Cache (kdestroy) 251
View Kerberos Tickets (klist) 252
Obtain and Cache a TGT (kinit) 252
Change a Password (kpasswd) 253
The Keytab File Maintenance Utility (ktutil) 253
Acquire a Service Ticket and Print Key Version Number (kvno) 254
Manage PBIS Enterprise from the Windows Command Line (btopt.exe) 254
Configuring PBIS with the Registry 256
The Structure of the Registry 256
Data Types 257
Modify Settings with the config Tool 258
Example 1 258
Example 2 259
Example 3 260

Access the Registry 261
Change a Registry Value Using the Shell 262
Set Common Options with the Registry Shell 264
Change a Registry Value from the Command Line 265
Find a Registry Setting 266
lsass Settings 266
Log Level Value Entries 266
Turn on Event Logging 266
Turn off Network Event Logging 267
Restrict Logon Rights 267
Display an Error to Users Without Access Rights 268
Display a Message of the Day 268
Change the Domain Separator Character 269
Change Replacement Character for Spaces 269
Turn Off System Time Synchronization 270
Set the Default Domain 271
Set the Home Directory and Shell for Domain Users 271
Set the Umask for Home Directories 273
Set the Skeleton Directory 274
Force PBIS Enterprise to Work Without Cell Information 275
Refresh User Credentials 276
Turn Off K5Logon File Creation 277
Change the Duration of the Computer Password 277
Sign and Seal LDAP Traffic 278
NTLM Settings 279
Additional Subkeys 280
Add Domain Groups to Local Groups 281
Control Trust Enumeration 281
Modify Smart Card Settings 283
Set the Interval for Checking the Status of a Domain 283
Set the Interval for Caching an Unknown Domain 283
lsass Cache Settings 283
Set the Cache Type 284
Cap the Size of the Memory Cache 284
Change the Duration of Cached Credentials 285
Change NSS Membership and NSS Cache Settings 285
eventlog Settings 287
Allow Users and Groups to Delete Events 287
Allow Users and Groups to Read Events 288
Allow Users and Groups to Write Events 288
Set the Maximum Disk Size 288
Set the Maximum Number of Events 289
Set the Maximum Event Timespan 289
Change the Purge Interval 289
netlogon Settings 290
Set the Negative Cache Timeout 290

Set the Ping Again Timeout 291
Set the Writable Rediscovery Timeout 291
Set the Writable Timestamp Minimum Change 291
Set CLdap Options 292
lwio Settings 292
Sign Messages If Supported 292
Enable Security Signatures 293
Require Security Signatures 293
Set Support for SMB2 293
Lwedsplugin Settings for Mac Computers 294
IV. Troubleshooting 296
Troubleshooting Domain-Join Problems 297
Top 10 Reasons Domain-Join Fail 297
Generate a Domain-Join Log 298
Solve Domain-Join Problems 298
Verify that the Name Server Can Find the Domain 298
Make Sure the Client Can Reach the Domain Controller 298
Check DNS Connectivity 299
Make Sure nsswitch.conf Is Configured to Check DNS for Host Names 299
Ensure that DNS Queries Use the Correct Network Interface Card 299
Determine If DNS Server Is Configured to Return SRV Records 299
Make Sure that the Global Catalog Is Accessible 299
Verify that the Client Can Connect to the Domain on Port 123 300
FreeBSD: Run ldconfig If You Cannot Restart Computer 300
Ignore Inaccessible Trusts 300
Resolving Common Error Messages 302
Configuration of Krb5 302
Chkconfig Failed 302
Replication Issues 303
Diagnose NTP on Port 123 303
Output When There Is No NTP Service 304
Turn off Apache to Join a Domain 305
Troubleshooting the PBIS Agent 306
PBIS Services 306
Check the Status of the Authentication Service 307
Check the Status of the DCE/RPC Service 307
Check the Status of the Network Logon Service 308
Check the Status of the Input-Output Service 308
Restart the Authentication Service 308
Restart the DEC/RPC Service 309
Restart the Network Logon Service 309
Restart the Input-Output Service 309
Logging 310

Temporarily Change the Log Level and Target for a Service 312
Generate a Directory Service Log on a Mac 313
Generate a Network Trace 314
Basic Troubleshooting 314
Check the Version and Build Number 314
Determine a Computer's FQDN 315
Make Sure Outbound Ports Are Open 316
Check the File Permissions of nsswitch.conf 316
Configure SSH After Upgrading It 317
Upgrading an Operating System 317
Accounts 317
Allow Access to Account Attributes 317
User Settings Are Not Displayed in ADUC 318
Resolve an AD Alias Conflict with a Local Account 319
Fix the Shell and Home Directory Paths 320
Troubleshoot with the Get Status Command 321
Troubleshoot User Rights with Ldp.exe and Group Policy Modeling 322
Fix Selective Authentication in a Trusted Domain 326
Cache 327
Clear the Authentication Cache 327
Clear a Corrupted SQLite Cache 328
PAM 329
Dismiss the Network Credentials Required Message 329
Generate a PAM Debug Log 329
OS-Specific Troubleshooting 330
Red Hat and CentOS 330
Ubuntu 332
SUSE Linux Enterprise Desktop (SLED) 333
AIX 334
FreeBSD 334
Solaris 335
Mac OS X 336
Troubleshooting Logon Issues 338
Solve Logon Problems from Windows 338
Solve Logon Problems on Linux or Unix 339
Make Sure You Are Joined to the Domain 339
Check Whether You Are Using a Valid Logon Form 339
Clear the Cache 339
Destroy the Kerberos Cache 339
Check the Status of the PBIS Authentication Service 340
Check Communication between the PBIS Service and AD 340
Verify that PBIS Can Find a User in AD 340
Make Sure the AD Authentication Provider Is Running 341
Run the id Command to Check the User 342
Switch User to Check PAM 342

Test SSH 343
Run the Authentication Service in Debug Mode 343
Check Nsswitch.Conf 343
On HP-UX, Escape Special Characters at the Console 343
Additional Diagnostic Tools 343
Troubleshooting SSH SSO Problems 344
Use NT4-style Credentials and Escape the Slash Character 344
Perform General Logon Troubleshooting 344
Get an SSH Log 344
After an Upgrade, Reconfigure SSH for PBIS 345
Verify that Port 22 Is Open 345
Make Sure PAM Is Enabled for SSH 345
Make Sure GSSAPI Is Configured for SSH 347
Check the Configuration of SSH for SSO 347
Platform-Specific Issues 349
Troubleshooting Kerberos 356
Fix a Key Table Entry-Ticket Mismatch 356
Fix a KRB Error During SSO in a Disjoint Namespace 357
Eliminate Logon Delays When DNS Connectivity Is Poor 358
Eliminate Kerberos Ticket Renewal Dialog Box 359
Troubleshooting Single Sign-on and Kerberos Authentication 359
Troubleshooting the PBIS Database 364
Check the Endpoints 364
Check the Collector 366
Check the Database 368
Troubleshooting Checklists 369
Switching Between Databases 370
Contact Technical Support 373
Before Contacting Technical Support 373
Contacting Support 375

I. Preparing for PBIS Deployment
This section of the Installation and Administration Guide provides detailed
information on PBIS features, including:
Introduction to PBIS
PBIS Feature Review
Planning Your Installation and Deployment
PBIS Enterprise Installation and Administration I. Preparing for PBIS Deployment

Introduction to PBIS Enterprise
PowerBroker Identity Services Enterprise Edition connects Linux, Unix,
and Mac OS X computers to Microsoft Active Directory so you can centrally
manage all your computers and users from a single identity management
system.
This guide describes how to install and manage PowerBroker Identity
Services Enterprise Edition. The target audience is system administrators
who manage access to workstations, servers, and applications with Active
Directory.
The guide assumes that you know how to administer computers, users, and
Group Policy settings in Active Directory and that you know how to manage
computers running Unix, Linux, and Mac OS X.
PBIS Overview
PBIS Enterprise is installed on a Windows administrative workstation
connected to a domain controller so you can set user identifiers and group
identifiers in Active Directory Users and Computers. Once the UIDs and
GIDs are set, the PBIS agent uses the identifiers to authenticate users and
groups and to control access to computers and applications.
PBIS Enterprise includes additional features:
• Apply policy settings to Unix computers from the Microsoft Group
Policy Management Console (GPMC), including policy settings based on
the Gnome GConf project to define desktop and application preferences
for Linux computers.
• Integrates Apple's Workgroup Manager with the Group Policy
Management Editor (or Group Policy Object Editor) to apply managed
client settings to Mac OS X computers with Group Policy Objects
(GPOs).
• Generate a range of reports to help improve regulatory compliance. The
result: lower operating costs, better security, enhanced compliance.
• PBIS provides graphical tools to manage Linux and Unix information in
Active Directory. However, it can be useful to access and modify the
information programmatically. For this purpose, PBIS provides scripting
objects that can be used by any programming language that supports the
Microsoft Common Object Model, or COM. The scripting objects
provide dual interfaces that can be used by languages that use COM early
binding, such as C++ and C#, and by languages that use Idispatch, such
as VBScript and Jscript.
PBIS - Open Edition
PBIS Enterprise Installation and Administration Introduction to PBIS Enterprise

PBIS Open Edition is available as a free and open source version of
PowerBroker Identity Services. PBIS Open authenticates domain users with
the highly secure Kerberos 5 protocol by hashing their security identifiers
from Active Directory.
PBIS Open does not, however, process user identifiers or group identifiers
even if they are set in Active Directory. For more information, visit the
BeyondTrust website.
PBIS Components
There are two installation packages that you need to install PBIS:
• PBIS management tools for Active Directory, which you install on a
Windows computer that connects to an Active Directory domain
controller.
• PBIS agent, which you install on a Linux, Unix, or Mac computer to
connect it to Active Directory.
Component Function
Agent n Runs on a Linux, Unix, or Mac OS X computer to connect it to
Active Directory with the PBIS command-line interface or GUI.
See Join Active Directory from the Command Line. PBIS Open is
an open-source version of the agent that is available for free at
www.beyondtrust.com.
n Communicates with an Active Directory domain controller to
authenticate and authorize users and groups with the PBIS Identity
Service. See Log On with AD Credentials.
n Pulls and refreshes policy settings by using the Group Policy service,
which is included only with the PBIS Enterprise agent.
Enterprise
Console
n Runs on a Windows administrative workstation that connects to an
Active Directory domain controller to help manage Linux, Unix,
and Mac OS X computers in Active Directory.
n Migrates users, checks status, and generates reports.
MMC Snap-
Ins for
ADUC and
GPME
n Extends Active Directory Users and Computers to include Unix
and Linux users.
n With PBIS Enterprise, it also extends the Group Policy
Management Editor (or Group Policy Object Editor) and the
Group Policy Management Console (GPMC) to include Linux,
Unix, and Mac OS X Group Policy settings as well as a way to target
them at specific platforms.

Component Function
Cell Manager n A snap-in for the Microsoft Management Console to manage cells
associated with Active Directory Organizational Units.
Reporting
Database
n Stores security events and access logs for compliance reports.
Operations
Dashboard
n The PBIS Operations Dashboard is a management application, or
plug-in, for the BeyondTrust Management Console. The dashboard
retrieves information from the PBIS reporting database to display
authentication transactions, authorization requests, network events,
and other security events that take place on PBIS clients.
Task Road Map
To See
Set up and test a trial version of PBIS Enterprise in a
networked test environment.
PowerBroker Identity
Services Evaluation Guide
Install the BeyondTrust Management Console and the PBIS
management tools on a Windows workstation in a
production environment.
Install the Enterprise
Console
Determine the storage mode. Storage Modes
Find out how to use a container, known as a PowerBroker
cell, to manage PBIS clients and Unix settings in AD.
PowerBroker Cells
Create a cell in AD for Unix settings, such as a UID, so an
AD user can log on a PBIS client.
Create a Cell in AD
Provide AD users and groups with access to Linux, Unix,
and Mac computers.
Managing Users,
Groups, and Computers
Install the PBIS agent on a Linux, Unix, or Mac OS X
computer.
Install the Agent
Connect a computer running PBIS to Active Directory. Join Active Directory
from the Command Line
Troubleshoot problems joining a domain. Troubleshooting
Domain-Join Problems
Log on a PBIS client with an Active Directory user account. Log On with AD
Credentials
Troubleshoot logon problems. Troubleshooting Logon
Problems
Use Cell Manager to administer PowerBroker cells in AD. Administering Cells with
Cell Manager

To See
Apply Group Policy settings to Linux, Unix, and Mac
computers.
Services Group Policy
Administration Guide
Use Workgroup Manager to apply managed client settings
(MCX) to Mac computers as Group Policy Objects (GPOs).
Services Group Policy
Install the PBIS reporting and auditing components,
including the PBIS database.
Configuring the PBIS
Reporting System
Find information about PBIS commands and command-line
utilities for Linux, Unix, and Mac.
Command-Line
Reference
Change the local settings on a PBIS client. Configuring the PBIS
Agent
Monitor security events with the event log. Monitoring Events with
the Event Log
Configure PBIS clients for single sign-on. Using PBIS for Single
Sign-On
Migrate Unix or NIS users to Active Directory. Migrating Users to
Active Directory
Migrate a user profile on a Mac from a local user account to
the home directory specified for the user in Active
Directory.
Migrate a User Profile on
a Mac
Set up Samba to authenticate users with PBIS Enterprise. PowerBroker Identity
Services Samba Integration
Guide
Install and use PBIS Open. PBIS Open Installation and
View a list of documents for all PBIS products. Documentation Library

PBIS Feature Review
The following sections provide details on PBIS features.
PBIS Agent
The PowerBroker Identity Services (PBIS) agent is installed on a Linux,
Unix, or Mac OS X computer to connect it to Microsoft Active Directory
and to authenticate users with their domain credentials.
The agent integrates with the core operating system to implement the
mapping for any application, such as the logon process (/bin/login), that
uses the name service (NSS) or pluggable authentication module (PAM). As
such, the agent acts as a Kerberos 5 client for authentication and as an
LDAP client for authorization. In PBIS Enterprise, the agent also retrieves
Group Policy Objects (GPOs) to securely update local configurations, such
as the sudo file.
The following topics provide more information about the PBIS agent, also
known as the PBIS client software.
Services
Prior to PowerBroker Identity Services 6.5, the agent was composed of
separate daemon processes (with various dependencies between them), and
each was started in sequence by the operating systems at boot up. In
PowerBroker Identity Services 6.5, the daemons have been replaced by
libraries loaded by the service manager daemon (/opt/pbis/sbin/lwsmd).
Beginning in version 6.5, the service lsass replaces the daemon lsassd.
At boot time, the operating system is configured to start the service manager
daemon. It is then instructed by the operating system (with the command
/opt/pbis/bin/lwsm autostart) to start all desired services. The service
manager daemon keeps track of which services have already been started and
sees to it that all services are started and stopped in the appropriate order.
PBIS Enterprise Installation and Administration PBIS Feature Review

PBIS Open and PBIS Enterprise
Both the PBIS Open agent and the PBIS Enterprise agent are composed of
the service manager daemon (/opt/pbis/sbin/lwsmd) and include the
following services:
Service Description Dependencies
lsass Handles authentication, authorization,
caching, and idmap lookups. You can
check its status or restart it.
To view the Lsass architecture see the
diagram following the tables.
netlogon
lwio
rdr
lwreg
Usually eventlog (Can be
disabled after installation.)
Sometimes dcerpc (Can
be enabled after installation
for registering TCP/IP
endpoints of various
services.)
netlogon Detects the optimal domain controller
and global catalog and caches them.
lwreg
lwio An input-output service that is used to
communicate through DCE-RPC calls
to remote computers, such as during
domain join and user authentication.
lwreg
rdr A redirector that multiplexes
connections to remote systems.
lwio
lwreg
dcerpc Handles communication between
Linux, Unix, and Mac computers and
Microsoft Active Directory by mapping
data to end points. By default, it is
disabled.
eventlog Collects and processes data for the local
event log. Can be disabled.
lwreg The registry service that holds
configuration information both about
the services and information provided
by the services.
reapsysl The syslog reaper that scans the syslog
for events of interest and records them
in the eventlog.
eventlog
usermonitor The usermonitor service scans the
system for changes to users, groups,
and authorization rights and records the
changes in the eventlog.
lsass
eventlog

PBIS Enterprise Only
Additionally, PBIS Enterprise also includes the following services to apply
Group Policy settings, handle smart cards, and monitor security events:
Service Description Dependencies
gpagent Pulls Group Policy Objects (GPOs) from Active
Directory and applies them to the computer.
lsass
netlogon
lwio
rdr
lwreg
eventlog
eventfwd Forwards events from the local event log to a remote
computer.
eventlog
lwsc Smart card service. lwpkcs11
lwpkcs11 Aids lwsc by supporting PKCS#11 API.
Figure 1. LSASS Architecture

PBIS Input-Output Service
The lwio service multiplexes input and output by using SMB1 or SMB2.
The service's plugin-based architecture includes several drivers, the most
significant of which is coded as rdr—the redirector.
The redirector multiplexes CIFS/SMB connections to remote systems. For
instance, when two different processes on a local Linux computer need to
perform input-output operations on a remote system by using CIFS/SMB,
with either the same identity or different identities, the preferred method is
to use the APIs in the lwio client library, which routes the calls through the
redirector. In this example, the redirector maintains a single connection to
the remote system and multiplexes the traffic from each client by using
multiplex IDs.
The input-output service plays a key role in the PBIS architecture because
PBIS uses DCE/RPC (Distributed Computing Environment/Remote
Procedure Calls). DCE/RPC uses SMB: Thus, the DCE-RPC client libraries
use the PBIS input-output client library, which in turn makes calls to lwio
with Unix domain sockets.
When you join a domain, for example, PBIS uses DCE-RPC calls to
establish the machine password. The PBIS authentication service
periodically refreshes the machine password by using DCE-RPC calls.
Authentication of users and groups in Active Directory takes place with
Kerberos, not RPC.

The following data-flow diagram shows how systems interact when you join
a domain.
In addition, when a joined computer starts up, the PBIS authentication
service enumerates Active Directory trusts by using DCE-RPC calls that go
through the redirector. With one-way trusts, the authentication service uses
RPC to look up domain users, groups, and security identifiers. With two-way
trusts, lookup takes place through LDAP, not RPC.
Because the authentication service registers trusts only when it starts up,
you should restart lsass with the PBIS Service Manager after you modify a
trust relationship.

The PBIS Group Policy agent also uses the input-output client library and
the redirector when it copies files from the sysvol share of a domain
controller.
To troubleshoot remote procedure calls that go through the input-output
service and its redirector, use a Wireshark trace or a TCP dump to capture
the network traffic. Wireshark, a free open-source packet analyzer, is
recommended.
PAM Options
PowerBroker Identity Services uses three standard PAM options:
• try_first_pass
• use_first_pass
• use_authtok
Additionally, there are three non-standard options to the PAM configuration
on some systems:
• unknown_ok – Allows local users to continue down the stack (first line
succeeds but second line fails) while blocking domain users who do not
meet group membership requirements.
• remember_chpass – On AIX systems, which have both PAM and LAM
modules, the remember_chpass prevents the AIX computer from
trying to change the password twice and prompting the user twice.
• set_default_repository – On Solaris systems, the set_default_
repository option is used to make sure password changes work as
expected.
Managing the PBIS Services
Using the PBIS Service Manager, you can:
• Track and troubleshoot all the PBIS services with a single command-line
utility.
For example, check the status of the services, view their dependencies,
and start or stop them. The service manager is the preferred method for
restarting a service because it automatically identifies a service's
dependencies and restarts them in the correct order.
• Use the service manager to set the logging destination and the log level.
To list status of the services, run the following command with superuser
privileges at the command line:
/opt/pbis/bin/lwsm list
Example:

[root@bvt-rhe55-32s ~]# /opt/pbis/bin/lwsm list
lwreg running (container: 4916)
dcerpc stopped
eventfwd stopped
eventlog running (container: 4929)
gpagent stopped
lsass running (container: 4963)
lwio running (container: 4951)
lwpkcs11 stopped
lwsc stopped
netlogon running (container: 4941)
rdr running (io: 4951)
reapsysl running (container: 4978)
usermonitor stopped
[root@bvt-rhe55-32s ~]#
After you change a setting in the registry, you must use the service manager
to force the service to begin using the new configuration by executing the
following command with superuser privileges. This example refreshes the
lsass service:
/opt/pbis/bin/lwsm refresh lsass
PBIS Registry
Configuration information for the services is stored in the PBIS registry.
You can access and modify there registry using the registry shell or executing
registry commands at the command line.
The registry shell is at /opt/pbis/bin/regshell
For more information, see Configuring the PBIS Services with the Registry.
Ports and Libraries
The agent includes a number of libraries in /opt/pbis/lib and uses certain
ports for outbound traffic. For details about the ports, see Make Sure
Outbound Ports Are Open.
To view a data-flow diagram that shows how systems interact when you join
a domain, see PBIS Input-Output Service.
Caches and Databases
To maintain the current state and to improve performance, the PBIS
authentication service (lsass) caches information about users and groups in
memory.
You can change the cache to store the information in a SQLite database. For
more information, see lsass Cache Settings.

The PBIS site affinity service, netlogon, caches information about the
optimal domain controller and global catalog in the PBIS registry.
The following files are in /var/lib/pbis/db:
File Description
registry.db The SQLite 3.0 database in which the PBIS registry service,
lwreg, stores data.
sam.db Repository managed by the local authentication provider to
store information about local users and groups.
lwi_events.db The database in which the event logging service, eventlog,
records events.
lsass-
adcache.filedb.FQDN
Cache managed by the Active Directory authentication
provider to store user and group information. The file is in
/var/lib/pbis/db. In the name of the file, FQDN is
replaced by your fully qualified domain name.
Since the default UIDs that PBIS generates are large, the entries made by the
operating system in the lastlog file when AD users log in make the file
appear to increase to a large size. This is normal and should not cause
concern. The lastlog file (typically /var/log/lastlog) is a sparse file that
uses the UID and GID of the users as disk addresses to store the last login
information. Because it is a sparse file, the actual amount of storage used by
it is minimal.
With PBIS Open, you can manage the following settings for your cache by
editing the PBIS registry. See Cache Settings in the lsass Branch.
• The Cache Type
• The Size of the Memory Cache
• The Duration of Cached Credentials
• The NSS Membership and NSS Cache Settings
• The Interval for Caching an Unknown Domain
With PBIS Enterprise, you can manage the settings with Group Policy
settings; see the PowerBroker Identity Services Group Policy Administration Guide.
Additional information about a computer's Active Directory domain name,
machine account, site affinity, domain controllers, forest, the computer's
join state, and so forth is stored in the PBIS registry. Here is an example of
the kind of information that is stored under the Pstore key and the
netlogon key:
[HKEY_THIS_MACHINEServiceslsassParametersProviders
ActiveDirectoryDomainJoinEXAMPLE.COMPstore]

"ClientModifyTimestamp"=dword:4b86d9c6
"CreationTimestamp"=dword:4b86d9c6
"DomainDnsName"="EXAMPLE.COM"
"DomainName"="EXAMPLE"
"DomainSID"="S-1-5-21-3190566242-1409930201-3490955248"
"HostDnsDomain"="example.com"
"HostName"="RHEL5D"
"MachineAccount"="RHEL5D$"
"SchannelType"=dword:00000002
[HKEY_THIS_MACHINEServicesnetlogoncachedbexample.com-
0]
"DcInfo-ClientSiteName"="Default-First-Site-Name"
"DcInfo-DCSiteName"="Default-First-Site-Name"
"DcInfo-DnsForestName"="example.com"
"DcInfo-DomainControllerAddress"="192.168.92.20"
"DcInfo-DomainControllerAddressType"=dword:00000017
"DcInfo-DomainControllerName"="w2k3-r2.example.com"
"DcInfo-DomainGUID"=hex:71,c1,9e,b5,18,35,f3,45,ba,15,05,
95,fb,5b,62,e3
"DcInfo-Flags"=dword:000003fd
"DcInfo-FullyQualifiedDomainName"="example.com"
"DcInfo-LMToken"=dword:0000ffff
"DcInfo-NetBIOSDomainName"="EXAMPLE"
"DcInfo-NetBIOSHostName"="W2K3-R2"
"DcInfo-NTToken"=dword:0000ffff
"DcInfo-PingTime"=dword:00000006
"DcInfo-UserName"=""
"DcInfo-Version"=dword:00000005
"DnsDomainName"="example.com"
"IsBackoffToWritableDc"=dword:00000000
"LastDiscovered"=hex:c5,d9,86,4b,00,00,00,00
"LastPinged"=hex:1b,fe,86,4b,00,00,00,00
"QueryType"=dword:00000000
"SiteName"=""
Time Synchronization
For the PBIS agent to communicate over Kerberos with the domain
controller, the clock of the client must be within the domain controller's
maximum clock skew, which is 300 seconds, or 5 minutes, by default. (For
more information, see http://web.mit.edu/kerberos/krb5-1.4/krb5-
1.4.2/doc/krb5-admin/Clock-Skew.html.)
The clock skew tolerance is a server-side setting. When a client
communicates with a domain controller, it is the domain controller's
Kerberos key distribution center that determines the maximum clock skew.
Since changing the maximum clock skew in a client's krb5.conf file does
not affect the clock skew tolerance of the domain controller, the change will
not allow a client outside the domain controller's tolerance to communicate
with it.

The clock skew value that is set in the /etc/pbis/krb5.conf file of
Linux, Unix, and Mac OS X computers is useful only when the computer is
functioning as a server for other clients. In such cases, you can use a PBIS
Group Policy setting to change the maximum tolerance; for more
information, see Set the Maximum Tolerance for Kerberos Clock Skew in
the PowerBroker Identity Services Group Policy Administration Guide.
The domain controller uses the clock skew tolerance to prevent replay
attacks by keeping track of every authentication request within the
maximum clock skew. Authentication requests outside the maximum clock
skew are discarded. When the server receives an authentication request
within the clock skew, it checks the replay cache to make sure the request is
not a replay attack.
Using a Network Time Protocol Server
If you set the system time on your computer with a Network Time Protocol
(NTP) server, the time value of the NTP server and the time value of the
domain controller could exceed the maximum skew. As a result, you will be
unable to log on your computer.
If you use an NTP server with a cron job, there will be two processes trying
to synchronize the computer's time—causing a conflict that will change the
computer's clock back and forth between the time of the two sources.
It is recommended that you configure your domain controller to get its time
from the NTP server and configure the domain controller's clients to get
their time from the domain controller.
Automatic Detection of Offline Domain Controller and Global Catalog
The PBIS authentication service—lsass—manages site affinity for domain
controllers and global catalogs and caches the information with netlogon.
When a computer is joined to Active Directory, netlogon determines the
optimum domain controller and caches the information.
If the primary domain controller goes down, lsass automatically detects the
failure and switches to another domain controller and another global catalog
within a minute.
However, if another global catalog is unavailable within the forest, the PBIS
agent will be unable to find the Unix and Linux information of users and
groups. The PBIS agent must have access to the global catalog to function.
Therefore, it is a recommended that each forest has redundant domain
controllers and redundant global catalogs.

UID-GID Generation in PowerBroker Cells
In PBIS Enterprise, you can set the UIDs and GIDs that you want.
• Using PowerBroker cells, set multiple UID and GID values for a given
user based on OU membership. (PowerBroker cells, available only in
PBIS Enterprise, provide a method for mapping Active Directory users
and groups to UIDs and GIDs.)
• You can also set PBIS Enterprise to automatically generate UID and
GID values sequentially.
In PBIS Open, a UID and GID are generated by hashing the user or group's
security identifier (SID) from Active Directory. With PBIS Open, you do
not need to change Active Directory. A UID and GID stay the same across
host machines. With PBIS Open, you cannot set UIDs and GIDs for Linux
and Unix in Active Directory.
If your Active Directory relative identifiers (RIDs) are a number greater than
524,287, the PBIS Open algorithm that generates UIDs and GIDs can result
in UID-GID collisions among users and groups. In such cases, it is
recommended that you use PBIS Enterprise or the PBIS UID-GID
management tool.
The PBIS Open algorithm is the same in all versions of PBIS. If you are
running PBIS V5.x on one computer and V6.0 or later on another computer,
each user and group should have the same UID and GID on both
computers.
Note: If you have UIDs and GIDs defined in Active Directory, PBIS
Open will not use those UIDs and GIDs.
Cached Credentials
Both PBIS Open and PBIS Enterprise cache credentials so users can log on
when the computer is disconnected from the network or Active Directory is
unavailable.
Trust Support
The PBIS agent supports the following Active Directory trusts:
Trust
Type Transitivity Direction
PBIS Default Cell
Support
PBIS Non-Default Cell
Support (Named Cells)
Parent
and child
Transitive Two-way Yes Yes
External Nontransitive One-way No Yes

Trust
Type Transitivity Direction
PBIS Default Cell
Support
PBIS Non-Default Cell
Support (Named Cells)
External Nontransitive Two-way No Yes
Forest Transitive One-way No Yes
Forest Transitive Two-way Yes: Must enable
default cell in both
forests.
Yes
There is information on the types of trusts at
http://technet.microsoft.com/en-us/library/cc775736(WS.10).aspx.
Notes on Trusts
The following is general information about working with trusts.
• You must place the user or group that you want to give access to the
trust in a cell other than the default cell.
• In a two-way forest or parent-child trust, PBIS merges the default cells.
When merged, users in one domain can log on computers in another
domain, and vice-versa.
• To put a user in a child domain but not the parent domain, you must put
the user in a non-default cell, which is a cell associated with an
organizational unit.
• If there is a UID conflict across two domains, one domain will be
dropped.
• In a cross-forest transitive one- or two-way trust, the root of the trusted
forest must have a default cell.
• In a one-way trust in which Forest A trusts Forest B, a computer in
Forest A cannot get group information from Forest B, because Forest B
does not trust Forest A. The computer in Forest A can obtain group
information if the user logs on with a password for a domain user, but
not if the user logs on with Kerberos single sign-on credentials. Only the
primary group information, not the secondary group information, is
obtained.

• To support a 1-way trust without duplicating user accounts, you must
use a cell associated with an OU, not a default cell. If Domain A trusts
Domain B (but not the reverse) and if Domain B contains all the account
information in cells associated with OUs, then when a user from Domain
B logs on a machine joined to Domain A, Domain B will authenticate
the user and authorize access to the machine in Domain A.
In such a scenario, you should also add a domain user from the trusted
domain to an administrative group in the trusting domain so you can
manage the trusting domain with the appropriate level of read access to
trusted user and group information. However, before you add the
domain user from the trusted domain to the trusting domain, you must
first add to the trusting domain a group that includes the user because
Unix and Linux computers require membership in at least one group and
Active Directory does not enumerate a user's membership in foreign
groups.
• If you have a network topology in which the "front" domain trusts the
"back" domain, and you join a machine to the front domain using a back
domain administrator, as in the following example, the attempt to join
the domain will fail: domainjoin-cli join front.example.com
backadministrator password. However, the attempt to join the
domain will succeed if you use the following nomenclature:
domainjoin-cli join front.example.com
administrator@BACK.example.COM password
• With PBIS Enterprise, aliased user names are supported in the default
cell and in named cells.
Trusts and Cells in PBIS Enterprise
In PBIS Enterprise, a cell contains Unix settings, such as a UID and a GID,
for an Active Directory user. When an AD user logs on a PBIS client, PBIS
Enterprise searches Active Directory for the user's cell information—and
must find it to operate properly. Thus, your AD topology and your trust
relationships may dictate where to locate a cell in Active Directory so that
your PBIS clients can access their Unix settings.
With a default cell, PBIS searches for a user or group's attributes in the
default cell of the domain where the user or group resides. In a multi-domain
topology, a default cell must exist in the domain where user and group
objects reside in addition to the default cell that exists in the domain to
which Unix, Linux, and Mac computers are joined. In a multi-domain
topology, then, be sure to create a default cell in each domain.

Ideally, Unix information is stored on the user object in default cell
Directory Integrated mode. If the client computer does not have the access
rights to read and write the information to the user object, as in an external
one-way trust, the Unix information cannot be stored on the user object. It
can, however, be stored locally in a named cell, that is, a cell associated with
an organizational unit.
Since a named cell can be linked to the default cell, you can store Unix
information on the user object in default cell Directory Integrated mode
when possible, and otherwise in a named cell that represents the external
user. For information about cells, see the chapter on planning your PBIS
Enterprise installation and deployment.
Integrating with Samba
PowerBroker Identity Services includes a tool to install the files necessary to
use Samba with PBIS. Located in /opt/pbis/bin, the tool is named
samba-interop-install. The PowerBroker Identity Services Samba Guide
describes how to use the tool to integrate Samba 3.0.25, 3.2.X, or 3.5.X
with PBIS Enterprise or PBIS Open.
Supported Platforms
PBIS Open and PBIS Enterprise run on a broad range of Unix, Mac OS X,
and Linux platforms. BeyondTrust frequently adds new vendors and
distributions. See the BeyondTrust website for the list of supported
platforms.
SELinux Support
The PBIS SELinux implementation supports the following operating
systems:
• Fedora 13—Fedora 17
• RedHat Enterprise Linux version 6
When you install any of these versions, PBIS policies are installed
(regardless if SELinux is enabled).
All versions of the policy and the source for the policy are available on the
workstation after the PBIS RPM is installed.
Appropriate versions of the policy are determined by the logic in the RPM
package.

Unsupported Operating Systems
If SELinux is enabled and you are installing to an unsupported operating
system (for example, Fedora 12 or Fedora 25), the installation is stopped.
You must place SELinux in permissive mode to continue.
• SELinux enabled is only detected with the RPM package.
• SELinux enabled is not detected with the self-extracting installer or
domainjoin.
Storage Modes
PBIS has two operating modes: Directory Integrated mode and Schemaless
mode.
The modes provide a method for storing Unix and Linux information in
Active Directory—including UIDs and GIDs—so that PBIS can map SIDs
to UIDs and GIDs and vice versa.
The mapping lets PBIS use an Active Directory user account to grant a user
access to a Unix or Linux resource that is governed by a UID-GID scheme.
When an AD user logs on a Unix or Linux computer, the PBIS agent
communicates with the Active Directory Domain Controller through
standard LDAP protocols to obtain the following authorization data:
• UID
• Primary GID
• Secondary GIDs
• Home directory
• Login shell
PBIS uses this information to control the user's access to Unix and Linux
resources.
Directory Integrated Mode
Directory Integrated mode takes advantage of the Unix- and Linux-specific
RFC 2307 object classes and attributes to store Linux and Unix user and
group information, namely the posixAccount and posixGroup object
classes.
For example, the posixAccount and posixGroup object classes include
attributes—uidNumber and gidNumber—that PBIS uses for UID and GID
mapping. In addition, PBIS uses serviceConnectionPoint objects to
store the same information as in Schemaless by using the keywords
attribute.

For example, when you create a cell in Directory Integrated mode, PBIS
creates a container object—CN=$LikewiseIdentityCell—in the domain
root, or in the OU where you created the cell. If the container is created in
an OU, which is called a named or non-default cell, the Unix-specific data is
stored in CN=Users and CN=Groups in the $LikewiseIdentityCell
container object. The objects point to the Active Directory user or group
information with a backlinked security identifier.
If the container is created at the level of the root domain, it is known as a
default cell. In this case, the Unix-specific data is stored directly in the AD
user or group account.
Upgrading Your Schema
You must upgrade your schema if your schema does not comply with RFC
2307. The PBIS Directory Integrated Mode Wizard, which is a tool in the
console, can automatically upgrade your schema to comply with RFC 2307.
(Windows Server 2003 R2 or later complies with RFC 2307.)
When you use Directory Integrated mode with a schema that already
complies with RFC 2307, PBIS does not change the schema, but you still
must run the Directory Integrated Mode Wizard to include the RFC 2307
attributes in the global catalog and to index them for faster searches.
For more information, see Run the Directory Integrated Mode Wizard.
Schemaless Mode
In contrast, Schemaless mode stores Linux and Unix data without requiring
RFC 2307 object classes and attributes and without modifying the schema.
Instead, Schemaless mode uses existing object classes and attributes to store
its data.
• To store information about a cell, PBIS creates a container object and
stores data in its description attribute.
• To store information about a group or user, PBIS creates a
serviceConnectionPoint object and stores data in its keywords
attribute. Both keywords and description are multi-valued attributes
that can have multiple values while still allowing AD searches for
specific values.
In Schemaless mode, PBIS uses RFC 2307 attribute names to store values in
the keywords and description attributes in the form name=value, where
name is the attribute name and value is its value. Here is an example of how
the keywords attribute name-value pairs can contain Unix and Linux
information for an AD user:

uid=
uidNumber=1016
gidNumber=100000
loginShell=/bin/bash
unixHomeDirectory=/home/joe
gecos=
backlink=[securityIdentifierOfUser]
objectClass=CenterisLikewiseUser
In the example, the uid attribute is empty. It is needed only when you want
to specify a name alias so that the AD user can log on a computer with
something other than his or her AD account name.
In ADSI Edit, the properties for a user look like this:
The keywords attribute is also used to store Linux and Unix group
information. Here is an example of how the attribute name-value pairs can
contain Unix and Linux information for a group:
backLink=[securityIdentifierOfGroup]description=
displayName=gidNumber=100000objectClass=centerisPBISGroup
When you set an alias for a group, it is stored in the displayName attribute
(for the group in the example above, no alias has been set, and thus
displayName is empty).
In ADSI Edit, the values of the keywords attribute look like this:

Key Differences
The following table summarizes the differences between modes:
Mode Use Case Storage Method
Schemaless
mode
AD installations that have not
migrated to the latest AD schema;
administrators are reluctant or
unwilling to change the schema.
AD installations that use Windows
2000 domain controllers.
PBIS uses the description
and the keywords attributes of
container and
serviceConnectionPoint
objects to store Unix and Linux
information for users, groups,
and cells.
Directory
Integrated
mode
AD installations that comply with
RFC 2307, such as Windows
Server 2003 R2 or later. Or,
administrators who are willing to
change the schema to RFC 2307
and to raise the forest functional
level to Windows Server 2003.
AD installations that do not use
Windows 2000 domain
controllers.
PBIS uses the Unix- and Linux-
specific attributes that are built
into the RFC 2307 schema as
well as the container object
and the keywords attribute.

Pros and Cons of the Modes
Review the following sections on advantages and disadvantages of the
modes.
Schemaless Mode: Advantages and Disadvantages
The benefit of using schemaless mode is that it does not require you to
upgrade the Active Directory schema. This may be preferable in an
environment that places special controls around how Active Directory is
managed. This mode is sufficient for use in small deployments, such as a
single server or workstation that will be added to a single domain controller.
Advantages of schemaless mode include the following:
• Supports Windows 2000 domain controllers.
• Does not change the current schema. PBIS objects are contained in their
own serviceConnectionPoints.
• Does not affect settings in a global manner.
• Does not affect other Unix schema extensions that may be in place.
A disadvantage of schemaless mode is that if you're using third-party
software to manipulate AD objects, it will not recognize how PBIS stores
data in Active Directory.
Directory Integrated Mode: Advantages and Disadvantages
Directory Integrated mode raises the version of the schema to match that of
Windows Server 2003 R2—the schema extensions are added to comply with
the standard defined in RFC 2307. These changes are prescribed by
Microsoft and are built into Windows Server 2003 R2.
Advantages of Directory Integrated mode include the following:
• Uses indexed searching, which makes lookups faster when there are a
large number of UID-GID mappings to process.
• Improves compatibility with other tools.
• Enhances ADSI scripting capabilities.
Drawbacks of Directory Integrated mode include the following:
• Significantly modifies the Active Directory schema in cases where it
must be upgraded to RFC 2307. If you are already using the RFC 2307-
compliant schema, the schema adds the uid, uidNumber, and
gidNumber attributes to the global catalog, which could marginally
increase the size of the catalog and might marginally affect performance
in a large Active Directory implementation.

• Requires you to raise the forest functional level to at least Windows
Server 2003.
Important: If you upgrade your schema to RFC 2307, you cannot roll
back the changes.
• Cannot use Directory Integrated mode if you have Windows 2000
domain controllers; you must first upgrade them to at least Windows
Server 2003. See http://support.microsoft.com/kb/322692
There is background information about functional levels at
http://technet.microsoft.com/en-us/library/cc738038.aspx and reference
information about functional level features at
http://technet.microsoft.com/en-us/library/understanding-active-
directory-functional-levels(WS.10).aspx.
PowerBroker Cells
A PowerBroker cell is a container of Unix settings for Active Directory
users and groups so they can log on to Linux, Unix, and Mac OS X
computers.
Review the details in this section to learn more about how cells work. For
more information about creating and managing cells, see Working with Cells.

You can use cells to map a user to different UIDs and GIDs for different
computers. In the following screen shot, the example user, Bala, is allowed
to access the computers that are in the selected cells:
Types of Cells
There are two types of PowerBroker cells:
• Default cell – A cell associated with a domain or an entire enterprise. In
a multi-domain topology, you create a default cell in each domain, and
these domain-specific default cells merge into an enterprise-wide default
cell.
• Named cell – A cell associated with an organizational unit (OU).
Associating cells with OUs is a natural way to organize computers and
users.

PBIS lets you define a default cell that handles mapping for computers that
are not in an OU with an associated named cell. The default cell for the
domain can contain the mapping information for all your Linux and Unix
computers. If you are using Directory Integrated mode, various attributes are
indexed in the global catalog by using the default cell.
In a multi-domain or multi-forest enterprise, the default cells of the domains
merge into a single enterprise-wide default cell where users from each
domain can authenticate with their credentials. Users' UID, GID, and other
settings are defined separately in each domain, but nothing additional is
needed at the domain-level to enable the user to authenticate.
Each forest that has a two-way transitive forest trust with the computer's
forest is listed in the default cell. Each domain in each forest can opt in to
this enterprise-wide default cell by creating a default cell in that domain. Any
user who is listed in the default cell in a domain can be seen by the PBIS-
enabled operating system of any computer joined to the default cell.
How Cells Are Processed
• PBIS searches Active Directory for cell information
When an Active Directory user logs on to a PBIS client computer, the
PBIS agent searches Active Directory for the user's PowerBroker cell
information.
The search typically begins at the node where the computer is joined to
Active Directory and can extend to all forests that have a two-way
transitive trust with the client computer's forest.
• PBIS agent checks the cell type
The PBIS agent determines the OU where the computer is a member
and checks whether a named cell is associated with it.
• PBIS agent continues search if no cell found for the OU
If a cell is not associated with the OU, the PBIS agent on the Unix or
Linux computer moves up the directory structure, searching the parent
and grandparent OUs until it finds an OU that has a PowerBroker cell
associated with it.
• Named cell found
If a named cell is found, PBIS searches for a user or group's attributes in
the cell associated with the computer.
If an OU with an associated cell is not found, the PBIS agent uses the
default cell for the domain to map the username to UID and GID
information.

Default Cell Processing
A default cell is processed differently than a named cell. When processing a
default cell, PBIS searches for a user or group's attributes in the default cell
of the domain where the user or group resides. For example, a two-domain
topology configured with one domain for users and another domain for
computers would require two default cells—one default cell in the domain
where user and group objects reside, and another default cell in the domain
where computer objects are joined.
A Linux or Unix computer can be a member of an OU that does not have a
cell associated with it. In such a case, the Group Policy Objects (GPOs)
associated with the OU apply to the Linux or Unix computer, but user UID
and GID mappings follow the policy of the nearest parent cell or the default
cell.
PBIS does not require you to have a default cell, but for PBIS to operate
properly you must ensure that the PBIS agent can always find a cell. For
more information, see Best Practices for Modes, Cells, and User Rights.
Cell Design
PowerBroker cell technology allows managing overlapping Unix identities in
a single Active Directory organization for PBIS Enterprise. Cells work in
Directory Integrated or Schemaless mode.
Storing Unix Identities
Cells store Unix identity information separate from other cells. This allows a
single user or group to have different names or different numerical ID values
(UID or GID) in different environments, all associated with the same AD
identity.
This also allows multiple users or groups to have overlapping names or
numerical ID values (UID or GID) in separate environments. Each cell
requires additional overhead for the standard procedure for account
management and for troubleshooting end-user logon issues, because both
cases require the additional step of determining which cell the operation
must be performed against.
To minimize complexity while allowing the flexibility of cells, it is
recommended that you use no more than four cells.
Named Cells
Named Cells store Unix identity information (uid, uidNumber, gidNumber,
gecos, unixHomeDirectory, logonShell) in a subcontainer of the
organizational unit (OU) which is associated with the cell.

Whether a user exists in the local domain or a trusted domain, the Unix
identity information exists in an object in the cell. In other words, a Named
Cell can reference users or groups from outside the current AD domain.
Default Cells
Default Cell mode refers to how an AD domain is set up. There is one
Default Cell, and it is enterprise-wide. All trusted Microsoft Active
Directory Global Catalogs are part of the Default Cell. However, individual
AD domains participate in the Default Cell by creating the Default Cell
object in the root of those domains.
In Default Cell mode, the Unix identity information is stored in the same
OU as the user object that the Unix Identity information is related to. This
enforces a single Unix identity for a single AD user across the entire
enterprise. Therefore, the Default Cell should be viewed as the ultimate
authority for Unix information within an enterprise.
Directory Integrated Mode - Default Cell Configurations
In Directory Integrated mode, the Default Cell stores the Unix identity
information directly to the user or group object in the same manner as “First
Name” (givenName), “Address” (address, city, state), and “Email”
(emailAddress) attributes.
Because the Directory Integrated Mode - Default Cell stores the information
to the user or group object, existing Identity Management (IDM) products
do not need to be modified to provision users for the Default Cell in
Directory Integrated Mode. This also allows non-PBIS computers that use
the RFC2307 attributes (such as Network Appliances ONTAPP Filers and
EMC Celerra storage devices) to use the same identity information as PBIS
Enterprise.
Directory Integrated Mode - Default Cell is the preferred method for all
PBIS Enterprise installations. In all cases where Unix identity information
can be made to be non-overlapping, the Directory Integrated Mode - Default
Cell should be used.
Directory Integrated Mode - Named Cell Configurations
In Directory Integrated mode, Named Cells create objects of class
PosixAccount and serviceConnectionPoint, which are linked back to the
user or group object associated with the PBIS object.
Directory Integrated Mode - Named Cells are recommended wherever
multiple cells beyond the Default Cell are required.
Schemaless Mode Cells
Schemaless mode is deprecated but fully supported.

The PBIS clients determine cell and Schema configuration at startup and re-
check this configuration periodically. Because of how the data is stored,
migration from a Schemaless Default Cell to a Directory Integrated Mode -
Default Cell configuration requires more work, more steps, and more
potential risks than any other cell migration.
For migration and long-term support purposes, Schemaless Mode Cells
should only be created as Named Cells.
Note: Directory Integrated mode is preferred for the performance benefits
and because Microsoft Active Directory is moving towards Directory
Integrated Mode by default.
Using Multiple Cells
If you have multiple Unix and Linux computers but are not using a
centralized scheme to manage UIDs and GIDs, it is likely that each
computer has unique UID-GID mappings. You may also have more than one
centralized IMS, such as multiple NIS domains. You can use multiple cells
to represent the UID-GID associations that the NIS domain provided,
allowing those Unix and Linux users to continue to use their existing UID-
GID information while using Active Directory credentials.
When using multiple cells, it can be helpful to identify what Unix and Linux
objects each cell represents. For example:
• Individual Unix, Linux, or Mac OS X computers
• A single NIS domain
• Multiple NIS domains (which require multiple cells)
Linking Cells
To provide a mechanism for inheritance and to ease system management,
PowerBroker Identity Services can link cells. Users and groups in a linked
cell can access resources in the target cell.
For example, if your default cell contains 100 system administrators and you
want those administrators to have access to another cell, called Engineering,
you do not need to provision those users in the Engineering cell—Link the
Engineering cell to the default cell. The Engineering cell will inherit the
settings of the default cell.
To ease management, in the Engineering cell you can set any mapping
information that should differ from the default cell.
Although you can use linking to create a hierarchy of cells, linking is not
transitive.
For example, consider the following linked cells:
- Civil cell linked to Engineering cell

- Engineering cell linked to Default cell
In this scenario, the Civil cell will not inherit the settings of the default cell.
Linking to Multiple Cells
The order of the UIDs controls the search order.
Consider the following scenario:
Kathy, a system administrator, has UIDs set in the default cell (100,000) and
in the Engineering cell (150,000). In the Civil cell, however, the UID from
the Engineering cell must be used to log on to Civil computers.
If the Civil cell is linked to the default cell and the Engineering cell, the
order is important. If Engineering does not precede the default cell in the
search order, Kathy will be assigned the wrong UID and will be unable to
log on computers in the Civil cell.
For information about how to link cells, see Link Cells.
Managing Cells with Cell Manager
PBIS Enterprise includes Cell Manager, a Microsoft Management Console
(MMC) snap-in for managing PowerBroker cells associated with Active
Directory organizational units.
Using Cell Manager, you can view all of your cells in one place. Cell Manager
complements Active Directory Users and Computers by letting you delegate
management of a cell.
Cell Manager is automatically installed when you install the BeyondTrust
Management Console. For more information, see Manage Cells.
Migrating Users to Active Directory
The BeyondTrust Management Console includes a migration tool to import
Linux, Unix, and Mac OS X, passwd and group files—typically
/etc/passwd and /etc/group—and automatically map their UIDs and
GIDs to users and groups defined in Active Directory. The migration tool
can also generate a Windows automation script to associate the Unix and
Linux UIDs and GIDs with Active Directory users and groups. For more
information, see Migrate Users to Active Directory.
Migrating NIS Domains
If you use PBIS to migrate all your Unix and Linux users to Active
Directory, in most cases you will assign these users a UID and GID that is
consistent across all the Unix and Linux computers that are joined to Active
Directory—a simple approach that reduces administrative overhead.

In cases when multiple NIS domains are in use and you want to eliminate
these domains over time and migrate all users and computers to Active
Directory, mapping an Active Directory user to a single UID and GID might
be too difficult. When multiple NIS domains are in place, a user typically has
different UID-GID maps in each NIS domain. With PBIS, you can eliminate
these NIS domains but retain the different NIS mapping information in
Active Directory because PBIS lets you use a cell to map a user to different
UIDs and GIDs depending on the Unix or Linux computer that they are
accessing.
To move to Active Directory when you have multiple NIS servers, you can
create an OU (or choose an existing OU) and join to the OU all the Unix
computers that are connected to the NIS server. You can then use cells to
represent users' UID-GID mapping from the previous identity management
system.
Finding Orphaned Objects
The BeyondTrust Management Console includes a tool for finding and
removing orphaned objects. An orphaned object is a linked object, such as a
Unix or Linux UID or GID, that remains in a cell after you delete a group or
user's security identifier (SID), from an Active Directory domain. Removing
orphaned objects from Active Directory can clean up manually assigned
UIDs and improve search speed. For more information, see Find Orphaned
Objects.

Planning Your Installation and Deployment
Installation and Provisioning Overview
The installation and deployment process typically proceeds as follows:
1. Make sure your computers meet the installation requirements and then
obtain the PowerBroker Identity Services software package from
www.beyondtrust.com.
2. Plan your installation, test environment, and production deployment.
Make decisions about whether to use PBIS in directory integrated mode
or schemaless mode; whether to manage a single forest or multiple
forests and to assign UID-GID ranges accordingly; how to configure a
PowerBroker cell topology for your unique needs; whether to migrate
NIS users and what to do with local user accounts after migration; and
whether to use specific cells for aliasing.
3. Before you install the BeyondTrust Management Console, check Active
Directory to make sure it is ready for PBIS by meeting our remediation
requirements.
4. Install the BeyondTrust Management Console, which includes
management tools, on a Windows administrative workstation that you
use to manage Active Directory.
5. Optionally, install a reporting database on a Windows administrative
workstation connected to a domain controller. The reporting database,
which can be either MySQL or SQL Server, stores access information
and security events for compliance reports.
6. Use a PBIS wizard to configure your Active Directory domain in either
Directory Integrated or Schemaless mode.
7. Configure a cell topology in Active Directory Users and Computers.
8. Optionally use the console's migration tool to migrate Unix and Linux
users and groups to Active Directory.
9. Check the system health, or readiness, of your Linux, Unix, and Mac
computers before installing the PBIS agent. For example, you must make
sure resolv.conf is configured for PBIS.
10. Install the PBIS agent on each Unix, Linux, or Mac OS X computer that
you want to join to the Active Directory domain.
11. Join your Unix and Linux computers to an Active Directory domain.
12. Optional. Plan and deploy Group Policy settings to manage your Unix,
Linux, and Mac OS X computers in Active Directory.
13. Troubleshoot any deployment issues and optimize the deployment for
your unique mixed network.
PBIS Enterprise Installation and Administration Planning Your Installation and Deployment

Planning Your Deployment
The key to a successful deployment is planning. Before you begin deploying
PBIS in an enterprise, develop a plan that addresses at least the following
aspects of installation and deployment:
• Set up a test environment. It is recommended that you first deploy PBIS
in a test environment so that you can identify and resolve any issues
specific to your mixed network before you put the system into
production.
• Determine whether to use PBIS in Directory Integration or Schemaless
mode. When you configure your domain with the PBIS domain
configuration wizard, you must choose the mode to use.
Important: Back up Active Directory before you run the PBIS domain
configuration wizard.
• Decide whether to configure PBIS to manage a single forest or multiple
forests. If you manage multiple forests, the UID-GID range assigned to a
forest should not overlap with the range of another forest.
• Determine how you will migrate Linux, Unix, and Mac OS X users to
Active Directory. For example, if you are using NIS, decide whether you
will migrate those accounts to Active Directory and whether you will
migrate local accounts and then delete them or leave them. It is usually
recommended that you delete interactive local accounts other than the
root account.
• Identify the structure of the organizational units—or cell topology—that
you will need, including the UID-GID ranges. If you have multiple NIS
servers in place, your users may have different UID-GID maps in each
NIS domain. You may want to eliminate the NIS servers but retain the
NIS mapping information in Active Directory. To do so, you can use
PowerBroker cells.
• Determine whether you will use aliasing. If you plan to use aliasing, you
must associate users with a specific PowerBroker cell; you cannot use
the default cell.

Best Practices for Modes, Cells, and User Rights
In general, the optimal setup is a Directory Integrated Mode - Default Cell
configuration.
Keep the following in mind when considering mode type:
• When Unix identity information does not overlap, use a Directory
Integrated Mode - Default Cell configuration.
• If you require multiple cells to keep Unix identities from conflicting, use
a Directory Integrated Mode - Named Cells configuration.
Number of Cells
• Try to minimize the number of Named Cells you use, preferably no more
than four.
Storage Mode
• Directory Integrated Mode is strongly preferred because lookups use
attributes indexed in Active Directory, reducing network traffic and the
processing load on domain controllers.
• Because of the performance benefits of Directory Integrated Mode,
avoid Schemaless Mode whenever you can. Schemaless mode, however,
remains fully supported by PBIS.
Migrating Cells
Migrating from a Schemaless - Default Cell configuration to a Directory
Integrated Mode - Default Cell configuration requires more work and is
riskier than any other kind of cell migration.
To ease migration in the future and to improve support, create Schemaless
mode cells as Named Cells only—that is, cells associated with OUs.
User Rights
Cells are designed only as a method to manage conflicting Unix identities in
an environment.
Use the PBIS settings to manage access:
• "RequireMembershipOf" registry setting
• "Allow Logon Rights" GPO setting

It is strongly recommended that cells not be used for access control
(authorization). While technically, a cell can be used to limit end-user access
to a computer, this is against the design of Active Directory, which allows all
users to be "seen" by any joined client, but limits authorization based on
other methods.
Pre-stage Unix Computer Accounts
Because PBIS joins the Unix computers to AD with the same API calls as
Microsoft Windows uses, the same rights as Windows administrators are
required in AD for Unix administrators to join a domain.
Consider pre-staging Unix computer accounts or delegating to Unix system
administrators control of the OU where the Unix computers will be joined.
For information on how to delegate control, see Best Practices for
Delegating Active Directory Administration.
For information on how to pre-create computer accounts, see Domain Users
Cannot Join Workstation or Server to a Domain.
In addition to the recommendations in that article, it is recommended that
you delegate read and write access to the following attributes: Operating
System, Operating System Version, operatingSystemServicePack,
operatingSystemHotFix.
Best Practices for Windows
PowerBroker Identity Services Enterprise Edition supports Windows and
Windows Server.
The following topics recommend best practices for using PBIS Enterprise in
Windows and Windows Server environments.
PBIS Enterprise Tools Best Practices
The PBIS Enterprise Tools can be installed on either 32-bit or 64-bit
Windows or Windows Server operating systems.
• Install PBIS on a management workstation. Domain controllers are not
recommended.
• Installing PBIS on a management workstation or on several management
workstations is recommended.
PBIS authentication architecture installs no services that need to run on
a Windows Server. Because of this, administrators can keep Domain
Controllers free of non-Microsoft software, and they can maintain these
servers with no special considerations for PBIS client computers.

Follow Microsoft Best Practices for Group Policy administration when
working with GPOs and PBIS Enterprise (available at
http://www.microsoft.com/downloads/details.aspx?FamilyID=237b03af-
fa8c-4362-8b03-90c47b9b8be2&DisplayLang=en). For more information
about Group Policy, see http://www.microsoft.com/gp.
Installation on 64-bit Windows Management Workstations is supported, but
requires special considerations for running tools such as Group Policy
Management Console (GPMC) or Active Directory Users and Computers
(ADUC).
Active Directory Best Practices
PowerBroker cells provide a means of directly managing Unix identities in
Active Directory. PBIS Open does not use cells, but cell support can be
purchased. The recommended best practice is to use cells rather than
Unprovisioned mode wherever possible.
Reporting Tools Best Practices
PBIS Reporting requires a SQL database and services to collect and forward
data.
Database
PBIS Reporting requires a SQL database called the PBIS Enterprise
Database (EDB) which can be either MySQL or Microsoft SQL (MSSQL).
MSSQL is the preferred database platform for PBIS reporting for the
following reasons:
• Fully integrates with AD. Database ownership and rights can be set
directly for AD users.
• Supports Integrated Security (which does not require
username/password combinations in connection strings).
• MySQL does not support PBIS entitlement reporting.
Database Growth
PBIS Reporting uses approximately 1MB of space in the EDB for every
1000 records logged.
Best practice for environments with a lot of audit data being captured is to
size the database to grow 2MB per PBIS Enterprise agent per day. Most
environments will only grow 1MB per PBIS agent per day.

Collector Services
PBIS Reporting requires Windows platforms to run the Collector server and
Enterprise Database Forwarder. These are the only Windows services that
PBIS requires.
Best practice for network design and WAN traffic management is to place
the Collector servers closer to the PBIS agents.
To support auditing in case of a Collector failure, the PBIS agents only need
to be pointed to a different collector. To support this situation, it is
recommended that you build a number of Collector servers equal to or
greater than the following formula:
Total Collectors = ((number of PBIS agents) / 400) + 1
Each Collector server will need local storage for the Collector database equal
to 10MB per PBIS agent.
User Monitor for Entitlement Reports
PBIS Enterprise includes a User Monitor service for entitlement reports.
This feature is designed to support computers that are critical to regulatory
compliance and for which restricted access by only essential staff is vital. A
computer that is openly accessible to hundreds of users would be a source of
unnecessary audit activity in such a situation and would significantly increase
resource requirements, such as for Auditing Database sizing.
PBIS Enterprise includes Group Policy settings for fine-tuning the User
Monitor. As a best practice, it is recommended that you do not enable the
User Monitor on computers to which more than 100 users can log on or for
users who are members of more than 100 PBIS-related groups.
Group Policy Best Practices
The following best practices are recommended for Group Policy.
General Best Practices
• Follow the same best practices for applying Group Policy Objects
(GPOs) that Microsoft recommends on TechNet.
• PBIS provides a “Target Platform Filter” that you can use to limit the
application of Group Policy to selected operating systems.To simplify
troubleshooting across multiple operating systems, avoid heavy use of
the PBIS target platform filter for Group Policy settings.
Reporting Best Practices
To use the full functionality of PBIS reporting, follow these best practices:
• Configure all of the "Enable PBIS Auditing" settings in Group Policy.

• Configure the Syslog Auditing policy so that you can obtain a complete
picture of audit events across all PBIS agents.
Settings
The New Cell Wizard in the PBIS Console provides the initial best practices
for your PBIS Enterprise settings. Those settings not enforced in this initial
Group Policy Object have been optimized on the client for each version of
PBIS.
PBIS Settings
• Authorization
– Enable use of the Event Log
– Enable user credential refreshing on Workstations
– Disable user credential refreshing on Servers
• Logon
– Disable creation of home directory on NFS mounted home
directories
– Disable creation of .k5login on NFS mounted home directories
• Group Policy
– Enable use of the Event Log
• Event Log
– Keep a 90-plus day history in the Event Log
– Set a maximum disk size at 75MB
– Remove events as needed
• Logging and Audit Settings
– Enable PBIS Auditing in the Syslog settings
Group Policy Object Creation
Many PBIS Enterprise policy settings control specific Unix files. For
example, the sudoers and Automount policy settings.
When these policy settings are used, it is strongly recommended that the
files be created and tested on a Unix computer, then transferred directly to
Group Policy using one of the following:
• the gp-admin tool from a Linux computer
• binary transfer to a Windows computer to upload with Group Policy
Management Console (GPMC).
As a best practice, never modify these settings on a Windows computer.

Best Practices for Unix, Linux, and Mac OS X
The following are recommend best practices for using PowerBroker Identity
Services in Unix, Linux, and Mac OS X environments.
• Any time SSH is upgraded, run the following command to verify the
sshd_config file is set up properly to work with PBIS:
domainjoin-cli configure --enable ssh
• After any major upgrade (kernel patch, operating system upgrade, or
similar upgrade), rejoin the domain.
This will ensure that all OS-specific files are configured properly, and
will also update the "operatingSystemVersion" and
"operatingSystemServicePack" values in Active Directory so that the
PBIS Reporting (or other reporting) system can accurately reflect the
environment.
• Apply all vendor patches according to the vendor’s schedule.
AIX Best Practices
It is recommended that PAM support be enabled and tested with all client
applications prior to installing PBIS. While LAM is supported, PAM
authentication provides standardized authentication across all environments,
including AIX.
It is recommended that you deprecate the practice of using the suroot
group in favor of PAM-enabled sudo (available from IBM at
http://www.ibm.com/developerworks/aix/library/au-sudo/) for all end-
users and application owners on the AIX environment, due to difficulties
managing the suroot group for AD users after PBIS is installed.
Linux Best Practices
The following are best practices for using PBIS with specific Linux variants.
Debian Linux variants (Ubuntu)
Likewise Open 5.4 from Ubuntu repositories should be replaced with the
current version of PBIS Open to implement important fixes to the registry.

Red Hat Enterprise Linux variants (CentOS and Fedora)
In RPM-based systems, each package owns its own PAM file, which is
written, then updated by the authconfig process. Therefore, whenever
authconfig, yum upgrade, or a similar command is run, you should run
domainjoin-cli configure --enable pam to ensure that the pam_
lsass.so entries are added back into the proper places in the PAM
configuration. Of particular note is that in some environments customers
schedule a background update from RHN on computers. After this
background update is complete, domainjoin-cli configure --enable
pam should also be run.
Mac OS X Best Practices
All PPC systems should be upgraded to OS X 10.5 or later for several
updates to the Apple DirectoryService process.
OS X 10.6 systems must be running 10.6.4 or later for several important
updates to the Apple DirectoryService process.
OS X 10.5 systems must be running 10.5.6 or later for important updates to
the Apple DirectoryService process.
OS X systems should be rejoined to AD using the PBIS Domain Join plug-
in in Directory Utility after any OS X kernel update.
Because OS X DirectoryService caches information including negative
lookups, it is recommended that you clear the agent cache (ad-cache --
delete-all) and reboot a user's Mac after any change to that user's Unix
attributes in the PBIS Settings tab.
Solaris Best Practices
Using Solaris 10 U5 or later is recommended. There are many fixes in U2,
U4 and U5 for pthreads support, which PBIS uses extensively.
Large Solaris environments should enable only the AD groups required for
Unix file/sudo access, because Solaris 10 still has a maximum of 32 groups
per user.
Solaris Full Root Zones
It is recommended that you install PBIS on Solaris Zones individually. This
gives the Unix administrator the flexibility to upgrade zones individually,
separate from the upgrade state of the global zone. Additionally, because the
join state is managed on a per-zone basis, the entire PBIS installation can be
managed together on each individual zone.

Solaris Sparse Root Zones
Solaris Sparse Root zones should be managed with a “whole system”
philosophy. Because certain files are only created in the global zone, when
they are upgraded, all child zones should be upgraded at the same time as
well. This is handled by the PBIS installer automatically. The join state is
still managed individually on each child zone. In cases where all the zones
cannot be upgraded simultaneously, the non-upgradable systems must be
migrated to a new host.
Unix Applications Best Practices
To achieve best performance for Kerberos SSO, SSH platforms based on
OpenSSH 4.3 or later are recommended. Sun Solaris SunSSH 1.2 and HP-
UX SSH 2.0 also perform optimally.
For best performance, the PBIS NssEnumerationEnabled setting (config
--detail NssEnumerationEnabled) should be set to false, which is the
default. However, many applications use the getent() family of functions
for PAM-based authentication, particularly getpwent() and getgrent().
For applications that claim PAM support but do not work initially, you may
need to set NssEnumerationEnabled to true.
Account Management Best Practices
The following are recommended best practices for managing service
accounts, application accounts, and user accounts when using PowerBroker
Identity Services in a Unix, Linux, or Mac OS X environment.
Note: Some Unix operating systems may limit how many groups can be
nested or of how many groups a user can be a member.
Service Accounts
Any application that runs as a process on a host as a user ID should be run as
a local service account. Users should not authenticate as these accounts, but
instead should use sudo or a similar process to authenticate as themselves
with the authorization to run commands on behalf of the service account.
Application Accounts
Applications that authenticate to another host as a user ID should use an
application account based in Active Directory (AD), and managed by your
SOP for application and service accounts in AD.
User Accounts
All accounts that can be mapped back to a single person should be based in
AD and not exist locally. If there is no account for a person in AD, then the
account should be moved to AD.

PBIS Installation and Administration Guide

PBIS Installation and Administration Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to PBIS Installation and Administration Guide

Similar to PBIS Installation and Administration Guide (20)

More from Kumaran Balachandran

More from Kumaran Balachandran (13)

Recently uploaded

Recently uploaded (20)

PBIS Installation and Administration Guide