Server Suite 2022.x

Server Suite
Documentation 2022.x
Table of Contents
Welcome to Server Suite 253
Welcome to Server Suite 254
Install and Upgrade 255
Using this Planning and Deployment Guide 256
Planning Deployment for an Enterprise 257

What You Should Know Before Planning a Deployment 257
Why Planning a Deployment is Important 257
What to Expect During Deployment 257
Evaluation 257
Analysis and Design 257
Pilot Deployment 258
Testing and Validation 258
Roll-Out Deployment 258
Ongoing Management and Evolution 258
Preparing a Deployment Team 258
Active Directory Enterprise or Domain Administrators 258
UNIX Administrators or Administrators with Specific Expertise 258
Security Administrators 258
IT or Network Architects 259
Application Developers 259
Functional Testers 259
Centrify Administrative Operators 259
Database Administrators 259
Internal or External Auditors 259
Preparing Deployment Documentation 259
Defining Goals for the Deployment 260
Architecture and Basic Operations 261
Server Suite Platform-Specific Components 261
Server Suite Components for Windows 261
Components Installed on Managed Computers 261
Storing Server Suite Properties in Active Directory 262
Using Access Manager 262
Allowing and Blocking Domains for Access Manager 263
Core Agent Components and Services 263
Key Operations Handled by the Adclient Process 264
How PAM Applications Work with Server Suite 264
https://delinea.com/ 2
How NSS Configuration Works with Server Suite 265
How the Server Suite Agent Manages Kerberos Files 265
What Happens During the Typical Log-on Process 266
How Failover and Disconnected Access Work 267
Establishing a Connection to DNS 267
Connecting to the Closest Domain Controller 267
Restricting the Domain Controllers Contacted 268
Switching to Disconnected Mode 268
Responding to DNS Configuration Changes 268
Connecting to Trusted Forests and Domains 269
Deployment Process Overview 270

What’s Involved in a Typical Deployment Project 270
Plan 270
Default Ports for Network Traffic and Communication 271
Network Connections and Database Management for Auditing 272
Prepare 272
Deploy 273
Validate 274
Manage 275
Deployment Tasks and Administrative Activity 275
Steps You Only Take Once 275
Steps You Take More than Once During Deployment 276
Steps You Take After Deployment to Begin Managing Zones Effectively 276
What Happens After Deployment? 277
Sample Workflow for Deployment Decisions 277
Planning Organizational Units and Security Groups 278

Identifying Stakeholders and Business Processes 278
Designing Organizational Units for Centrify 278
Selecting a Location for the Top-Level OU 278
Single Forest with a Single Domain 278
Single Forest with an Empty Root Domain 279
Single Forest with Account and Resource Domains 279
Multiple forests with Trust Relationships 279
Cross-forest Authentication for Two-way Trust Relationships 279
Cross-forest Authentication for One-way Trust Relationships 279
Analyzing Trust Relationship to Prevent Authentication Failures 280
Forests separated by a firewall (DMZ) 280
Creating Recommended Organizational Units 280
Creating Organizational Units In Access Manager 280
Centrify Administration Organizational Unit 281
Computer Roles Organizational Unit 281
Computers Organizational Unit 281
Provisioning Groups Organizational Unit 281
Service Accounts Organizational Unit 282
Unix Groups Organizational Unit 282
User Roles Organizational Unit 282
Licenses And Zones Parent Containers 282
Security Groups To Manage Centrify Information 282
Delegating Control For Centrify Administrators 283
Delegating Control For Authorization Managers 283
Delegating Tasks For User Role Groups 283
Delegating Tasks For Computer Role Groups 283
Delegating Zone-specific Tasks 283
Delegating Control For Computer Managers 284
Delegating Control For Unix Data Managers 284
Delegating Tasks For Unix Groups 284
Delegating Tasks For Service Accounts 284
Delegating Zone-Specific Tasks 284
Planning for Data Storage in Active Directory 284
Changing The Zone Type 284
Modifying Indexed Attributes For Zones 285
Viewing and Manipulating Data in Active Directory 285
Installing Authentication & Privilege Services 287
Preparing for Installation on Windows 287
Installing Server Suite 287
Preparing Active Directory and DNS 287
Identifying the Windows Computer and Log On Credentials 287
Checking Operating System and Software Requirements 288
Checking Disk and Memory Requirements 288
Running the Setup Program on a Windows Computer 288
Installing Zone Provisioning Agent 289
About Zone Provisioning Agent and its Requirements 289
Create a service account for the Zone Provisioning Agent 290
Configure the local or domain group policy to allow the account to log on as a service 290
Installing the Zone Provisioning Agent on the Access Manager computer 291
Installing the Zone Provisioning Agent on its own 291
Configuring the Zone Provisioning Agent 292
Whitelisting Domains for the Zone Provisioning Agent 292
Running Access Manager for the First Time 293
Access Manager Account Permissions 293
Installing Agents on Computers to be Managed 295
About the Deployment Process 295
Select a Target Set of Computers 295
Options for deploying Server Suite Agent Packages 295
Install Interactively on a Computer 295
Run the Bundle Installation from a Mounted Network Volume 296
Install Silently Using a Configuration File 297
About the Sample Configuration Files Available 297
Setting the Parameters in a Custom Configuration File for the Installation Script 297
Customizing the Return Codes for the Installation Script 299
Use Other Automated Software Distribution Utilities 299
Using a Native Package Installer 300

Enabling Package Repositories 301
Redhat 302
To Set Up and Configure a Redhat, Centos, or Amazon Repository 302
SuSE 304
To Set Up and Configure a Suse Repository 304
Debian Ubuntu 305
To set up and configure a Debian or Ubuntu repository 305
To Access a Raw Package (wget) Repository for Atomic 306
To Set Up and Configure an Alpine Linux Repository 307
About the Files And Directories Installed on the Agent 308
Joining an Active Directory Domain at a Later Time 309
Installing the Agent on Solaris Systems 310

Installing the Solaris Svr4 Agent Packages 310
Installing the Solaris IPS Agent Packages 310
Installing the Solaris IPS Agent Packages With Child Zones 311
Uninstalling the Agent on Solaris Systems 312
Sun Solaris Installation Notes 313
Changing the Local User Password on Solaris 313
Installing Authentication Service Packages into Solaris 10 Zones 313
Installing Authentication Service Packages into Solaris 11 Child Zones 313
Creating a Home Directory for New Users on Solaris 314
Planning to Use Server Suite Zones 315

Why Use Zones? 315
Identity Management Using Zones 315
Role-based Access Control and Zones 315
Using Zones to Delegate Administrative Duties 316
Deploying to a Single Auto Zone 316
Classic and Hierarchical Zones 316
Should You Use Classic Zones? 316
When Should You Use Hierarchical Zones? 317
How Many Zones Do You Need? 317
A Closer Look at Using Zones in a Hierarchical Model 317
How Inheritance Provides Additional Benefits 317
How Many Levels Should You Use in the Zone Hierarchy? 318
Identity Management and Inherited Profile Information 318
Working with Partial Profiles in the Zone Hierarchy 318
Working with Variables in the Zone Hierarchy 319
Complete Profiles Do Not Grant Access 319
Access Controls and the Assignment of Rights and Roles 319
Understanding Roles and Rights 319
Working with a Candidate Set of Profiles 320
Delegation in Hierarchical Zones 320
Designing a Zone Structure for Your Environment 320
Preparing To Migrate Existing Users And Groups 321

Collecting And Analyzing Users and Groups 321
Collecting Information from Other Departments in Your Organization 321
Using a Script to Retrieve User and Group Profiles for Each Computer 321
Collecting Data from NIS Domains 321
Identifying Accounts that Should Not Be Migrated 322
Eliminate Default System Accounts 322
Remove Other Invalid Accounts 322
Create a List of the Users and Groups to Ignore 322
Analyze User Profiles for Conflicting Attributes 322
Analyze Group Profiles for Conflicting Attributes 323
Create a Working Set of User and Group Profiles 323
How Migration Affects the Zone Design 323
Creating the First Zone 324
Create a Top-level Parent Zone 324
To create the top-level parent zone 324
Add Provisioning Groups to the Parent Zone 324
To add the provisioning groups for user and group profiles to the parent zone 324
Create Groups for the Default Roles in fhe Parent Zone 325
To create the groups for listed and UNIX Login roles in the parent zone 325
Delegate Administrative Tasks on the Parent Zone 325
To delegate administrative tasks on the top-level parent zone 325
Link a Role Group to a Role Assignment in the Parent Zone 326
Create One or More Child Zones 326
Logical Models for Defining Zones 326
Create a Child Zone under the Parent Zone 327
To create a child zone under the parent zone 327
Create Role Groups for Child Zones 327
To create the role groups for listed and UNIX Login roles in the parent zone 327
Delegate Administrative Tasks on the Child Zone 328
Link Role Groups to Role Assignments in the Child Zone 328
Create Computer Objects For The Target Set Of Computers 328
Prepare A Computer Object Before Joining 328
To prepare a computer account in Active Directory using Prepare Computer 328
Migrating Existing Users To Hierarchical Zones 330
Importing Group Profiles 330
Import Unix Groups that Apply to All Computers into the Parent Zone 330
To Import Unix Groups Using the Import from Unix Wizard 330
Import Unix Groups that Apply Only to a Specific Zone into a Child Zone 331
Import a Group Profile or Override Attributes on Specific Computers 331
To create a group profile for a specific computer 331
Avoiding Group Collisions When Using Computer-level Overrides 331
Importing User Profiles 331
How Group Membership Works Within Zones 332
Assigning Roles to Existing Users and Groups 332
Using Active Directory Groups for Roles 332
Adding Users to Role Groups 333
Migrating Existing Users Into The Unix Login Role In The Parent Zone 333
Migrating Existing Users into the Unix Login Role in Child Zones 333
Migrating Existing Users into the Listed Role in Child Zones 333
Using a Computer-level Override for the Unix Login Role 333
Managing Role Assignment Without Role Groups 334
Verifying Effective Users On Each Zone 334
To access the Effective Users for a zone 334
Adding Existing Users and Groups to Provisioning Groups 334
Add Existing Users To The Provisioning Group For The Parent Zone 334
To add existing UNIX users to the provisioning group for the parent zone 335
Add Existing Groups to the Provisioning Group for the Parent Zone 335
To add existing UNIX groups to the provisioning group for the parent zone 335
Joining Computers to a Domain and Zone 336
Using Adjoin on New Computers 336
Running Adjoin Requires Unix and Active Directory Privileges 336
Specifying the Required Options 336
Pre-staging Before Using Adjoin on a New Machine 336
Security Requirements 337
Preparing to Use the --prestage Option 337
Verify Authentication After Joining the Domain By Logging On 337
Provisioning New User and Group Profiles After Migration 339

Integrating with Existing Provisioning Processes 339
Defining the Business Rules for New Groups in the Parent Zone 339
Configure the Business Rules for Automated Provisioning of Group Profiles 339
To Configure the Business Rules For Groups in the Parent Zone 339
Add Security Groups to the Parent Zone 340
Defining The Business Rules For New Users In The Parent Zone 340
To Configure The Business Rules For User Profiles In The Parent Zone 340
How Hierarchical Zones Affect Provisioning 342
Adding New Users to a Provisioning Group and a Role Group 342
Add The User to a Provisioning Group 342
Add the User to a Role Group 343
Adding a New Unix Group Profile to All Zones 343
Using the Zoneupdate Program for Controlled Automation 344
Using Any Active Directory Attribute in a Profile 346
Provisioning Users When Across Trusted Domains 347
Monitoring Provisioning Events 347
Adding New Profiles Manually 349
Validating Operations After Deploying 350

Understanding Testing as Part of Deployment 350
Validating Basic Authentication and Password Policy Operations 350
Running Commands on the Unix Computer to Verify Operations 350
Verify the Computer is Joined to Active Directory 351
Verify Authentication for an Authorized User 351
Test Additional Administrative Tasks 351
Resolving Issues in the Pilot Deployment 352
Preparing Training and Documentation for Administrators and Users 352
Deploying to the Production Environment 352
Training the Support Staff for a Production Deployment 353
Preparing the User Community in a Production Deployment 353
Populating Zones in a Production Environment 354
Joining a Domain in a Production Environment 354
Defining Role-Based Access for Users and Computers 355
Addressing the Business Problem of Role-based Security 355
Creating a Root-Equivalent Role Definition 355
Define the Right for Running All Commands 355
Create a Role Definition for Running All Commands 356
Assign an Active Directory Group to the Role 356
Creating a Restricted Role for a Shared Service Account 357
Define the Right for Switching to a Service Account 357
Define a PAM Access Right to Allow Logging On 358
Create a Restricted Role Definition for the Service Account 358
Assign an Active Directory Group to the Role 359
Working in a Restricted Shell Environment 359
Testing Access in a Restricted Shell 359
What Users See in a Restricted Shell Environment 360
Creating a Role Definition for Temporary Root Access 360
Define a Command that Allows Root Access 360
Create a Role Definition for Temporarily Running as Root 360
Assign the Role as a Computer-level Override 361
Verify the Role Assignment on the Computer 361
Creating a Role Definition With Specific Privileges 362
Define Command Rights to Prevent the Use of Commands 362
Create a Restricted Shell Role Definition that Uses the Command Rights 362
Create an Unrestricted Shell Role Definition that Uses the Command Rights 363
Creating a Role Definition with Rescue Rights 364
Creating Additional Custom Roles and Role Assignments 364
Working with Computer Roles 364
Planning to Use Computer Roles 364
How Computer Roles Simplify the Management of Access Rights 365
Migrating And Managing Service Accounts 366

Why Migrate Service Accounts? 366
Identifying Service Accounts to Migrate Tto Active Directory 366
Service Accounts Without a Password 366
Service Accounts with a Shared Password 366
Service Accounts that Use SSH Keys 366
Mapping a Service Account to an Active Directory User 366
Create a New Active Directory User Account 367
Map the Unix Service Account to the Active Directory User 367
How the Mapped User Changes Your Environment 368
Creating a Service Account Role in a Zone 368
Create an Active Directory User Account for the Service 368
Define a New Role with System Rights 368
Create a Unix Profile for the Service Account and Assign the Role 369
Secure the Active Directory User Account 370
Using Ssh Keys for Authentication 370
Using Kerberos Tickets for Authentication 370
Testing And Migration 371
Renewing Ticket Granting Tickets 371
More Information 371
Remove Local Service Accounts from Remote Computers 371
Planning to Deploy in a Demilitarized Zone (DMZ) 372

Identifying the Computers to Protect 372
Creating a Forest and Trusts for a DMZ 372
Defining Zones for Computers in the DMZ 372
Creating a Firewall and Securing the Network 373
How to Join a Domain with a Read-Only Domain Controller (RODC) 373
Enabling NTLM Authentication through a Firewall 374
Configuring the Domain Controllers that Allow NTLM Authentication 374
Configuring a Map that Converts NTLM Domains to Active Directory 374
Managing and Evolving Operations After Deployment 375

Understanding How Server Suite Software Affects Operations 375
Understanding Change Management Activities 375
Understanding System Administration Activities 375
Understanding Security Administration Activities 375
Delegated Administration 375
Password Policy Enforcement 376
Privileged Account Management 376
Understanding Service Desk Operations 376
Understanding Capacity Management Activities 376
Determining Whether You Need More Resources 376
Understanding How Caching Facilitates Lookups 376
Troubleshooting Logon Failures 377
Evaluating Additional Services And Integrations 378
Adding Authentication Service for Applications 379
Supporting Single Sign-on for Kerberos-enabled Applications 379
Supporting Single Sign-on for PAM-aware Applications 379
Supporting Active Directory Authentication for Apache and Java Applications 379
Supporting Database Server Applications 379
Adding Custom Reports for Auditing Unix Properties 379
Adding Group Policies 380
Evaluating Existing Policy Settings 380
Adding Server Suite-specific Group Policies to a GPO 380
Adding Support for NIS Clients 380
Using Programs Optimized for Kerberos Authentication 381
Integrating with Products from Other Vendors 381
Getting Assistance from Support 381
Templates and Sample Forms 383
Simplified Environment Analysis and Zone Design Template 383
Change Control Request Form 383
Test Case Matrix Sample 384
Preliminary Software Delivery Notification Email Template 385
Department-specific Announcement and Instructions Email Template 386
General Announcement and Deployment Schedule Email Template 386
Deployment Team Task Checklist 387
Permissions Required for Administrative Tasks 390

How Permissions Are Set 390
Permissions Required to Use the Setup Wizard 392
Licenses Container Permission Requirements 392
Licenses Container Permissions 393
Zones Container Permissions 393
Computers Container Permissions 394
Computers Container Within a Zone Permissions 394
Creating Parent Containers Manually 394
Optional Administrative Tasks 394
Creating Display Specifiers for Centrify Profiles 395
Registering the Administrative Notification Handler 395
Granting Permissions For Administrative Tasks 396
Setting permissions for zones 398
Creating a Zone 398
Opening Zones 399
Modifying Zone Properties 399
Renaming a Zone 399
Deleting a Zone 399
Managing Roles and Rights in a Zone 400
Managing Role Assignments in a Zone 400
Changing Computer Role Properties in a Zone 401
Setting Permissions to Join or Leave the Domain 401
Setting Permissions for Zone Computers 402
Joining a Computer to a Zone 402
Listing Computer Accounts 402
Modifying Computer Properties 402
Responding to NIS Requests 403
Changing the Computer Zone 403
Preparing a Computer Object 403
Creating The Computer Object Manually 404
Modifying Computer Roles 404
Deleting Computer Roles 404
Setting Permissions For Zone Users 405
Adding Users To Standard Zones 405
Modifying Users In Standard Zones 405
Modifying Users In Rfc 2307-compliant Zones 405
Listing Users In Standard Zones 406
Listing Users in RFC 2307-Compliant Zones 406
Removing Users from Zones 406
Setting Permissions for Zone Groups 406
Adding Security Groups to Zones 406
Modifying Groups in Standard Zones 407
Modifying Groups in RFC 2307-Compliant Zones 407
Listing Groups in Zones 407
Listing Groups in RFC 2307-Compliant Zones 408
Removing Groups from Zones 408
Setting Permissions for License Keys 408
Setting Permissions for NIS Maps 408
Adding NIS Maps to a Zone 409
Deleting NIS Maps from a Zone 409
Adding Map Entries to NIS Maps 409
Modifying Map Entries in NIS Maps 409
Changing the Map Type for NIS Maps 410
Deleting Map Entries from NIS Maps 410
Adding Entries to a Specific NIS Map 410
Modifying Entries in a specific NIS Map 410
Changing the Map Type for a Specific NIS Map 410
Deleting Map Entries from a Specific NIS Map 411
Setting Permissions for Password Synchronization 411
Centrify Password Synchronization Service 411
Microsoft Password Synchronization Service 411
Setting Permissions for Rights and Roles 411
Creating the Authorization Store 411
Defining Rights And Roles in the Authorization Store 412
Configuring Authorization In Classic Zones 412
Adding Roles 412
Modifying Roles 412
Deleting Roles 413
Adding Rights 413
Modifying Rights 413
Deleting Rights 413
Adding or Removing Rights from Roles 414
Adding Role Assignments 414
Modifying Role Assignments 414
Deleting Role Assignments 414
Setting Permissions for Zone Provisioning 415
Supplemental Installation Notes 416

Verifying the DNS Configuration on Linux 416
Joining the Domain (Zoned Mode Only) 416
Joining the Domain (Express mode) 416
HPUX Installation Notes 416
ia64 - Mapping Local HP-UX User Accounts to Active Directory Accounts 417
Entering an Incorrect Password on HP-UX 417
AIX Installation Notes 417
Support for AIX Capabilities Attribute 417
Users Cannot Log in by way of FTP if They Have a Restricted Shell 418
Starting and Stopping DirectControl on AIX 418
Using the Server Suite Authentication Service LDAP Proxy on AIX 418
Setting the DNS Configuration Parameter to Join the Domain on SuSE Linux 418
Mounting CIFS Shares 419

Use Cases 419
CentrifyDC-cifsidmap Plug-in Requirements 419
Prepare to Install the CentrifyDC-cifsidmap Plug-in 420
Install the CentrifyDC-cifsidmap Package 420
Configure cifs-utils for CentrifyDC-cifsidmap Plug-in 421
Mount the CIFS Share and Confirm File Ownership 422
Known Issues 424

Installation and Un-installation Issues 424
Configuration Issues 424
Environment Issues 424
RunAsRole Issues 425
Desktop with Elevated Privileges issues 425
Roles and Rights Issues 425
Compatibility with Third Party Products Issues 425
Application Manager Issues 426
Best Practices 427
Best Practices For Unix And Linux Systems With Server Suite 427
Upgrade Server Suite Agents And Administrative Tools 427
Enable NSCD 427
Set Group Policies To Govern The Agent Behavior 427
Set agent parameters 427
Exclusions of Domains 427
Paged Control 428
Suite 2016.1 428
Use the Server Suite DB2 Plugin 428
Best Practices for Active Directory Environment 428
Index the UID Attribute 428
Windows Active Directory functional level and Windows Server version 428
Maintain sites and services domain controller topology 428
Centrify Access Model Best Practices 428
Proper definition of global/child zone structure. 428
Analyze The Deployment Periodically 429
Use the Centrify Zone Provisioning Agent 429
Deploy Reporting Services and Security Information and Event Management (SIEM) 429
Best Practices for the Audit and Monitoring Service 429
Manage the Audit Store Database Size 429
Maintain the audit store database index 430
Configure SQL Server 430
Audit and Monitoring Architecture 430
Grant Audit Installation Rights To Administrator Groups 430
Delinea Relationship Best Practices 430
Monthly Cadence Call with Delinea 430
Get Your Annual Delinea Healthcheck 430
Attend Annual Delinea Update Meetings 430
Using this Licensing Guide 432

Audience 432
How Delinea Licenses are Managed 433
Delinea License Management Tools 433

How Licensing Works 433
Understanding License Types 433
Understanding License Keys 434
How License Usage is Counted 434
Using Delinea Licenses in FIPS Environments 434

Installing License Management Tools 435
Installing the Delinea Licensing Service 435

Performing a Standalone Licensing Service Installation 435
Modifying a Delinea Licensing Service Installation 435
Verifying that the Delinea Licensing Service is Running 435
Assigning a License Container to a Zone through Access Manager 436
Installing the Licensing Report Wizard 436

Modifying a Licensing Report Wizard Installation 436
Managing Licenses with the Licensing Service 437
Opening the Licensing Service control panel 437
Starting, stopping, and refreshing the licensing service 438
Refreshing the License Count Manually 438
Creating License Containers and Adding License Keys 438
Creating License Containers 438
Adding and Removing Centrify License Keys 439
To add license keys for authentication and privilege elevation: 440
To add license keys for audit and monitoring service: 440
To delete a license key that you have previously installed: 440
Monitoring Centrify license Usage 440

To see usage information for authentication and privilege elevation licenses: 440
Configuring Licensing Service Settings 441

Refreshing license usage information 441
To configure an automatic refresh interval: 441
Configuring License Usage Email Notification 441
To configure license usage email notification: 442
Configuring and Viewing Licensing Service Logs 443

To view and edit the current log file: 443
To configure licensing service event logging level: 443
Creating Licensing Reports with the Licensing Report Wizard 444
Permissions Required to Generate a Licensing Report 444
Information Required to Produce the Licensing Report 444
Preparing to run the Licensing Report wizard 445

To check for and remove orphaned and decommissioned computers: 445
Running the Licensing Report Wizard 445

To run the wizard from within Access Manager: 445
Running the utility as a separate package 446
Running the utility from the command line. 446
Reviewing the licensing report output 447
How Computers are Counted for Licensing Reports 447
Counted Computer Scenarios 447
Uncounted Computer Scenarios 448
License Type Information for Managed and Audited Computers 448
Zone information for managed computers 448
Status information for managed and audited computers 449
Remarks for Managed and Audited Computers 449
Evaluation Licenses for Managed and Audited Computers 450
Status Information for Zoneless Computers 450
Examples 450
Example 1: Agent, License Type and Count 450
Example 2: Zone Mode and Number of Agents 451
Example 3: Zone Names and Deployment Details 452
Example 4: License Detail Summaries 453
Example 5: Counted and Uncounted Computers 454
Example 6: Counted Identity and Privilege Elevation Computers 455
Example 7: Counted Audit and Monitoring Service Computers 456
Example 8: Uncounted computers of all license types 457
Example 9: List of Zones and Special Profiles 459
Upgrade and Compatibility Guide 461
Preparing For An Upgrade 462
Upgrading the Operating System 463
Upgrading Computers Accessed by Multiple Users 464
Compatibility Between Versions of Delinea Software 465

Finding Upgrade Packages 466
Disabling Command-line Auditing 467
Upgrading Delinea Management Services on Windows Computers 468

What Should You Upgrade First? 469
Updating Administrative Components 470

Access Control and Privilege Management Compatibility 470
Auditing Infrastructure Compatibility 470
Access Control and Privilege Management Compatibility 471
Auditing Infrastructure Compatibility 472
Upgrading Components Interactively 473
Upgrading Auditing Components Silently on Windows 474
Upgrading Auditing Infrastructure 475

Why Are There Formal Steps for Upgrading an Audit Installation 476
Upgrading Auditing Components in a Specific Order 477
Unsupported Configurations 478
Updating Auditing-Related Databases 479
Updating Agents Out of Sequence 480

Restarting Computer After Agent Upgrade 481
Best Practices for Upgrading Large Audit Installations 482
Upgrading Managed Computers 483
Configuring install.sh to Run Without User Interaction 484
Using the install.sh Shell Script to Update Packages 485

Using a Native Package Manager on Linux Computers 486
Upgrading Packages on a Linux Computer 486
Fresh Installation Using RPM 486
Upgrading Existing Packages Using RPM 486
Fresh Installation Using the Debian Package Manager 486
Upgrading Packages Using the Debian Package Manager 487
Using a Native Package Manager on UNIX Computers 488
Upgrading Packages Individually on a UNIX Computer 488
Performing Upgrades on UNIX Computers 488
Upgrading Packages on Solaris Computers 488
Upgrading Packages on HP-UX Computers 489
Upgrading Packages on AIX Computers 490
Upgrading Agents on Solaris Systems 491
Upgrading and Migrating Solaris svr4 Packages to IPS on Solaris 11 491
Upgrading Managed Mac OS X Computers 493

Compatibility for Additional Packages 494
Should You Be Concerned About Compatibility? 495
Removing the CentrifyDC-samba Package 496
Compatibility for CentrifyDC-nis Package 497
Compatibility for CentrifyDC-krb5 Package 498

Compatibility for CentrifyDC-ldapproxy Package 499
Compatibility for CentrifyDC-openssh Package 500
Compatibility for CentrifyDC-Apache and CentrifyDC-Web Packages 501
Upgrading Version-Dependent Packages 502
Working with Classic Zones After an Upgrade 503

What To Do If There Are Problems During an Upgrade 504
Remove and Re-install Authentication and Privilege 505
Remove and Re-install Delinea Audit and Monitoring Service 506
Remove and Re-install Agent Features 507
Known Issues 508

Installation and Uninstallation Issues 509
Configuration Issues 510
Environment Issues 511
RunAsRole Issues 512
Desktop with Elevated Privileges Issues 513

Roles and Rights Issues 514
Compatibility with Third Party Products Issues 515
Application Manager Issues 516
Configuration 517
Configuration and Tuning Reference Guide 518

Intended Audience 518
Limitations of this Guide 518
Working with Parameters and Agent Configuration Files 519
Controlling agent operations 520
Basic syntax used in configuration files 521
Setting configuration parameter names 522
Setting configuration parameter values 523
Using special characters 523
Using environment variables 523
Rereading parameter values after making changes 524

Securing parameter settings 525
Using group policies to configure settings 526
Parameters and values are subject to change 527
Customizing adclient Configuration Parameters 528
adclient.altupns 529
adclient.autoedit 530
Enabling automatic editing for specific files 530
Editing the NSS configuration manually 531
Editing the PAM configuration manually 531
Editing the LAM configuration manually 532
adclient.binding.dc.failover.delay 533
adclient.binding.idle.time 534
adclient.binding.ldapsearch.statistic.interval 535
adclient.binding.refresh.force 536
adclient.binding.refresh.interval 537
adclient.get.builtin.membership 538
adclient.cache.cleanup.interval 539
adclient.cache.encrypt 540
adclient.cache.encryption.type 541
adclient.cache.expires 542
adclient.cache.expires.computer 543
adclient.cache.expires.extension 544
adclient.cache.expires.gc 545
adclient.cache.expires.group 546
adclient.cache.expires.group.membership 547
adclient.cache.expires.search 548
adclient.cache.expires.user.membership 550
adclient.cache.flush.interval 551
adclient.cache.negative.lifetime 552
adclient.cache.object.lifetime 553
adclient.cache.refresh 554
adclient.cache.refresh.computer 555
adclient.cache.refresh.extension 556
adclient.cache.refresh.gc 557
adclient.cache.refresh.group 558
adclient.cache.refresh.search 559
adclient.cache.refresh.user 560
adclient.cache.upn.index 561
adclient.client.idle.timeout 562
adclient.clients.listen.backlog 563
adclient.clients.socket 564
adclient.clients.threads 565
adclient.clients.threads.max 566
adclient.clients.threads.poll 567
adclient.cloud.auth.token.max 568
adclient.cloud.cert.store 569
adclient.cloud.connector 570
adclient.cloud.connector.refresh.interval 571
adclient.cloud.skip.cert.verification 572
adclient.cloud.connector.subnet.preference.enabled 573
adclient.custom.attributes 574
adclient.deploy.report.update.interval 575
adclient.disk.check.free 576
adclient.disk.check.interval 577
adclient.dns.cache.timeout 578
adclient.dns.cachingserver 579
adclient.dumpcore 580
adclient.dynamic.dns.command 581
adclient.dynamic.dns.enabled 582
adclient.dynamic.dns.refresh.interval 583
adclient.excluded.domains 584
adclient.exit.on.incomplete.zone.hierarchy 585
adclient.fetch.object.count 586
adclient.force.salt.lookup 587
adclient.gc.locator.shortcut 588
adclient.get.primarygroup.membership 589
adclient.gmsa 590
adclient.hash.allow 591
adclient.hash.deny 592
adclient.hash.expires 593
adclient.heartbeat.interval 594
adclient.ignore.setgrpsrc 595
adclient.included.domains 596
adclient.ipv4.port.range.low / high 597
adclient.iterate.private.groups 598
adclient.krb5.principal.lower 599
adclient.krb5.conf.domain_realm.anysite 600
adclient.ldap.packet.encrypt 601
adclient.ldap.socket.timeout 602
adclient.ldap.timeout 603
adclient.ldap.timeout.search 604
adclient.ldap.trust.enabled 605
adclient.ldap.trust.timeout 606
adclient.legacyzone.mfa.background.fetch.interval 607
adclient.legacyzone.mfa.cloudurl 608
adclient.legacyzone.mfa.enabled 609
adclient.legacyzone.mfa.required.groups 610
Supported group name formats 610
Specifying the parameter value in a separate file 610
adclient.legacyzone.mfa.required.users 611
Supported user name formats 611
adclient.legacyzone.mfa.rescue.users 612
adclient.legacyzone.mfa.tenantid 613
adclient.local.account.manage 614
adclient.local.account.manage.strict 615
adclient.local.account.notification.cli 616
adclient.local.account.notification.cli.arg.length.max 617
adclient.local.forest.altupn.lookup 618
adclient.local.group.merge 619
adclient.logonhours.local.enforcement 620
adclient.lookup.sites 621
adclient.lrpc2.receive.timeout 622
adclient.lrpc2.send.timeout 623
adclient.next.closest.site.lookup.enabled 624
adclient.nss.statistic.interval 625
adclient.ntlm.domains 626
adclient.ntlm.separators 627
adclient.one-way.x-forest.trust.force 628
adclient.os.name 629
adclient.os.version 630
adclient.os.version.use.win7prefix 631
adclient.paged.search.max 632
adclient.prefer.cache.validation 633
adclient.preferred.login.domains 634
adclient.preferred.site 635
adclient.prevalidate.allow.groups 636
Using this parameter with other prevalidation parameters 636
Registering service principal names 636
Specifying the supported encryption types 636
Refreshing prevalidated credentials 637
adclient.prevalidate.allow.users 638
sing this parameter with other prevalidation parameters 638
Registering service principal names 638
Specifying the supported encryption types 638
Refreshing prevalidated credentials 639
adclient.prevalidate.deny.groups 640
adclient.prevalidate.deny.users 641
adclient.prevalidate.interval 642
adclient.prevalidate.service 643
adclient.random.password.generate.try 644
adclient.random.password.complexity.pattern 645
adclient.random.password.length.min 646
adclient.random.password.length.max 647
adclient.samba.sync 648
adclient.server.try.max 649
adclient.skip.inbound.trusts 650
adclient.skip.unused.outbound.trusts 651
adclient.sntp.enabled 652
adclient.sntp.poll 653
dclient.tcp.connect.timeout 654
adclient.udp.timeout 655
adclient.update.os.interval 656
adclient.use.all.cpus 657
adclient.use.tokengroups 658
adclient.user.computers 659
adclient.user.lookup.cn 660
adclient.user.lookup.display 661
adclient.user.name.max.exceed.disallow 662
adclient.version2.compatible 663
adclient.watch.cpu.utilization.info.threshold 664
adclient.watch.cpu.utilization.warning.threshold 665
adclient.watch.slow.lookup.info.threshold 666
adclient.watch.slow.lookup.info.threshold.group 667
adclient.watch.slow.lookup.info.threshold.user 668
adclient.watch.slow.lookup.warn.threshold 669
adclient.watch.slow.lookup.warn.threshold.group 670
adclient.watch.slow.lookup.warn.threshold.user 671
adclient.zone.group.count 672
addns.tcp.timeout 673
addns.wait.time 674
adjust.offset 675
audittrail.audited.command.with.args 676
audittrail.Centrify_Suite.Trusted_Path.machinecred.skipda 677
audittrail.targets 678
audittrail. 679
audittrail. 680
capi.cache.enabled 681
capi.cache.hash.table.size 682
capi.cache.log.interval 683
capi.cache.max.objects 684
capi.cache.negative.ttl 685
capi.cache.ttl 686
db2.implement.pam.ignore.users 687
db2.user.zone_enabled 688
db2.userpass.username.lower 689
dc.dead.cache.refresh 690
dc.live.cache.refresh 691
dc.penalty.time 692
dns.alive.resweep.interval 693
dns.block 694
dns.cache.negative 695
dns.cache.timeout 696
dns.dc.domain_name 697
dns.dead.resweep.interval 698
dns.gc.domain_name 699
dns.query.all.servers 700
dns.servers 701
dns.sort 702
dns.sweep.pattern 703
dns.tcp.timeout 704
dns.udp.timeouts 705
domain.dead.cache.refresh 706
domain.live.cache.refresh 707
fips.mode.enable 708
log 709
logger.facility.adclient 710
logger.facility.adclient.audit 711
logger.facility.diag 712
logger.memory.bufsize 713
logger.memory.enabled 714
logger.memory.log 715
logger.queue.size 716
lrpc.connect.timeout 717
lrpc.session.timeout 718
lrpc.timeout 719
secedit.system.access.lockout.allowofflinelogin 720
queueable.random.delay.interval 721
Customizing Kerberos-Related Configuration Parameters 722
adclient.dc.switch.update.krb5.conf 723
adclient.krb5.allow_weak_crypto 724
adclient.krb5.autoedit 725
adclient.krb5.cache.renewal.service.accounts 726
adclient.krb5.ccache.dir 727
adclient.krb5.ccache.dir.secure.usable.check 727
adclient.krb5.conf.file.custom 728
adclient.krb5.conf.domain_realm.anysite 730
adclient.krb5.extra_addresses 731
adclient.krb5.keytab.clean.nonfips.enctypes 732
adclient.krb5.keytab.entries 733
adclient.krb5.keytab.use.all.etypes 734
adclient.krb5.password.change.hook 735
adclient.krb5.password.change.interval 736
adclient.krb5.password.change.verify.interval 737
adclient.krb5.password.change.verify.retries 738
adclient.krb5.passwd_check_s_address 739
adclient.krb5.permitted.encryption.types 740
adclient.krb5.permitted.encryption.types.strict 741
adclient.krb5.principal 742
adclient.krb5.send.netbios.name 743
adclient.krb5.service.principals 744
adclient.krb5.tkt.encryption.types 745
adclient.krb5.tkt.encryption.type.strict 746
adclient.krb5.use.addresses 747
fips.mode.enable 748
krb5.cache.clean 749
krb5.cache.clean.exclusion 750
krb5.cache.clean.force.max 751
krb5.cache.clean.interval 752
krb5.cache.infinite.renewal 753
krb5.cache.infinite.renewal.batch.groups 754
krb5.cache.infinite.renewal.batch.users 755
krb5.cache.renew.exclusion 756
krb5.cache.renew.interval 757
krb5.conf.plugins.ccselect.disable 758
krb5.cache.type 759
krb5.conf.k5login.directory 760
krb5.conf.kcm.socket.path 761
krb5.conf.kcm.socket.path.secure.usable.check 761
krb5.config.update 762
krb5.forcetcp 763
krb5.forwardable.user.tickets 764
krb5.pac.validation 765
krb5.permit.dns.spn.lookups 766
krb5.sso.block.local_user 767
krb5.sso.ignore.k5login 768
krb5.support.alt.identities 769
krb5.unique.cache.files 770
krb5.use.kdc.timesync 771
krb5.verify.credentials 772
krb5.udp.preference.limit 773
Customizing PAM-Related Configuration Parameters 774
Configuring PAM-related parameters on IBM AIX computers 775

Controlling access to AIX computers 775
Explicitly allowing and denying access 775
Changing the configuration of AIX computers 775
pam.account.conflict.both.mesg 776
pam.account.conflict.name.mesg 777
pam.account.conflict.uid.mesg 778
pam.account.disabled.mesg 779
pam.account.expired.mesg 780
pam.account.locked.mesg 781
pam.adclient.down.mesg 782
pam.allow.groups 783
Specifying group names for computers joined to Auto Zone 783
pam.allow.override 784
pam.allow.password.change 785
pam.allow.password.change.mesg 786
pam.allow.password.expired.access 787
pam.allow.password.expired.access.mesg 788
pam.allow.users 789
Specifying user names for computers joined to Auto Zone 789
pam.auth.create.krb5.cache 790
pam.auth.failure.mesg 791
pam.config.program.check 792
pam.create.k5login 793
pam.deny.change.shell 794
pam.deny.groups 795
pam.deny.users 796
pam.homedir.create 797
pam.homedir.create.hook 798
pam.homedir.create.mesg 799
pam.homedir.perms 800
pam.homedir.update.ownership 801
pam.homedir.perms.recursive 802
pam.homeskel.dir 803
pam.ignore.users 804
Skipping Active Directory authentication for local AIX users 804
pam.mapuser.username 805
pam.mfa.program.ignore 806
pam.ntlm.auth.domains 807
pam.password.change.mesg 808
pam.password.change.required.mesg 809
pam.password.confirm.mesg 810
pam.password.empty.mesg 811
pam.password.enter.mesg 812
pam.password.expiry.warn 813
pam.password.expiry.warn.mesg 814
pam.password.new.mesg 815
pam.password.new.mismatch.mesg 816
pam.password.old.mesg 817
pam.policy.violation.mesg 818
pam.setcred.respect.sufficient 819
pam.setcred.support.refresh 820
pam.setcred.support.reinitialize 821
pam.sync.mapuser 822
pam.uid.conflict 823
pam.workstation.denied.mesg 824
microsoft.pam.privilege.escalation.enabled 825
Customizing Group Policy Configuration Parameters 826
gp.disable.all 827
gp.disable.machine 828
gp.disable.user 829
gp.disk.space.check.folders 830
gp.disk.space.min 831
gp.mappers.certgp.pl.additional.cafiles 832
gp.mappers.certgp.pl.exclude.cacerts 833
gp.mappers.directory.machine 834
gp.mappers.directory.user 835
gp.mappers.error_file 836
gp.mappers.machine 837
gp.mappers.runcommand.as.root.env.list 838
gp.mappers.runcommand.as.user 839
gp.mappers.runmappers 840
gp.mappers.timeout 841
gp.mappers.timeout.all 842
gp.mappers.umask 843
gp.mappers.user 844
gp.refresh.disable 845
gp.reg.directory.machine 846
gp.reg.directory.user 847
gp.use.user.credential.for.user.policy 848
gp.user.login.run 849
Customizing NSS-Related Configuration Parameters 850

nss.alias.source 851
nss.gecos.attribute 852
nss.gid.ignore 853
nss.group.ignore 854
nss.group.override 855
nss.group.skip.members 856
nss.nobody.gid 857
nss.nobody.group 858
nss.nobody.uid 859
nss.nobody.user 860
nss.passwd.hash 861
nss.passwd.info.hide 862
nss.passwd.override 863
nss.process_group.ignore 864
nss.program.ignore 865
nss.program.ignore.check.parents 866
nss.shell.emergency.enabled 867
nss.shell.nologin 868
nss.split.group.membership 869
nss.squash.root 870
nss.uid.ignore 871
nss.user.group.prefer.cache 872
nss.user.ignore 873
nss.user.ignore.all 874
nss.watch.slow.lookup.info.threshold 875
nss.watch.slow.lookup.info.threshold.group 876
nss.watch.slow.lookup.info.threshold.user 877
nss.watch.slow.lookup.warn.threshold 878
nss.watch.slow.lookup.warn.threshold.group 879
nss.watch.slow.lookup.warn.threshold.user 880
lam.attributes.group.ignore 881
lam.attributes.user.ignore 882
lam.max.group.count 883
lam.max.user.count 884
Customizing NIS Configuration Parameters 885
log.adnisd 886
log.adnisd.netgroup 887
logger.facility.adnisd 888
nisd.domain.name 889
nisd.exclude.maps 890
nisd.largegroup.name.length 891
nisd.largegroup.suffix 892
nisd.maps 893
nisd.maps.max 894
nisd.net_addr 895
nisd.passwd.expired.allow 896
nisd.port.tcp 897
nisd.port.udp 898
nisd.securenets 899
nisd.server.switch.delay 900
nisd.startup.delay 901
nisd.threads 902
nisd.update.interval 903
Customizing AIX Configuration Parameters 904

Setting extended attributes 905
Enforcing access rights on AIX computers 905
Setting extended attributes 905
aix.cache.extended.attr.enable 907
aix.user.attr.admgroups 908
aix.user.attr.admin 909
aix.user.attr.auditclasses 910
aix.user.attr.core 911
aix.user.attr.cpu 912
aix.user.attr.data 913
aix.user.attr.daemon 914
aix.user.attr.fsize 915
aix.user.attr.nofiles 916
aix.user.attr.nprocs 917
aix.user.attr.rlogin 918
aix.user.attr.rss 919
aix.user.attr.stack 920
aix.user.attr.su 921
aix.user.attr.sugroups 922
aix.user.attr.threads 923
aix.user.attr.tpath 924
aix.user.attr.ttys 925
aix.user.attr.umask 926
Customizing Delinea UNIX programs Configuration Parameters 927

adjoin.adclient.wait.seconds 928
adjoin.krb5.conf.file 929
adjoin.samaccountname.length 930
adpasswd.account.disabled.mesg 931
adpasswd.account.invalid.mesg 932
adpasswd.password.change.disabled.mesg 933
adpasswd.password.change.perm.mesg 934
Customizing Smart Card Configuration Parameters 935
smartcard.allow.noeku 936
smartcard.login.force 937
smartcard.name.mapping 938
smartcard.pkcs11.module 939
rhel.smartcard.pkcs11.module (Deprecated) 940
Customizing Authorization Configuration Parameters 941
adclient.azman.refresh.interval 942
adclient.cache.flush.interval.dz 943
adclient.dz.refresh.hook 944
adclient.dzdo.clear.passwd.timestamp 945
adclient.refresh.interval.dz 946
adclient.sudo.clear.passwd.timestamp 947
adclient.sudo.timestampdir 948
audittrail.dz.command.with.args 949
dz.auto.anchors 950
dz.enabled 951
dz.system.path 952
dz.user.path 953
dzdo.always_set_home 954
dzdo.badpass_message 955
dzdo.command_alias 956
dzdo.edit.checkdir 957
dzdo.edit.follow 958
dzdo.env_check 959
dzdo.env_delete 960
dzdo.env_keep 961
dzdo.lecture 962
dzdo.lecture_file 963
dzdo.legacyzone.mfa.enabled 964
dzdo.log_good 965
dzdo.passprompt 966
dzdo.passwd_timeout 967
dzdo.path_info 968
dzdo.search_path 969
dzdo.requiretty 970
dzdo.secure_path 971
dzdo.set_home 972
dzdo.set.runas.explicit 973
dzdo.timestampdir 974
dzdo.timestamp_timeout 975
dzdo.timestamp_type 976
dzdo.tty_tickets 977
dzdo.use_pty 978
dzdo.use.realpath 979
dzdo.user.command.timeout 980
dzdo.validator 981
dzdo.validator.required 982
dzsh.roleswitch.silent 983
Customizing Auto Zone Configuration Parameters 984

auto.schema.allow.groups 985
Adding zone users based on group membership 985
Supported group name formats 985
Limitations of this parameter 985
auto.schema.allow.users 987
Adding specific Active Directory users to Auto Zone 987
auto.schema.apple_scheme 988
auto.schema.domain.prefix 989
auto.schema.groups 990
auto.schema.homedir 992
auto.schema.primary.gid 993
auto.schema.private.group 994
auto.schema.shell 995
auto.schema.use.adhomedir 996
auto.schema.name.format 997
auto.schema.separator 998
auto.schema.search.return.max 999
auto.schema.name.lower 1000
auto.schema.iterate.cache 1001
auto.schema.uid.conflict 1002
auto.schema.homedir.illegal_chars 1003
auto.schema.thycotic.rids 1004
auto.schema.unix.name.disallow.chars 1005
auto.schema.substitute.chars 1006
auto.schema.max.unix.name.length 1007
Customizing Auditing Configuration Parameters 1008
agent.max.missed.update.tolerance 1009
agent.send.hostname 1010
agent.video.capture 1011
autofix.nss.conf 1012
cache.enable 1013
cache.max.size 1014
cache.time.to.live 1015
cagent.audit.session 1016
dad.client.idle.timeout 1017
dad.collector.connect.timeout 1018
dad.dumpcore 1019
dad.gssapi.seal 1020
dad.gssapi.sign 1021
dad.process.fdlimit 1022
dad.resource.cpulimit 1023
dad.resource.cpulimit.tolerance 1024
dad.resource.fdlimit 1025
dad.resource.memlimit 1026
dad.resource.restart 1027
dad.resource.timer 1028
dad.timer.diskspace 1029
dad.timer.monitor.nss.conf 1030
dash.allinvoked 1031
dash.auditstdin 1032
dash.auditstdin.except 1033
dash.cmd.audit.blacklist 1034
dash.cmd.audit.show.actual.user 1035
dash.cont.without.dad 1036
dash.force.audit 1037
dash.loginrecord 1038
dash.obfuscate.pattern 1039
dash.obfuscate.regex 1040
dash.obfuscate.stdin 1041
dash.parent.skiplist 1042
dash.prompt.message.file 1043
dash.reconnect.dad.retry.count 1044
dash.reconnect.dad.wait.time 1045
dash.select.timeout 1046
dash.shell.env.var.set 1047
dash.ssh.command.skiplist 1048
dash.user.alwaysallowed.list 1049
dash.user.skiplist 1050
event.execution.monitor 1051
event.execution.monitor.user.skiplist 1052
event.file.monitor 1053
event.file.monitor.process.skiplist 1054
event.file.monitor.user.skiplist 1055
event.monitor.commands 1056
event.monitor.commands.user.skiplist 1057
lang_setting 1058
lrpc2.message.signing 1059
lrpc2.timeout 1060
lrpc2.rebind.timeout 1061
nss.alt.zone.auditlevel 1062
nss.nologin.shell 1063
nss.user.conflict.auditlevel 1064
nss.user.override.auditlevel 1065
nss.user.override.userlist 1066
preferred.audit.store 1067
prefer.site.over.subnet 1068
spool.diskspace.logstate.reset.threshold 1069
spool.diskspace.min 1070
spool.diskspace.softlimit 1071
spool.maxdbsize 1072
uid.ignore 1073
user.ignore 1074
user.ignore.audit.level 1075
Customizing LDAP Proxy Configuration Parameters 1076
ldapproxy.cache.credential.expire 1077
ldapproxy.netgroup.use.rfc2307nisnetgroup 1078
ldapproxy.performance.log.interval 1079
Group Policy Guide 1080
Using this Guide 1080

Group Policies in Active Directory 1081
Configuring Computer and User Settings 1082
How Group Policies are Applied 1083

To create a new Group Policy Object 1083
Order in which Policies are Applied 1083
How the Resulting Policy Set is Determined 1083
Editing a Group Policy Object 1085
Selecting Computer or User Settings 1086
Applying Policies in Nested Organizational Units 1087

Enable the Loopback Policy 1087
Configuring Group Policies to be Refreshed 1088
Server Suite Group Policy Overview 1089
Mapping Settings to a Virtual Registry 1090
Configuring Settings in Administrative Templates 1091
Mapping Computer Configuration Policies 1092

Mapping User Configuration Policies 1093
Editing Configuration Settings Manually 1094
Updating Configuration Policies Manually 1095
Using Standard Windows Group Policies 1096
Reporting group policy settings 1097

Generating a report of Delinea group policies 1097
Adding Centrify Settings to Group Policy Objects 1098
Configuring Audit Event Logging Location by Group Policy 1099
Adding Administrative Templates to a Group Policy Object 1100

Installing Centrify Group Policy Templates 1100
Template File Formats 1100
Selecting a Group Policy Object for Centrify Settings 1100
Linking a Group Policy Object to an Organizational Unit 1101

Create and Link a Group Policy Object for Centrify Settings 1101
Using Security Filtering for Group Policies 1101
To enable security filtering of group policies: 1101
Adding Policies from XML Files 1102

Adding Templates after an Upgrade 1102
Enabling Delinea Policies 1103

To enable and configure Delinea settings: 1103
Delinea Policy Limitations 1104
DirectControl Settings 1105
Add centrifydc.conf properties 1106
Enable Active Directory PAM Privilege Escalation Feature 1107
Maintain DirectControl 2.x compatibility 1108

Merge Local Group Membership 1109
Prefer Authentication Credentials Source 1110
Set LDAP Fetch Count 1111
Set Password Cache 1112
Set User Mapping 1113

User's Initial Group ID 1114
Use FIPS 140-2 compliance algorithms 1115

Basic requirements 1115
Enabling the Policy 1115
Related configuration parameters 1116
Account Prevalidation 1117
Specify Allowed Groups for Prevalidation 1118
Specify Allowed Users for Prevalidation 1119
Specify Denied Groups for Prevalidation 1120
Specify Denied Users for Prevalidation 1121
Set Prevalidation Service Name 1122
Setting the Service Principal Name for a User 1122
Setting the Service Principal Name for Group Members 1122
Set Prevalidation Update Interval 1123
Refreshing Prevalidated Credentials 1123
Adclient Settings 1124
Add Attributes to Cached Objects 1125
Auto Zone Group Policies 1126
Auto Zone Default Shell 1127
Auto Zone Domain Prefix Overrides 1128
Auto Zone Home Directory 1129
Auto Zone Remote File Service (Mac OS X) 1130
Generate New UID/GID using Apple Scheme in Auto Zone 1131
Set User's Primary GID in Auto Zone 1132
Specify AD Groups Allowed in Auto Zone 1133
Specify AD Users Allowed in Auto Zone 1134
Specify Groups of AD Users Allowed in Auto Zone 1135
Configure /etc/nsswitch.conf (Solaris, HPUX, Linux) 1136
Configure /etc/{pam.conf,pam.d} (AIX, Solaris, HPUX, Linux, Mac OS X) 1137
Configure /etc/security/user (AIX) 1138
Configure /usr/lib/security/methods.cfg (AIX) 1139
Configure Directory Services (Apple OS/X) 1140
Configure Dump Core Setting 1141
Disable Multi-Factor Authentication (MFA) on Delinea-Managed Computers 1142
Disable nscd Group and passwd Caching (Solaris, Linux) 1143
Disable pwgrd (HPUX) 1144
Enable Core Dump Cleanup 1145
Enable Logon Hours Local Enforcement 1146
Encrypt adclient Cache Data 1147
Force Domains and Forests to be One-Way Trusted 1148
Force Password Salt Lookup from KDC 1149
Map /home to /User (Mac OS X) 1150
Run adclient on all Processors 1151
Set Cache Cleanup Interval 1152
Set the Connector Refresh Interval 1153
Set the Heartbeat Interval ( 1154
Set Maximum Number of Threads 1155
Set the Maximum Simultaneous Authentication Requests Allowed 1156
Set Minimum Number of Threads 1157
Specify Low Disk Space Interval 1158
Specify Low Disk Space Warning Level 1159
Specify a Per Machine (Random) Delay for Cache Refreshed Background Tasks 1160
Use the Legal Kerberos Type for Cache Encryption 1161
addns Settings Group Policies 1162
Enable addns Invoked by adclient 1163
Set Command Line Options Used by adclient 1164
Set DNS Records Update Interval 1165
Set Wait Response Interval for Update Requests 1166
dzdo Settings 1167
Always Add Anchors to Regex in dzdo and dzcmds 1168
Enable Logging of Valid Command Execution in dzdo 1169
Enable User Command Timeout 1170
Force dzdo Re-Authentication when Relogin 1171
Force dzdo to Set HOME Environment Variable 1172
Force dzdo to Set HOME Environment Variable when Runs with ‘-s’ Option 1173
Force per tty Authentication in dzdo 1174
Prompt Error Message if Command not Found by dzdo 1175
Replace sudo by dzdo 1176
Require dzdo Command Validation Check 1177
Require runas User for dzdo 1178
Require User is Logged in to a Real tty to Run dzdo 1179
Set Directory to Store User Timestamp by dzdo 1180
Set dzdo Authentication Timeout Interval 1181
Set dzdo Password Prompt Timeout Interval 1182
Set dzdo Validator 1183
Set Environment Variables to be Preserved by dzdo 1184
Set Environment Variables to be Removed by dzdo 1185
Set Environment Variables to be Removed by dzdo with Characters % or / 1186
Set Error Message when Failed to Authenticate in dzdo 1187
Set Lecture Shown by dzdo Before Password Prompt 1188
Set Password Prompt for Target User Password in dzdo 1189
Set Paths for Command Searching in dzdo 1190
Set Secure Paths for Command Execution in dzdo 1191
Show Lecture by dzdo Before Password Prompt 1192
Use realpath to canonicalize Command Paths in dzdo 1193
Set the Type of Time Stamp Record 1194
Group Policy Settings 1195
Enable User Group Policy 1196
Group Policy Commands Environment Variable List Running as Root 1197
Set Group Policy Mapper Execution Timeout 1198
Set Machine Group Policy Mapper List 1199
Set User Group Policy Mapper List 1200
Set Total Group Policy Mappers Execution Timeout 1201
User Group Policy Commands Run as User 1202
Use User Credential to Retrieve User Policy 1203
Kerberos Settings 1204
Allow PAM to Create User Kerberos Credential Cache 1205
Allow Weak Encryption Types for Kerberos Authentication 1206
Alternative Location for Credential Cache Directory 1207
Alternative Location for User .k5login Files 1208
Disable Kerberos Built-in ccselect Plugins 1209
Enable Kerberos Clients to Correct Time Difference 1210
Force Kerberos to Only use TCP 1211
Generate the Forwardable Tickets 1212
Generate Kerberos Version Numbers for Windows 2000 1213
Manage Kerberos Configuration 1214
Renew Credentials Automatically 1215
Set Configuration Update Interval 1216
Set Kerberos UDP Preference Limit 1217
Set Credential Renewal Interval 1218
Set Password Change Interval 1219
Set Password Change Verification Interval 1220
Set Password Change Verification Attempts 1221
Specify Credential Cache Type for AD Users 1222
Specify Groups to Infinitely Renew Kerberos Credentials 1223
Specify Maximum Kerberos Credential Cache Lifetime 1224
Specify Users to Infinitely Renew Kerberos Credentials 1225
Specify Whether CDC k5login Module Should Ignore .k5login for SSO 1226
Specify Whether Kerberos PAC Checksum Validation Should be Done 1227
Strictly Enforce Default Encryption Types 1228
Strictly Enforce Permitted Encryption Types 1229
Use DNS to Lookup KDC 1230
Use DNS to Lookup Realms 1231
Local Account Management Settings 1232
Enable Local Account Management Feature 1233
Notification Command Line 1234
Logging Settings 1235
Set adclient Audit Logging Facility 1236
Set General Audit Logging Facility 1237
Set Log Message Queue Size 1238
Set NIS Audit Logging Facility 1239
Login Settings 1240
Allow Localhost Users 1241
Allow Offline Login when User Account is Locked Out 1242
Enabled nss Emergency Shell 1243
Manage Login Filters 1244
Set Minimum Group ID (Lookup) 1245
Set Minimum User ID (Lookup) 1246
Set Sync Mapped Users 1247
Specify Group Names to Ignore 1248
Specify the Certificate Files to Add (Lookup) 1249
Specify the Fingerprints of Certificate Files to Ignore (Lookup) 1250
Specify User Names to Ignore 1251
Split Large Group Membership 1252
MFA Settings 1253
Enable Multi-Factor Authentication for Auto Zone and Classic Zone 1254
Set Background Fetch Interval for Groups that Require Multi-Factor Authentication 1255
Specify Centrify Identity Platform Tenant ID for Multi-Factor Authentication 1256
Specify AD Users that can Login when Multi-Factor Authentication is Unavailable 1257
Specify AD Groups that Require Multi-Factor Authentication 1258
Specify AD Users that Require Multi-Factor Authentication 1259
Specify Delinea Identity Platform URL for Multi-Factor Authentication 1260
Network and Cache Settings 1261
Blacklist DNS DC Hostnames 1262
Enable LDAP Cross-Forest Search 1263
Enable User Lookup and Login by CN 1264
Enable User Lookup and Login by displayName 1265
Force DNS to Use TCP 1266
Force DNS to Rotate 1267
Force Switching to Different Domain Controller in the Preferred Site Periodically 1268
Set Cache Negative Life Time 1269
Set DNS Cache Size 1270
Set DNS Cache Timeout 1271
Set DNS Cache Timeout (Deprecated) 1271
Set DNS UDP Buffer Size 1272
Set Domain DNS Refresh Interval 1273
Set GC Expiration 1274
Set Group Object Expiration 1275
Set Idle Client Timeout 1276
Set LDAP Connection Timeout 1277
Set LDAP Response Timeout 1278
Set LDAP Search Timeout 1279
Set LDAP Trust Timeout 1280
Set LRPC Response Timeout 1281
Set LRPC2 Receive Timeout 1282
Set LRPC2 Send Timeout 1283
Set Maximum Server Connection Attempts 1284
Set Object Expiration 1285
Set Refresh Interval for Access Control Cache 1286
Set UDP Timeout 1287
Set User Object Expiration 1288
Specify AD to NTLM Domain Mappings 1289
Specify DNS DC Hostnames 1290
Specify DNS GC Hostnames 1291
Specify IP Port Range that adclient Should Use 1292
NIS Daemon Settings 1293
Set Thread Number for NIS Daemon 1294
Specify NIS Daemon Update Interval 1295
Specify Allowed NIS Mapping Files for NIS Daemon 1296
Specify Disallowed NIS Mapping Files for NIS Daemon 1297
Specify Allowed Client Machines for NIS Daemon 1298
Set Switch Delay Time for NIS Daemon 1299
Set Maximum Number of Mapping Files Allowed for NIS Daemon 1300
Set Large Group Suffix for NIS Daemon 1301
Set Large Group Name Length for NIS Daemon 1302
Set Domain Name for NIS Daemon 1303
Set Startup Delay Time for NIS Daemon 1304
NSS Overrides 1305
Specify NSS Group Overrides 1306
Specify NSS Password Overrides 1307
PAM Settings 1308
Create Home Directory 1309
Create k5login 1310
Set Home Directory Permissions 1311
Set Multi-Factor Authentication to Use an External PAM Module 1312
Set Options for Multi-Factor Authentication by an External PAM Module 1313
Set UID Conflict Message 1314
Set UID Conflict Resolution 1315
Set User Name and UID Conflict Message 1316
Update Home Directory Ownership 1317
Set User Name Conflict Message 1318
Specify Message for Creating Home Directory 1319
Specify NTLM Authentication Domains 1320
Specify Programs for which Multi-Factor Authentication is Ignored 1321
Password Prompts 1322
Set Account Disabled Error Message 1322
Set Account Expired Error Message 1322
Set Account Locked Message for adpasswd 1322
Set adclient Inaccessible Message 1322
Set Password Change Disallowed Message for adpasswd 1322
Set Invalid User or Password Message for adpasswd 1322
Set Permission Denied Message for adpasswd 1322
Set Lockout Error Message 1322
Set Error Message for Empty Password Entered 1322
Set New Password’s Mismatch Error Message for Password Change 1322
Set Notification Text for Password Change 1322
Set Old Password Incorrect Error Message for Password Change 1323
Set Violation Error Message for Password Change 1323
Set Password Prompt for Confirming New Password Change 1323
Set Password Prompt for New Password Change 1323
Set Password Prompt for Old Password Change 1323
Set Message Text for Password Change 1323
Set Login Password Prompt 1323
Set Password Expiry Approaching Text 1323
Set Workstation Denied Error Message 1323
Sudo Settings 1324
Force sudo Re-Authentication when Relogin 1324
Window Settings 1325
Common Settings 1326
Configure Heartbeat Message for Centrify Analytics and SIEM (Windows) 1327
Configure Windows Authentication Grace Period for Run with Alternate Account 1328
Configure Windows Authentication User Privilege Elevation Grace Period 1329
Custom Message for Locked User Accounts 1330
Disable the Centrify Notification Icon 1331
Enable Run with Alternate Account 1332
Enable Setup Centrify Offline MFA Profile 1333
Enable Use of Alternate User's Role to Run an Application 1334
Hide Command Line Arguments in Analytics 1335
Prevent Local Administrators from Being Able to Log On in Rescue Mode (When There are No Explicit Rescue Users
Defined) 1336
Re-Authentication: Require Smart Card 1337

Require Justification on Privilege Elevation 1338
Require Re-Authentication to Run Application with Alternate Account 1339
Specify a List of Blacklisted Domains 1340
Specify a List of Rescue Users (When the Agent is not Joined to a Zone) 1341
Specify a List of Whitelisted Domains 1342
Specify Offline MFA Profile Desktop Notification Message 1343
Specify a Privilege Elevation Validator 1344
Specify Whether to Keep the Desktop Notification Permanently Visible 1345
Local Account Management 1346
Enable Local Account Management Feature 1347
Enforce Local Account Management Feature 1348
Synchronization Interval 1349
Notification Command Line 1350
MFA Settings 1351
Configure Multi-Factor Authentication for Logon when the Agent Cannot Connect to the Platform 1352
Configure Multi-Factor Authentication for Privilege Elevation when the Agent Cannot Connect to the Platform 1353
Connect to the Centrify Platform Directly 1354
Continue with MFA Challenges after Failed Windows Authentication in Logon Screen 1355
Disable Multi-Factor Authentication for Screen Unlock 1356
Disable Self-Service Password Reset 1357
Enable Multi-Factor Authentication for Windows Login (when the Agent is not Joined to a Zone) 1358
Force to Enter Explicit UPN 1359
Send UUID for MFA Challenges 1360
Skip Client Certificate Authentication 1361
Specify a Web Proxy URL 1362
Specify Active Directory Users that Require Multi-Factor Authentication on Windows Login (when the Agent is not Joined
to a Zone) 1363
Specify How Frequently to Check for Responses to Multi-Factor Authentication Challenges 1364
Specify the Multi-Factor Authentication Grace Period 1365
Applying the MFA Lock Screen Grace Period to Remote Sessions 1365
Specify the Authentication Source for Privilege Elevation 1366
Specify the Centrify Connector URL to Use 1367
Specify the Connection Timeout for Multi-Factor Authentication Requests 1368
Specify Credential Providers to Exclude from the Logon Screen 1369
Specify the Platform Instance Id to Use (when the Agent is Not Joined to a Zone) 1370
Specify the Platform Instance URL to Use 1371
Specify the Platform Instance URL to Use (when the Agent is Not Joined to a Zone) 1372
Specify the Timeout on Skipping Previously Disconnected Centrify Connectors 1373
Specify the timeout on Using the Last Successfully Connected Centrify Connector First 1374
Remote Authentication Dial-In User Service (RADIUS) Settings 1375
Enable Remote Authentication Dial-In User Service (RADIUS) 1376
Specify the RADIUS Connection Timeout 1377
Specify the RADIUS Server IP Address 1378
Specify the RADIUS Server Port Number 1379
Audit and Audit Trail Settings 1380

Alternate Location for Policies Installed with an ADMX Template 1381
Audit Trail Settings 1382
Audit Trail Snap-In Policies 1383
Audit Trail ADMX Template Policies 1384
Send Audit Trail to Audit Database 1385
Send Audit Trail to Log File 1386
Audit Trail Overrides 1387
Audit Trail Targets 1388
Centrify Audit Settings 1389
Installation 1391
Set the Match Order of Audit Store 1392
Set Maximum Missed Status Update Tolerance 1393
Set the Preferred Audit Store 1394
Set Video Capture Auditing of User Activity 1395
Use the Host Name Specified by the Agent 1396
Collector Settings 1397
Do Not Audit Output of Specified UNIX Commands 1397
DirectAudit Advanced Monitoring 1398
Enable Advanced Monitoring 1399
Set Monitor of Program Execution for Audit Sessions 1400
Set Monitored Programs List 1401
Set Monitoring of System Configuration Files 1402
Set Processes that are Skipped for System Configuration File Monitoring 1403
Set Skip Users for Monitored Program Executions 1404
Set Users that will be Skipped for Program Execution Monitoring 1405
Set Users Who will be Skipped for System Configuration File Monitoring 1406
UNIX Agent Settings 1407
Add centrifyda.conf Properties 1408
Enable DirectAudit Session Auditing Properties 1409
DirectAudit Daemon Settings 1410
Set Allow to Dump Core 1411
Set Audit Level of Ignored User 1412
Set Cache Live Time 1413
Set Cache the Query Results 1414
Set Check NSS Configuration File Timeout 1415
Set Client Idle Timeout 1416
Set Codepage of Audit Client 1417
Set Connect to Collector Timeout 1418
Set Fix NSS Configuration File Automatically 1419
Set Max Cache Size 1420
Set Resource Monitor Check Interval 1421
Set Resource Monitor CPU Limit 1422
Set Resource Monitor CPU Limit Tolerance 1423
Set Resource Monitor File Descriptor Limit 1424
Set Resource Monitor Memory Limit 1425
Set Resource Monitor Should Restart dad 1426
Set Seal Over a Secure GSSAPI Connection Collector 1427
Set Sign Over a Secure GSSAPI Connection with Collector 1428
Set Soft Limit of Open Files 1429
Set Update Agent Status Timeout 1430
Set Verification of Spool Disk Space Timeout 1431
Direct Audit NSS Settings 1432
Override Audit Level for a List of Users 1433
Set Audit Level for Conflict User 1434
Set Audit Level for Users Listed in uid.ignore 1435
Set Ignored Programs 1436
Set No-Login Shells 1437
Set Override Audit Level for Non-Hierarchical Zone Users 1438
DirectAudit Shell Settings 1439
Defining Information Pattern in Custom Format to Obfuscate Sensitive Information 1440
Defining Information Pattern in Regex Format to Obfuscate Sensitive Information 1441
Set Always Allowed Unix User Name List 1442
Set Audit All Invocations 1443
Set Audit Commands 1444
Set Audit STDIN Data 1445
Set Continue Working Without dad 1446
Set Except Auditing Password Strings 1447
Set Force Audit List 1448
Set Not Audited ssh Command List 1449
Set Parent Process Skip List 1450
Set Reconnect to dad Timeout 1451
Set Reconnect to dad Times 1452
Set Record Login Entry 1453
Set SHELL to Actual User Shell 1454
Set Skip Auditing Userlist 1455
Show Actual User Running an Audited Command 1456
LPRC2 Client Settings 1457
Set Contact with dad Timeout 1458
Set Contact with dad Timeout for Rebinding Collector 1459
Spool Disk Space Settings 1460
Set Maximum Disk Space for DB File Size 1461
Set Minimum Percentage of Disk Space 1462
Set Soft Limit Percentage of Disk Space 1463
Set Threshold Percentage of Disk Space to Reset Log State 1464
Windows Agent Settings 1465
Allow Selected Administrative Users to Stop the Auditing Service 1466
Audited User List 1467
Non-Audited User List 1468
Set Maximum Recorded Color Quality 1469
Set Maximum Size of the Offline Data File 1470
Set Update Agent Status Timeout 1471
Additional Group Policies for UNIX Services 1472

Common UNIX Settings 1473
Copy Files 1474
Copy Files from SYSVOL 1475
Sudo Rights 1476
Set crontab Entries 1478
Specify Commands to Run 1479
Linux Settings 1480
Enforce Screen Locking 1481
Specify Basic Firewall Settings 1482
Specify Network Login Message Settings 1483
Security 1484
Certificate Validation Method 1485
Enable Smart Card Support 1486
Specifying the PKCS #11 Module 1487
Lock Smart Card Screen for RHEL 1488
Require Smart Card Login 1489
Specify Applications to Import System NSSDB 1490
SSH (Secure Shell) Settings 1491
Add sshd_config Properties 1492
Allow Challenge-Response Authentication 1493
Allow Groups 1494
Allow GSSAPI Authentication 1495
Allow GSSAPI Key Exchange 1496
Allow Users 1497
Deny Groups 1498
Deny Users 1499
Enable Application Rights 1500
Enable PAM Authentication 1501
Enable SSO MFA Properties 1502
Match Block 1503
Permit Root Login 1504
Set Banner Path 1505
Enable Rlogin Control SFTP 1506
Enable Rlogin Control SSH 1507
Specify Authorized Key File 1508
Specify Ciphers Allowed for Protocol Version 2 1509
Specify Client Alive Interval 1510
Specify Log Level 1511
Specify Login Grace Period 1512
Specify Maximum Client Alive Count 1513
Mac OS X Settings 1514

Group Policies and System Preferences 1515
Adding Mac OS X Group Policies 1516
Installing the Administrative Template 1517
Installing the Agent and System Files 1518
Enabling and Disabling Mac OS X Group Policies 1519

Setting Mac OS X Computer Policies 1520
Setting Mac OS X User Policies 1521
GNOME Settings 1522
GNOME Desktop Preferences 1523
Adding GNOME Group Policy Templates 1524

Setting GNOME Policies 1525
Verifying GNOME Policy Settings 1526
Troubleshooting GNOME Policy Settings 1527
Using the Enable GNOME Group Policy 1528
Creating custom GNOME Settings Through Group Policy 1529

Defining Custom Group Policies 1530
Implementing Custom Group Policies 1531
Creating a Custom Administrative Template 1532
Defining a Policy 1533
Defining the User Interface for a Policy 1535
Using String IDs 1537
Validation Settings 1538
Adding a Mapper Program to the Agent 1540
Network Information Services 1541
Introduction to the Basics of NIS 1541
Limitations of using NIS 1541

Deciding to Maintain NIS in your Environment 1541
Using the Network Information Service 1542
How NIS Client Requests are Processed 1542

Derived and Explicitly-defined Maps 1542
Accessing NIS Maps in the Local Cache 1542
Migrating Information from Existing Maps 1543
Managing Automounts without Using NIS 1543
Mounting Home Directories with the nosuid Option 1545
Using Executable Maps 1545
Testing the Status of the Automount Service 1545
Testing the adauto.pl script results 1546
Restarting the Automount Service 1546
Distributing Automount Maps 1546
Discontinuing Use of Legacy NIS Servers 1547
Preparing for Agentless Authentication for NIS Clients 1548

Deciding to Use Agentless Authentication 1548
Planning for Agentless Authentication 1548
Selecting a Zone to Use for NIS Authentication 1549
Selecting a Computer for NIS Authentication 1550
Configuring a Password Synchronization Service 1550

Using Delinea Password Synchronization 1550
Using Microsoft Password Synchronization Service 1551
Locating Zones for Password Synchronization 1551
Configuring the Centrify NIS server 1553
Installing the Centrify NIS Server 1553

Adding IP Addresses from Which to Accept Requests 1553
Starting the adnisd Process 1554
Customizing the Update Interval for NIS Maps 1554
Customizing the NIS Maps to PUblish 1555
Configuring the Maximum Number of Map Sets 1555

Handling Large Active Directory Groups 1555
Splitting a single large group into multiple new groups 1555
Setting the maximum length of new group names 1556
Making the NIS Server Available 1556
Configuring NIS Clients 1557

Specifying the Server for NIS Clients to Use 1557
Configuring NIS Clients on Linux 1557
Configuring NIS Clients on Solaris 1558
Configuring NIS Clients on HP-UX 1558
Configuring NIS Clients on AIX 1559

Verifying the Client Configuration 1559
Checking the Derived passwd and Group Maps 1559
Importing and Managing NIS Maps 1561
Importing and Creating User and Group Profiles 1561
Publishing Network or Custom Information 1561

Importing Network NIS Maps 1561
Creating New NIS Maps in Active Directory 1562
Creating Maps for Common Network Services 1563
aliases 1563
audit_user 1564
auth_attr 1564
bootparams 1565
ethers 1565
exec_attr 1566
hosts 1566
netgroup 1567
netmasks 1567
networks 1568
printers 1568
prof_attr 1569
project 1569
protocols 1570
rpc 1570
services 1571
user_attr 1572
Creating Generic Custom Maps 1572
Changing the Map Type 1573
Maintaining Map Records in Active Directory 1573
Modifying Map Records in Active Directory 1573
Deleting a map stored in Active Directory 1573
Troubleshooting and Logging NIS Operations 1575
Analyzing Zones for Potential Issues 1575
Verifying NIS Configuration for Servers and Clients 1575
Updating the Startup Sequence 1576
Using NIS Command Line Utilities 1576

Configuring Logging for adnisd 1577
The following topics are available in the Smart Card Configuration Guide: 1578
Smart Card for Red Hat Linux 1579
Why and How to Use a Smart Card to Log On 1579
Configuring Smart Card Authentication 1580
Before Configuring Smart Card Authentication 1581

Enabling Smart Card Support 1582
Steps 1582
To Enable Smart Card Support Using Group Policy 1582
To Manually Enable Smart Card Support Running sctool 1583
To Manually Enable Smart Card and Specify a Different PKCS 1583
Next Steps 1584
Enabling Support for Multi-User Smart Cards 1585
Enforcing Smart Card Authentication 1586

Steps 1586
To require smart card login, complete one of these procedures 1586
To require smart card login for all users on a computer 1586
To require smart card login for a specific user 1586
Configuring Certificate Validation 1588

To Configure How Certificates are Validated 1588
Locking Screen if Smart Card is Removed 1589

Enabling a Certificate Without Extended Key Usage 1590
Configuring Applications for Smart Card Access 1591
Steps 1591
To configure NSS database synchronization 1591
Configuring Citrix VDA Smart Card Authentication 1592

Verifying Smart Card Authentication 1594
Using a Smart Card at Login 1596
How the Login Screen Appears for a Single-User Card 1597
How Login Screen Appears for a Multi-User Card 1598

Screen Saver Shows Password Not PIN Prompt 1598
What Happens After Login 1599
Disabling Smart Card Support 1600
To Disable Smart Card Support by Using Group Policy 1600
To Disable Smart Card Support by Running sctool 1600
Troubleshooting Smart Card Login 1601
Administration Guides 1602
Administering Linux / Unix 1603
Server Suite for Linux and UNIX 1604
Why Securing Access is Crucial 1605

Why Managing User Account Information Might be a Problem 1605
Why Managing Access and Privileges Might be a Problem 1605
How Centrify can Reduce Security Risks 1605
Secure Authentication and Identity Management 1605
Role-based Access Rights 1605
Delegation of Authority 1605
Auditing of Activity 1606
How Zones Help you Organize Information 1606
Improving Security: Access and Privilege Management 1607
Consolidating User Account Information 1607
Defining Role-based Access Rights 1607
Improving Accountability: Auditing User Activity 1608
Why auditing User Activity is Important 1608
Reviewing User Activity 1608
Using Access and Auditing Features Together 1609

Enabling Access Control without Auditing on a Managed Computer 1609
Enabling Auditing without Access Control on a Managed Computer 1609
Enabling Access Control and Auditing on a Managed Computer 1609
Managing Zones and Delegating Administrative Tasks 1610
Starting Access Manager for the First Time 1611

What to do Before Updating Active Directory 1611
Rights Required for this Task 1611
Who Should Perform this Task 1611
How often you Should Perform this Task 1611
Steps for Completing this Task 1612
What to Do Next 1613
Where you can Find Additional Information 1613
Preparing to Create Zones 1614
Creating Hierarchical Zones 1614
Creating Classic Zones 1614
Creating an Auto Zone 1614
Creating a New Parent Zone 1616
What to do before creating a new parent zone 1616
Rights required for this task 1616
Who should perform this task 1616
How often you should perform this task 1616
Steps for completing this task 1616
What to do next 1617
Where you can find additional information 1617
Creating Child Zones 1618

What to do before creating child zones 1618
Opening and Closing Zones 1619

Loading all zones 1619
Closing individual zones 1619
Delegating administrative tasks 1619
What to do before delegating administrative tasks 1620
Changing Zone Properties 1622

Changing the zone description 1622
Changing the parent zone or location of a zone 1623
Selecting the default location when moving a zone 1623
Moving a zone without changing its Active Directory location 1623
Restarting the agent after moving a zone 1623
Setting the master domain controller for a zone 1624
Selecting a license container for a zone 1624
Adding support for agentless clients 1624
Setting custom permissions for a zone 1625
Selecting a identity platform instance for a zone 1625
Configuring default values for a zone 1625
Setting user defaults 1625
Setting group defaults 1626
Configuring variables for a zone 1626
Adding custom runtime variable 1627
Modifying predefined variable values 1627
Editing or removing variables 1627
Configuring automated provisioning 1627
Renaming a Zone 1629
What to do before renaming a zone 1629
Adding Computers to a Zone 1630
Managing Licenses 1631
Reporting Zone Information 1632

Migrating from Classic to Hierarchical Zones 1633
Preparing for migration 1633
Verifying you have upgraded Access Manager 1633
Verifying you have upgraded UNIX agents 1633
What the migration utility does 1633
Using the migration utility 1633
Sample migration 1634
Inheritance and overrides 1635
Roles and rights for migrated users 1635
Assigning the audit level when migrating 1636
Moving joined computers to hierarchical zones 1636
What to do after the migration 1636
Managing Account Profiles and Identity Attributes 1638
Creating Group Profiles 1639

Creating group profiles for Active Directory groups 1639
What to do before creating a new Active Directory group profile 1639
Creating, modifying, and deleting group profiles for local groups 1640
What to do before creating a new local group profile 1640
Using partial profiles and child zones to fine tune group attributes 1641
Specifying profile states 1641
Roles and local group account visibility 1641
How often Access Manager and local group accounts are synchronized 1641
Delegating control of local group management tasks 1644
Migrating Local Group Profiles to Active Directory 1645
Making Group Membership a Requirement 1646
Creating User Profiles 1647

Creating user profiles for Active Directory users 1647
What to do before creating a new Active Directory user profile 1647
Changing the default profile attributes 1648
Defining partial UNIX profiles 1649
Defining valid login names 1649
Identifying a primary group 1649
Creating, modifying, and deleting user profiles for local users 1649
What to do before creating a new local user profile 1650
Using partial profiles and child zones to fine tune user attributes 1650
Specifying profile states 1650
Roles and local user account visibility 1650
How often Access Manager and local user accounts are synchronized 1651
Delegating control of local user management tasks 1654
Creating and managing local user passwords 1654
Setting Runtime Variables in User Profiles 1656

Using Active Directory attributes as variables 1657
Using other attributes in a profile 1657
Attributes for users in a forest with a one-way trust 1657
Adding custom variables to a zone 1658
Importing Local Account Profiles 1659

Collecting account information 1659
Using variables when importing UNIX users 1659
Using the Import from UNIX wizard 1659
Checking for conflicts and matching candidates 1660
Mapping UNIX profiles to Active Directory accounts 1661
Accepting the Active Directory candidate 1661
Creating a new Active Directory account 1661
Adding a profile to an existing Active Directory account 1661
Merging pending group members into an existing group 1661
Deleting a UNIX profile for a pending group or user 1662
Viewing or modifying properties for a pending group or user 1662
Resolving errors and conflicts 1662
Resolving warnings 1662
Overriding and modifying user properties 1663
Overriding and Modifying Group Properties 1664
Adding Users or Groups from a Trusted Forest 1665

Identifying users from remote forests 1665
Valid login names for users from a remote forest 1665
Adding Multiple Profiles for a User to a Zone 1666
Enabling and Disabling Users in Classic Zones 1667

Forcing Replication for Read-Only Domain Controllers 1668
Using Configuration Parameters and Group Policies 1669

Enabling and configuring local account management 1669
Group Policies 1669
Configuration Parameters 1669
Authorizing Basic Access 1671
Basic concepts of Access Rights and Roles 1672
System Rights Authorize Access in Role Definitions 1673
Access Rights Defined in the UNIX Login Role 1674
Default Access Rights and Roles 1675

Default PAM access rights 1675
Default secure shell (SSH) access rights 1675
Predefined role definitions 1675
Identifying the Scope for Role Definitions 1677
Assigning the UNIX Login Role 1678

What to do before assigning the UNIX Login role 1678
Where you can find additional information 1679
Performing Role Assignment on Multiple Computers 1680
Viewing Rights and Roles 1681

Checking rights and roles with the dzinfo program 1681
Changing the Audit Level for Role Definitions 1683
Requiring Multi-Factor Authentication to Log On 1684
Defining Rights to Use Commands 1685
Controlling Access to Commands 1686

What Command Rights Provide 1687
Granting access using command rights 1687
Restricting access using command rights 1687
Controlling the Shell Environment for Commands 1688
Defining Rights to Run Privileged Commands 1689

Creating a role to run commands with elevated privileges 1690
Defining a Restricted Shell Command Right 1692
What the restricted shell provides 1692
Limitations of the restricted shell 1692
Securing the restricted shell environment 1692
Creating a role to run commands in a restricted shell 1693
Selecting the Pattern Matching Syntax 1694
Customizing Environment Variables for Command Execution 1695

Resetting environment variables 1695
Removing environment variables 1695
Adding environment variables 1695
Customizing Command Execution Attributes 1696

Requiring re-authentication to run commands 1696
Preserving group membership 1696
Allowing nested commands 1696
Preventing unsafe path navigation 1696
Setting the umask value 1697
Setting the command digest 1697
Testing Command Rights 1698
Using Command Rights in a Standard Shell 1699
Using Command Rights in a Restricted Shell Environment 1700

Running unauthorized commands 1700
Setting or changing the active role 1700
Viewing available roles 1700
Using a graphical desktop manager in a restricted environment 1700
Defining rights to use PAM applications 1701
How applications determine access rights 1702
Default PAM access rights 1703
Adding Specific PAM Access Rights 1704

What to do before creating a new access right 1704
Modifying an existing PAM access right 1706

Copying a PAM access right 1707
Renaming a PAM access right 1709

Using PAM-enabled applications 1710
Requiring multi-factor authentication for PAM applications 1711

Options applied to the Centrify PAM module 1711
Using secure shell session-based rights 1713
Secure shell rights require Centrify OpenSSH 1714

Secure shell rights require PAM access rights 1715
Combining secure shell rights 1716
Configuring secure shell settings 1717
Configuring secure shell parameters 1719
Creating and assigning custom role definitions 1720

Combining rights into role definitions 1721
Creating a root-equivalent role definition 1722

Define the right for running all commands 1722
Create a role definition for running all commands 1722
Assign an Active Directory group to the role 1723
Creating a role definition for a shared service account 1724

Define the right for switching to a service account 1724
Define a PAM access right to allow logging on 1724
Create a restricted role definition for the service account 1725
Assign an Active Directory group to the role 1725
Working in a restricted shell environment 1726
Testing access in a restricted shell 1726
What users see in a restricted shell environment 1726
Define a command that allows root access 1727

Create a role definition for temporarily running as root 1727
Assign the role as a computer-level override 1727
Verify the role assignment on the computer 1728
Creating a role definition with specific privileges 1728
Define command rights to prevent the use of commands 1728
Create a restricted shell role definition that uses the command rights 1729
Create an unrestricted shell role definition that uses the command rights 1730
Creating a role definition with rescue rights 1730
Creating a role definition that allows local users 1730
Creating a role definition for secure shell rights 1731
Creating additional custom roles and role assignments 1731
Adding custom attributes 1731
Exporting authorization information 1732
Importing authorization information 1732
Updating rights, roles, and role assignments 1732
Reviewing the fundamentals of role definitions 1733
Working with computer roles 1734
How computer roles provide flexibility 1735

Computer roles can have multiple role assignments 1735
Managing access using multiple computer roles 1735
Planning to use computer roles 1736
Creating a new computer role 1737

What to do before creating a new computer role 1737
Adding computers to a computer role 1739

Adding role assignments to a computer role 1740
Viewing and modifying a computer role 1741
Using computer roles 1742
Requiring multi-factor authentication using computer roles 1743
Working with managed computers 1744
Identifying who can add computers to the domain 1745
Preparing computer accounts before joining 1746

Delegating permissions when preparing a computer account 1747
Allowing password resets for computer accounts 1748
Assigning administrative rights to computer accounts 1748
Joining a domain 1749

Connecting to the domain controller 1749
What happens during the join operation 1749
After joining a domain 1749
Joining a domain and zone with the adjoin command 1749
Specifying the most common arguments 1749
Using the self-serve option for a previously-created computer account 1750
Joining a domain in workstation mode 1750
Joining the domain using the computer account 1751
Setting the password interval for managed computers 1752
Allowing a managed computer to authenticate NIS users 1753
Changing the zone for a managed computer 1754
Changing domain information for a managed computer 1755

Leaving a domain 1755
Joining a different domain 1755
Renaming a managed computer 1755
Customizing configuration settings for a computer 1756
Enabling FIPS-compliant encryption 1757

Verifying the Windows environment 1757
Using group policy for FIPS compliance 1757
Using the XML template group policy 1757
Modifying the agent configuration file 1757
Applying the group policy to a domain 1758
Agent requirements for FIPS-compliant encryption 1758
NTLM authentication 1758
Non-compliant operations 1758
Configuring the encryption types for trusted domains 1758
Manually granting write permissions for a computer account 1759
Manually granting write permissions for a user account 1759
Enabling required encryption types for pre-validated users 1759
How Centrify FIPS mode affects other encryption settings 1760
Restarting the agent after enabling FIPS mode 1760
Importing sudoers configuration files 1761

Identify the sudoers file on each computer 1762
Get the sudoers file from each computer 1763

Import the sudoers file 1764
Converting sudoers aliases and user specifications 1765
Converting user aliases 1765
Viewing run-as aliases 1766
Converting host aliases 1766
Viewing command aliases 1766
Converting user specifications 1766
Removing imported sudoers information 1767
Mapping sudo to dzdo 1767
Using Centrify OpenLDAP proxy service 1768
What the OpenLDAP proxy provides 1769

Enabling simple authentication 1769
Enabling simple proxy mode 1769
Accessing network appliance or storage servers 1770
Mapping Active Directory users to UNIX profiles 1771

Configuring servers to use the proxy service 1772
Installing the Centrify OpenLDAP proxy service 1772
Specifying the LDAP server 1773
Testing the solution 1773
Manually starting the OpenLDAP service 1775

Sample deployment scenario 1776
Using OpenLDAP commands 1777

Centrify OpenLDAP proxy commands attributes 1777
Searching for users and groups 1777
Searching the global catalogs 1778
Minimizing search traffic to adclient 1778
Enabling encrypted communication 1778
Preparing for auto-enrollment 1779
Updating the Centrify OpenLDAP proxy computer 1779
Securing communication without auto-enrollment 1780
Searching for automount maps and entries 1782
Automatic translation to search for zone users 1783

Using workstation mode and Auto Zone 1784
Profiles are generated for all users in the forest 1785
Limiting users and groups in Auto Zone 1786
Auto Zone does not provide zone-specific features 1787
Joining a domain as a workstation 1788

Generating profiles for specific users and groups 1790

Steps for completing this task using group policies 1790
Steps for completing this task using configuration parameters 1790
Troubleshooting authentication and authorization 1792
Diagnostic tools and log files 1793

Analyzing information in Active Directory 1794
Common scenarios that generate analysis results 1796
Responding to analysis results 1797
Configuring logging for the agent 1801

Setting the logging level 1801
Logging for Access Manager 1801
Logging to the circular in-memory buffer 1802
Collecting diagnostic information 1803
Working with domain controllers and DNS servers 1804

Configuring the DNS server role on Windows 1804
Configuring DNS running on UNIX servers 1804
Checking whether DNS can resolve the domain controller 1804
Resolving issues in locating Active Directory domain controllers 1804
Setting up DNS service on a target domain controller 1804
Adding a DNS server role to an Active Directory domain controller 1805
Configuring UNIX to use DNS service on the target domain controller 1805
Setting the domain controller in the configuration file 1805
Using the fixdns script 1806
What the Centrify DNS subsystem provides 1807

Resolving a host name or IP address 1807
Selecting a DNS server 1807
Specifying DNS-related parameters 1808
Filtering the objects displayed 1809
Authentication Service issues on 1810
Using Centrify commands for administrative tasks 1811

How and when to use command-line programs 1812
Displaying usage information and man pages 1813
Result codes used by multiple programs 1814
Perform administrative tasks using commands 1816
Using Python with Centrify objects 1819

Python Pylrpc reference 1820
Pylrpc module objects 1820
Pylrpc session object methods 1820
Pylrpc Error object methods 1823
Codes and error messages 1824
Pylrpc dictionary objects 1824
Python Pycapi Reference 1825
Pycapi Module Methods 1825
Pycapi Module Objects 1825
Session Object Methods 1825
_ 1825
_ 1825
close() 1826
open(majorVersion, minorVersion) 1826
getOption(option) 1826
setOption(option, value) 1826
setSessionID(id) 1826
isSessionConnected() 1827
getSessionCode() 1827
ldapFetch(domain, dn, attrs) 1827
lookupObjectByUnixId(type, id) 1827
lookupObjectByName(category, name) 1827
lookupObjectByGuid(guid) 1828
lookupObjectBySid(sid) 1828
getDomainRids() 1828
networkChange() 1828
ping() 1828
getKerberosName(name, useSamName) 1829
authValidateAccount(name, flags) 1829
authValidatePlainTextUserNonCDC(name, password) 1829
authValidatePlainTextUser(name, password) 1829
systemHealthInfo(refresh=FALSE) 1829
getForestList(flags) 1830
getDomainList(flags) 1830
getDCInfo(name) 1830
getDomainControllers(name, flags) 1830
getAuditLevel(name) 1831
Error Object Methods 1831
message() 1831
code() 1831
Pycapi Module Constants 1831
Boolean Constants 1831
Code Constants 1832
Error System Constants 1834
Option Constants 1834
Object Type Constants 1835
AD Category Constants 1835
Get DC Flag Constants 1835
AD Attribute Constants 1836
Validate Flag Constants 1836
Audit Level Constants 1836
Pycapi Dictionary Objects 1837
Administering macOS Systems 1838

About Delinea Management Services for Mac 1838
Topics Covered in this Guide 1838

Installing the DirectControl Agent for Mac 1839
Preparing to Install the DirectControl Agent for Mac 1839

Installing the Agent on Apple M1 Mac Computers 1839
Verifying DirectControl Agent for Mac Installation Prerequisites 1839
Deciding When and How to Join a Domain 1839
Installing the DirectControl Agent 1840
Joining an Active Directory Domain 1842

Configuring Full Disk Access for the DirectControl Agent for Mac 1844
Configuring Full Disk Access Through Your MDM Provider 1845
Configuring Full Disk Access for Apple Remote Desktop 1845
Logging onto the Mac After Joining a Domain 1846
Upgrading The DirectControl Agent for Mac 1846

Creating Home Directories 1847
Understanding Home Directories 1847
Configuring a Local Home Directory 1847

Configuring a Network Home Directory 1847
Configuring a Portable Home Directory 1849

Advantages of a Portable Home Directory 1849
Working with Macs 1850
Specifying the Macintosh User’s Home Directory Location 1850

Populating the Home Directory on a Network Share 1852
Defining a Home Directory in the Active Directory Profile 1852
Setting Shared Directory Permissions 1852
Limiting Users Access to Other Users’ Home Folders 1854
Enabling Users to Manage Their Print Queues 1854

Setting Up Authenticated Printing 1855
Understanding Printing on Mac OS X 1855
Removing a Printer Definition from Client Computers 1858
Setting Up Local and Remote Administrative Privileges 1859
Querying User Information for Active Directory Users 1860

Migrating from Open Directory to Active Directory 1860
Changing the Delinea UIDs and GIDs 1861
Modifying the Mac UID and GID to Match AD 1862
Converting a Local User to an Active Directory User 1863
Migrating a User from Apple’s Active Directory Plugin to Delinea Active Directory 1863
Using Apple’s Scheme to Generate UIDs And GIDs For Mac Users 1863
To correct file ownership by running fixhome.pl 1865
Workaround for AFP and NFS Mounted Shares 1865
Configuring Auto-Enrollment 1866
Configuring 802.1X Wireless Authentication 1867

System Configuration for 802.1X Wireless Authentication 1867
Configuring Mac OS X 10.7 or Later for 802.1X Wireless Authentication 1868
Confirming that Windows Server Supports Certificate Auto-enrollment 1870
Internet Information Services (IIS) Supports CertEnroll and CertSrv URLs 1870
Windows Public Key Group Policies are Set to Trust the Root Certificate Authority and Enroll Certificates
Automatically 1870
A Certificate Template is Configured to Automatically Enroll Domain Computers 1871

A Certificate Template is Configured to Automatically Enroll Domain Users 1873
Configuring Single Sign-On for SSH and Screen Sharing 1874
To configure SSH SSO 1874
To configure Screen Sharing SSO 1874
Configuring FileVault 2 1875
How Filevault2 Protection Is Enabled by Delinea 1875
FileVault 2 Configuration Overview 1876
Before You Begin Configuring Filevault 2 1876
Create Filevault Master Keychain 1877
Export Certificate from Filevault Master Keychain and Upload it to a Domain Server 1878
Enable Bitlocker Recovery Password Viewer in Active Directory 1880
Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk 1880
Enable the Enable Filevault 2 Group Policy 1881
Set Up and Verify Filevault 2 Protection 1883
Adding Filevault-Authorized Users 1884
Changing FileVault 2 Settings 1885
Disabling FileVault 2 Protection 1885
What Happens if the Filevault-Authorized User’s Password is Reset? 1886
Restoring the Filevault User List After Adflush 1886
How to Recover an Encrypted Disk 1886
Deploy Configuration Profiles to Multiple Computers 1886

Understanding Group Policies for Mac Users and Computers 1889
Understanding Group Policies and System Preferences 1889
Linking Group Policy Objects 1891
Installing Mac Group Policies 1891

Installing the Administrative Template 1891
Setting Mac Group Policies 1893
Updating Configuration Policies Manually 1893
Applying Standard Windows Policies to Mac OS X 1894

Group Policy Refresh and Loopback Processing 1894
Synchronizing Time 1894
Specifying Time Sync Polling Interval 1894
Configure Interactive Log On 1894
Set Password Requirements 1894
Configuring Mac-specific Parameters 1895

adclient.autoedit.mac.netlogin 1895
adclient.mac.map.home.to.users 1895
adclient.network.wait.max 1896
logger.login.log 1896
mac.auto.generate.new.login.keychain 1896
mac.protected.keychain.enable 1896
mac.protected.keychain.user.default 1896
mac.protected.keychain.delete 1896
mac.protected.keychain.lock.inactivity 1897
mac.protected.keychain.lock.when.sleeping 1897
mac.keychain.sync.enabled 1897
mac.keychain.sync.polling.interval 1897
Setting Computer-Based Group Policies 1898
Setting Computer-Based Policies for Mac 1898
Allow Certificates with no Extended Key Usage Certificate Attribute 1899
Map /home to /Users 1899

802.1X Settings 1900
Enable Machine Ethernet Profile 1900
Enable Machine Wi-Fi Profile 1900
Enable User Ethernet Profile 1901
Enable User Wi-Fi Profile 1901
Specify System Profile (Deprecated) 1902
Accounts 1903
Set Login Window Settings 1903
Map Zone Groups to Local Admin Group 1904
Map Zone Groups to Local Group 1904
App Store Settings Deprecated 1905
Prohibit Access to the App Store (Deprecated) 1905
Custom Settings 1905

Enable Profile Custom Settings 1906
Install MobileConfig Profiles 1906
Energy Saver 1907
Allow Power Button to Sleep the Computer 1907
Put The Hard Disk(s) to Sleep When Possible 1908
Restart Automatically After a Power Failure 1908
Set Computer Sleep Time 1908
Set Display Sleep Time 1908
Wake When the Modem Detects a Ring 1909
Scheduled Events 1909
Set Machine Sleep/Shutdown Time 1909
Set Machine Startup Time 1910
Firewall 1910
Enable Firewall 1911
Enable iChat 1911
Enable iPhoto Sharing 1911
Enable iTunes Music Sharing 1911
Enable Network Time 1912
Block UDP Traffic 1912
Enable Firewall Logging 1912
Enable Stealth Mode 1912
Internet Sharing 1913

Disallow All Internet Sharing 1913
Network 1913
Legacy Location Settings 1914
Adjust List of DNS servers 1914
Adjust List of Searched Domains 1915
Configure Proxies 1915
Enable Proxies 1916
Exclude Simple Hostnames 1916
Use Passive FTP Mode (PASV) 1916
Bypass Proxy Settings for these Hosts & Domains 1916
Location 1 and Location 2 1917
Adjust List of DNS Servers 1917
Adjust List of Searched Domains 1917
Enable Network Location 1917
Configure Proxies 1918
Remote Management 1918
Enable Administrator Access Groups 1918
Scripts (Login/Logout) 1919
Specify Multiple Login Scripts 1919
Scripts (LaunchDaemons) 1920

Specify Multiple LaunchDaemon Scripts 1920
Security & Privacy 1921

Auto Generate New Login Keychain 1921
Certificate Validation Method 1921
Disable Automatic Login 1922
Disable Location Services 1922
Enable Smart Card Support 1922
Enable FileVault 2 1923
Enable Gatekeeper 1923
Enable Keychain Synchronization 1924
User experience when the AD password is already stored in the login Keychain 1924
User experience when the AD password is not yet stored in the login Keychain 1925
Log Out After Number of Minutes of Inactivity 1926
Require a Password to Wake this Computer from Sleep or Screen Saver 1926
Require Password to Unlock Each Secure System Preference 1927
Use Secure Virtual Memory 1927
Allow All Applications to Access the Auto-Enrollment Private Key(S) 1927
Allow Specific Applications to Access the Auto-Enrollment Private Key(S) 1927
Do Not Allow the Private Key(S) to be Extractable 1929
Store The Private and Public Key(S) Only in the Keychain 1930
Services 1930
Enable Personal File Sharing 1931
Enable Windows Sharing 1931
Enable Personal Web Sharing 1931
Enable Remote Login 1932
Enable FTP Access (deprecated) 1932
Enable Apple Remote Desktop 1932
Enable Remote Apple Events 1933
Enable Printer Sharing 1933
Enable Xgrid 1933
Software Update Settings 1933
Automatically Check For Software Updates (Legacy, Currently Supported) 1935
Use Version Specific Settings 1935
Specify Software Update Server (Legacy, Currently Supported) 1935
Setting User-Based Group Policies 1937

Setting User-Based Policies 1937
802.1X Wireless Settings 1938

Specify User Profiles (Deprecated) 1938
Application Access Settings (deprecated) 1939

Permit/Prohibit Access to Application List: Applescript (Deprecated) 1939
Permit/Prohibit Access to Application List: Applications (Deprecated) 1939
Permit/Prohibit Access to Application List: Server (Deprecated) 1940
Permit/Prohibit Accesst to Application List: Utilities (Deprecated) 1940
Permit/Prohibit Access to Applications (Deprecated) 1940
Permit/Prohibit Access to the User-Specific Applications (Deprecated) 1941
Automount Settings 1941
Automount Network Shares 1941
Automount User’s Windows Home 1943
Create Alias Instead of Symbolic Link 1943
Custom Settings 1944

Install MobileConfig Profiles 1944
Desktop Settings 1944

Set Computer Idle Time for Starting Screen Saver 1945
Dock Settings 1945

Add Other Folders to the Dock 1946
Adjust the Dock’s Icon Size 1946
Adjust the Dock’s Magnified Icon Size 1946
Adjust the Dock’s Position on Screen 1947
Adjust The Effect Shown When Minimizing the Dock 1947
Animate Opening Applications 1947
Automatically Hide and Show the Dock 1947
Lock the Dock 1948
Place Applications in Dock 1948
Place Documents and Folders in Dock 1948
Merge with User’s Dock 1948
Finder Settings 1949

Configure Finder Commands (Deprecated) 1949
Configure Finder Preferences (Deprecated) 1950
Folder Redirection 1951

Delete path 1952
Delete Symbolic Link and Restore 1952
Delete and Create Symbolic Link 1952
Rename And Create Symbolic Link 1953
Import Settings 1953

Import plist Files 1954
Import MCX Setting plist Files 1954
Login Settings 1955

Enable Login Items 1955
Media Access Settings 1956

Permit/Prohibit Access: CDs and CD-ROMs 1957
Permit/Prohibit Access: DVDs 1957
Permit/Prohibit Access: Recordable Discs 1957
Permit/Prohibit Access: Internal Discs 1958
Permit/Prohibit Access: External Discs 1958
Eject All Removable Media at Logout 1958
Mobility Settings 1959

Configure Mobile Account Creation 1959
Printing settings 1959
Specifying the Device URI 1960
AppSocket or Jetdirect Protocol 1960
Internet Printing Protocol (IPP) 1960
Line Printer Daemon Protocol (LPD) 1961

Windows Printer via Delinea 1961
Windows 1961
Specifying the Model (printer driver) 1961
Scripts (Login/Logout) 1962

Specify Login Script (Deprecated) 1962
Specify Logout Script 1962
Specify Multiple Login Scripts 1963
Security & Privacy Settings 1963

Disable Dictation 1963
Require a Password to Wake this Computer from Sleep or Screen Saver (Deprecated) 1964
Prohibit Authentication with Expired Password 1964
Keychain Policies 1965
Enable Protected Keychain 1965
Lock Protected Keychain After Number of Minutes of Inactivity 1965
Lock Protected Keychain When Sleeping 1965
Allow All Applications to Access The Auto-Enrollment Private Key(S) 1966
Allow Specific Applications to Access the Auto-Enrollment Private Key(S) 1966
Do Not Allow the Private Key(S) To Be Extractable 1967
System Preference Settings 1968

Use Version Specific Settings 1969
Legacy Settings 1969
Showing items in the Personal pane of System Preferences 1970
Enable Appearance 1970
Enable Dashboard & Expose 1970
Enable Desktop & Screen Saver 1970
Enable Dock 1970
Enable International (Language & Text) 1970
Enable Security 1970
Enable Spotlight 1970
Showing items in the Hardware System pane of Preferences 1970
Enable Bluetooth 1971
Enable CDs & DVDs 1971
Enable Displays 1971
Enable Energy Saver 1971
Enable Ink 1971
Enable Keyboard & Mouse (Keyboard) 1971
Enable Mouse 1971
Enable Print & FAX 1971
Enable Sound 1971
Enable Trackpad 1971
Showing Items in the Internet & Network Pane of System Preferences 1972
Enable .Mac (MobileMe) 1972
Enable Fibre Channel 1972
Enable Network 1972
Enable QuickTime 1972
Enable Sharing 1972
Showing items in the System pane of System Preferences 1972
Enable Accounts 1972
Enable Classic 1972
Enable Date & Time 1973
Enable Parental Controls 1973
Enable Software Update 1973
Enable Speech 1973
Enable Startup Disk 1973
Enable Time Machine 1973
Enable Universal Access 1973
Showing Items in the Other Pane of System Preferences 1973
Other Preferences Panes 1973
System Preferences Mac OS X 10.5 Settings (deprecated) 1973
Limit Items Usage in System Preferences (deprecated) 1974
Enable System Preferences Panes 10.7 (deprecated) 1974
Enable Built-in System Preferences Panes (deprecated) 1974
Enable Other System Preferences Panes (deprecated) 1975
Enable System Preferences Panes 10.8 (deprecated) 1976

System Preferences Mac OS X 10.10 or Above Settings 1978
Limit Items Usage on System Preferences 1978
Enable System Preferences Panes 10.10 1978
Enable Built-in System Preferences Panes 1978
Enable Other System Preferences Panes 1978
Configuring a Mac Computer for Smart Card Login 1980

Understanding Smart Card Login 1980
Supported Smart Card Types 1980

Configuring Smart Card Login 1980
Verifying Prerequisites for Configuring Smart Card Login 1980
Enabling Smart Card Support 1980
Verifying Smart Card Configuration 1981
Enabling the Sscreen Saver for Smart Card removal 1982
Disabling Smart Card Support 1982
Using Smart Card Login 1982
Troubleshooting Smart Card Login 1984

Other Functions of Smart Card Support on MacOS 1984
Known Issues of Using Smart Cards with Macos 1984

Troubleshooting Tips 1985
Using Common Account Management Commands 1985
Viewing the Agent Version on the Macs Joined to Active Directory 1985
Install the Active Directory Module for Windows PowerShell 1986
Show PowerShell Output of Agent Versions for AD-joined computers 1986
Export the Report of Agent Versions to a CSV file 1986
Enabling Logging for the Delinea DirectControl Agent for Mac 1986
Enabling Logging for the Mac Directory Service 1990

Using the Agent on a Dual-boot System 1990
Using adgpupdate Appropriately 1990

Understanding Delays when Logging on the First Time with a New User Account 1990
Configuring Single-sign on to Work with Non-Mac Computers 1990
Restricting Login Using FTP 1991

Logging on Using localhost 1991
Changing the Password for Active Directory Users 1991

Disabling the Apple Built-in Active Directory Plug-in 1991
Showing the Correct Status of the Delinea Plug-in 1991
Resolving VPN Access Issues with Mac OS X 10.7 and Later 1992
Diagnosing Smart Card Login Problems 1992
Opening a Support Case Online 1993

Collecting Information for Support Cases 1993
Collecting Information Specific to Smart Card Login Failure 1993
Collecting General Information about Your Environment 1994
Collecting Information Specific to Login Events 1995
Installing and Removing the Agent and Leaving a Domain 1996

Installing Using the install.sh Script 1996
Installing Silently on a Remote Computer 1996

Installing Remotely on a Mac Computer Using Sudo Commands 1997
Installing Remotely on a Mac Computer Using Apple Remote Desktop 1997
Understanding the Directory Structure 2000
Uninstall from the Delinea System Preferences Pane 2000
Run the uninstall.sh Script 2002
Leaving an Active Directory Domain 2002
Administrator’s Guide for Windows 2004
Introduction to Server Suite 2005
Managing Windows Computers Using Delinea software 2005
Access-Related Features 2005
Audit-Related Features 2005
Choosing Access and Auditing Features 2005
Access Control for Windows Computers 2005

How Zones Organize Access Rights and Roles 2006
How Role-Based Access Rights Can be Used 2006
Auditing User Activity on Windows Computers 2006
Using Access and Auditing Features Together 2007
Architecture and Operation 2008

Identity and Privilege Management 2008
Defining Rights and Roles Using Access Manager 2008
Enforcement of Rights and Roles by the Agent 2008
The Audit and Monitoring Service Infrastructure 2009

Auditing Captures User Activity 2009
Auditing Requires a Scalable Architecture 2009
How Audited Sessions are Collected and Stored 2009
Deploying the Audit and Monitoring Service Infrastructure 2010
Planning Where to Install Audit and Monitoring Service Components 2010
Using Multiple Databases in an Audit Store 2010
Using Multiple Consoles in an Installation 2011
Basic Operation with Identity and Privilege Management, and Auditing 2011
Planning a Deployment 2013

Why Planning is Important 2013
Identify Identity, Privilege Management, and Auditing Goals 2013
Decide on the Scope of the Installation 2013
Decide Where to Install the Management Database 2014
Decide Where to Install Collectors and Audit Stores 2015
Use Separate Computers for Collectors and Audit Store Databases 2015
Plan for Network Traffic and Data Storage 2015
Default Ports for Network Traffic and Communication 2015
Auditing Requires Database Management 2016
Identify an Active Directory Site or Subnets 2016
Determine How Many Collectors and Audit Stores to Install 2016
Estimate the Number of Agents and Sessions Audited 2017
Determine the Recommended Hardware Configuration 2017
Guidelines for Storage 2017
Guidelines for Disk Layout 2017
Decide Where to Install Agents 2019
Decide Where to Install Consoles 2020
Check SQL Server Logins for Auditing 2021
Create Security Groups for Auditing 2021
What’s Involved in the Deployment Process 2022
Plan 2022
Prepare 2023
Deploy 2024
Validate 2024
Manage 2024
Authentication and Privilege Elevation Services Deployment Checklist 2026

Accounts and Permissions for Installation and Deployment 2029
Authentication and Privilege Elevation Services permissions 2029
Zone Provisioning Agent Account Permissions 2029
Report Services Account Permissions 2029
SQL Server Permissions Set by the Report Services Configuration Wizard 2030
Audit & Monitoring Permissions 2031
Installing Server Suite 2033
Installation Checklist 2033
Installing Server Suite and Updating Active Directory 2034

Running the Setup Program on a Windows Computer 2034
Opening Access Manager to Update Active Directory 2035
Installing and Configuring Microsoft SQL Server for Auditing 2035
Downloading and Installing SQL Server Manually 2036
Configuring SQL Server to Prepare for Audit and Monitoring Service 2036
Installing the Audit Manager and Audit Analyzer Consoles 2036
Creating a New Installation 2037

How to Create an Installation without System Administrator Privileges 2038
Create the First Audit Store 2039
Create the Audit Store Database 2039
Connecting to SQL Server on a Remote Computer 2040
Verify Network Connectivity 2040
How to Create the Database without System Administrator Privileges 2040
Installing and Configuring Audit Collectors 2041
Set the Required Permission 2041
Install the Collector Service Using the Setup Program 2042
Configure the Audit Collector Service 2042
Installing the Agent for Windows 2043
Verifying Prerequisites 2043
Installing the Agent Interactively Using the Setup Program 2043
Configuring the Agent 2044
Configuring Agent Settings for the Audit and Monitoring Service 2045
Selecting the Maximum Color Quality for Recorded Sessions 2045
Configuring Agent Settings for Offline Audit and Monitoring Service Storage 2045
Configuring Agent Settings for the Identity Platform 2046
Configuring Agent Settings for Privilege Elevation 2047
Installing the Agent without MFA Login 2047
Installing the Agent for Windows Silently on Remote Windows Computers 2048
Deciding to Install with or without Joining the Computer to a Zone 2048
Configuring Registry Settings 2048
Editing the Default Transform (MST) File 2049
Installing Silently without Joining a Zone 2050
Installing and Joining a Zone Silently 2051
Installing the Agent for Windows Silently on All Domain Computers by Using Group Policy 2052
Installing the Agent on a Computer Running Server Core 2053
Installing Additional Consoles 2054
Installing Group Policy Extensions Separately from Access Manager 2054
Managing Zones 2056

What to do Before Updating Active Directory 2056
Rights Required for this Task 2056
How Often You Should Perform this Task 2057
Preparing to Use Zones 2058

Controlling Access through Hierarchical Zones 2058
Managing Access Rights and Roles Using Zones 2058
System and Predefined Rights 2058
Granting Permission to Log On 2058
Delegating Administrative Tasks in Hierarchical Zones 2059
Associating Computers and Role Assignments 2059
Creating a New Parent Zone 2059
What to Do Before Creating a New Parent Zone 2059
Creating Child Zones 2061
What to Do Before Creating Child Zones 2061
Opening and Closing Zones 2062
Changing Zone Properties 2062
Moving a Child Zone to a New Parent Zone 2063
Delegating Control of Administrative Tasks 2063

Granting the Authority to Perform All Administrative Tasks 2064
Restricting Authority to Specific Administrative Tasks 2064
Adding Windows Computers to a Zone 2064
Preparing Windows Computer Accounts 2064
Changing the Zone for the Computer 2064
Leaving a Zone 2065

Renaming a Zone 2065
What to Do Before Renaming a Zone 2065
Working Directly with Managed Computers 2066

Using the Agent Configuration 2066
Working with Zone Role Workflow 2066
Using Zone Role Workflow with the Connector 2066
Using Zone Role Workflow with the Client 2067
Managing Access Rights and Roles 2068

Basics of Authorization and Access Rights 2068
System Rights Allow Users to Log On 2068
Windows-specific Rights Can Grant Users Privileged Access 2068
Combining Rights into Roles and Role Assignments 2069
Deciding Where to Define and Assign Roles 2069
Adding Predefined Rights to a Zone 2069
Enabling Multi-factor Authentication for Windows Rights 2070
Using Multi-factor Authentication When There are Selective Cross-forest Trusts 2070
Defining Desktop Access Rights 2070

Where Desktop Rights Apply 2071
Defining Application Rights 2071
How to Specify Which Applications are in an Application Right 2071
Defining an Application Right Manually 2072
Using Application Utility Rights 2075
Application Manager 2075
Windows Feature Manager 2075
Network Manager 2076
Using an Installed Application or Running Process to Create Application Rights 2076
Examples of Application Right Definitions 2078
Defining Network Access Rights 2079

Using Network Access Rights When There are Two-way Selective Cross-forest Trusts 2080
Defining Custom Roles with Specific Rights 2080
Creating a Role Definition with Desktop Rights 2081
Creating a Role Definition with Application Rights 2082
Creating a Role Definition for Network Access Rights 2082
Combining Rights in the Same Role Definition 2083
Assigning Users and Groups to a Role 2083
Rights and Role Assignments for Local Users 2084
Restricting Roles that Include Network Access Rights 2084
Making Rights and Roles Available in Other Zones 2084

Exporting a Zone’s Rights and Role Definitions 2084
Importing Rights and Role Definitions into a New Zone 2084
Copying Rights and Role Definitions into a New Zone 2085
Viewing Rights and Roles 2085

Displaying Rights for an Individual User in the Console 2085
Scenario: Using a Network Access Role to Edit Group Policies 2085
Scenario: Using Multiple Roles for Network Resources 2086
Defining Rights for Windows Applications that Encrypt Passwords 2087
Enabling Access Across Multi-tiered Application Layers 2087
Requiring Users to Justify Privilege Elevation 2087

Working with Computer Roles 2088
Using Computer Roles to Simplify the Management of Access Rights 2089
Create an Active Directory Group for a Set of Computers 2089
Create an Active Directory Group for Each Set of Access Rights 2089
Create a Role Definition for Each Set of Users with Different Access Rights 2089
Create a New Computer Role 2090
Add Role Assignments to the Computer Role 2090
Assigning Roles on Multiple Computers at Once 2091
Using the Authorization Center Directly on Managed Computers 2091
Working with the Authorization Cache on Managed Computers 2092

Persisted and Non-persisted Capabilities 2092
Persisted Capabilities 2092
Cache Location 2092
Performing Cache Operations 2092
Refreshing the Cache 2093
Flushing the Cache 2093
Dumping the Cache 2093
Configuring PowerShell Remote Access 2094
What Gets Audited for Remote PowerShell Commands and Scripts 2094
Examples of Remote PowerShell Commands 2095
Hiding the Remote PowerShell Script Text 2095
Authentication Service Enforcement 2095
Configuring MFA with RADIUS for Privilege Elevation Service for Windows Checklist 2095
Adding Remote Users Automatically 2098
Enabling Users to Run Applications with Alternate Accounts 2099

Managing Local Windows Users and Groups 2100
Adding Local Windows Accounts 2100
Enabling Windows Local Account Management 2101
Creating and Managing Local Windows User Passwords 2102
Removing Local Windows Accounts 2103

Managing Auditing and Audit Permissions 2104
Configuring Selective Auditing 2104
Enabling Audit Notification 2104
Managing Audit Roles and Auditors 2105

Granting Permission to Manage Audit Roles 2105
Creating a New Audit Role 2106
Assigning Users and Groups to an Audit Role 2106
Delegating Audit-related Permissions 2106
Modifying an Audit Role's Properties 2107
How Access Roles and Audit Roles Differ 2107

Identity and Privilege Management Only 2107
Auditing Only 2107
Identity and Privilege Management and Auditing on the Same Computer 2107
Managing Auditing for an Installation 2108
Securing an Installation 2108

Securing an Audit Store with Trusted Collectors and Agents 2108
Securing Network Traffic with Encryption 2109
Setting Administrative Permissions 2110
Managing Audit Stores 2112

Configuring the Scope of an Audit Store 2112
Configuring Permissions for an Audit Store 2112
Managing Audit Store Databases 2113
Selecting a Recovery Model 2113
Configuring the Maximum Memory for Audit Store Databases 2114
Using Transact-SQL to Configure Minimum and Maximum Memory 2114
Estimating Database Requirements Based on the Data you Collect 2114
Adding New Audit Store Databases to an Installation 2115
Rotating the Active Database 2115
Creating a New Database for Rotation 2116
Database Archiving 2116
Queries During Rotation and Archiving 2116
Database Backups 2116
Allowed Incoming Accounts 2116
Managing the Management Database 2117
Configuring the Scope of the Management Database 2117
Configuring Permissions for the Management Database 2117
Managing Collectors 2118
Monitoring Collector Status Locally 2118
Removing Collectors 2119
Managing Audited Computers and Agents 2119

Monitoring Agent Status Locally 2119
Setting the Color Depth for Captured Sessions 2120
Removing an Audited Computer 2120
Adding an Installation 2120
Delegating Administrative Tasks for a New Installation 2121
Opening an Installation in a New Console 2121
Closing an Installation 2121
Publishing Installation Information 2121
Synchronizing Installation Information 2121
Removing or Deleting an Installation 2121
Troubleshooting and Common Questions 2123

Solving Problems with Logging On 2123
Accessing Network Computers with Privileges 2123
Refreshing Cached Information on Managed Computers 2124
Analyzing Information in Active Directory 2124

Common Scenarios that Generate Errors and Warnings 2124
Responding to Errors and Warnings 2125
Running Diagnostics and Viewing Logs for the Agent 2125
Sample Diagnostic Report 2126
Enabling Detailed Logging for Audit and Monitoring Service Components 2126
Enabling Detailed Logging for an Audited Computer 2127
Enabling Detailed Logging for the Collector Service 2127
Enabling Detailed Logging for Audit and Monitoring Service Consoles 2127
Enabling Audit and Monitoring Service Performance Counters for the Collector 2128
Tracking Database Activity 2128

Starting a Database Trace 2128
Stopping the Database Trace 2128
Exporting the Database Trace for a Management Database 2129
Exporting the Database Trace for Audit Store Databases 2129
Delegating Database Trace Management 2129
Controlling Audit Trail Events 2129
Summary of Audit Trail Events 2130
Offline MFA Profile Authentication 2130
Authentication Service Known Issues 2130
Using Windows Command Line Programs 2132
Using CopyGroup and CopyGroupNested 2132

Using dzinfo 2132
Using dzjoin 2135
Using dzleave 2135
Using dzdiag 2136
Using dzrefresh 2138

Using dzflush 2138
Using dzdump 2138
Using runasrole 2139
Examples 2140
Running an application from a shortcut 2140
How to determine whether RunAsRole supports an application shortcut 2141
Using RunAsAlternate 2141
Working with Server Core and Windows Server 2012 2142
Server Core Supported PLatforms 2142
Installing the Agent on a Computer Running Server Core 2142
Opening Consoles on Server Core Computers 2143

Joining a Zone 2143
Viewing Authorization Details 2143
Configuring Auditing Options 2144
Running Command Line Programs 2144
Unsupported Windows Server 2012 Features 2144

Server Suite Unix/Linux Quick Start 2146
Prepare to Use Multi-Factor Authentication 2148
Secure Login Access 2149
Multi-Factor Authentication and Smart Card PIN Login 2149
Secure Privileged Access 2150

Preview the Preliminary Steps 2151
Register for Privileged Access Service 2152
Sign Up and Activate Your Account 2152
Start or Skip the Wizard 2152
Plan Multi-Factor Authentication for Server Suite-Managed Computers 2152

Install and Configure a Connector 2153
Establishing a Connector Identity for Multi-Factor Authentication 2153
To Import the Certificate Manually to a Local Windows Computer 2153
To Export the Certificate for Bulk Group Policy Distribution 2154
To Distribute the Certificate using Group Policy 2154
Using a certificate not issued by Delinea with the Cloud Connector 2154
Verify Open Ports 2154
Log on and Verifying Connector Settings 2156
Prepare a Group for Delinea-Managed Computers 2157
To Add an Active Directory Group for Multi-Factor Authentication 2157

Add a User or Group for MFA to a Role with an Admin Portal-Specified pPolicy 2158
Prepare a Role for Delinea-Managed Computers in the Admin Portal 2159
Prepare Authentication Profiles 2160
Create an Authentication Profile 2160
Assign Login Authentication Profiles 2160

Assigning Privilege Elevation (Re-authentication) Profile 2163
Configuring Roles and Rights to Use Multi-Factor Authentication 2164
To Configure Multi-Factor Authentication 2164
Configuration Options for Linux and UNIX Computers 2165
Add Rescue Rights 2165

Configuring Secure Shell (ssh) for Multi-Factor Authentication 2165
Enforcing Multi-Factor Authentication for Single Sign-on Login Access 2165
Require Multi-Factor Authentication for PAM Applications 2165
Configure Multi-Factor Authentication in Legacy Zones 2166
Configuration Options for Windows Computers 2167

Reset Password 2167
Disable Self-Service Password Reset 2167
Configure Offline Multi-factor Authentication and Rescue Users 2167
Require Multi-Factor Authentication using Computer Roles 2168
Using Multi-Factor Authentication when there are Selective Cross-Forest Trusts 2169
Configuring MFA with RADIUS for Privilege Elevation Service for Windows Checklist 2169
Troubleshoot Multi-Factor Authentication 2173
Viewing Windows Diagnostics 2173
View UNIX and Linux Diagnostics 2174
Address Certificate Errors 2174

Manage Passwords 2174
Troubleshoot Login Issues 2174
Customize the HTTP Proxy Configuration 2175
Requirements 2175
Configure the Agent to Use a Custom HTTP Server 2175

HTTP Proxy Credential Local Storage 2175
Password Encryption 2175
Encrypted Password Storage 2176
Local Machine Account Support 2176
Command Reference 2176
adwebproxyconf 2176
Requirements 2176
Synopsis 2176
Command Options 2177
Configure RADIUS Silent Authentication 2179

Certificate Auto-Enrollment Quick Start 2180
Working with a Single Certificate Authority for UNIX Computers 2181
Preparing a Computer to be a Certificate Authority (CA) 2182
What's Required to Install Certificate Services 2182
Adding the Required Server Roles to Make the Computer a Certificate Authority 2182
Configuring the Certificate Authority 2182
Adding a Trusted Root Certificate to the Group Policy 2184
To Add a Trusted Root Certificate to the Group Policy Object 2184
Enabling Auto-Enrollment 2185
Enabling Auto-Enrollment for the Group Policy 2185
Creating a Certificate Template 2185
Assigning the Certificate Template to the CA 2186
Retrieving Certificate Revocation Lists (CRLs) 2187
Generating a Certificate Revocation List (CRL) 2187
Retrieving a Certificate Revocation List and Verifying Certificates 2187
Reports and Events 2188
Audit Events Admin Guide 2189
Overview of Delinea Server Suite Audit Events 2190
Windows and UNIX/Linux Audit Events 2191

Windows Audit Event Log Line Example 2191
Windows Audit Event Log Line Information 2191
UNIX/Linux Audit Event Log Line Example 2192
UNIX/Linux Audit Event Log Information 2192
How to Read Audit Event Data 2194

Event ID/CentrifyEventID 2194
Severity 2195
Spacing 2195
Case-Insensitive Field Names 2195
Configuring the Audit Event Log Location 2196

Configuring the Audit Event Logging Location by Group Policy 2196
Send Audit Trail to Audit Database 2196
Send Audit Trail to Log File 2196
Set Global Audit Trail Targets 2196
Which Events are Only in Centrify Audit & Monitoring Service 2197
Server Suite Audit Events 2198
Audit Analyzer 2199

Audit Analyzer Audit Event Log Sample 2199
Audit Analyzer Audit Events 2199
Audit Manager 2201

Audit Analyzer Audit Event Log Sample 2201
Audit Manager Audit Events 2201
Centrify Commands (UNIX Commands) 2205

Centrify Command Audit Event Log Sample 2205
Centrify Commands Audit Events 2205
Centrify Configuration 2208

Centrify Configuration Audit Event Log Sample 2208
Centrify Configuration Audit Events 2208
Centrify sshd 2218

Centrify sshd Audit Event Log Sample 2218
Centrify sshd Audit Events 2218
Command (Audited and Successfully Executed Commands) 2219

Command Audit Event Log Sample 2219
Command Audit Events 2219
Centrify Audit & Monitoring Service Advanced Monitoring 2220

Advanced Monitoring Audit Event Log Sample 2220
Centrify Audit & Monitoring Service Advanced Monitoring Audit Events 2220
Centrify Audit & Monitoring Service System Management 2221

Centrify Audit & Monitoring Service System Management audit events 2221
Centrify Authentication Service UNIX Agent 2223

Centrify Authentication Service UNIX Agent Audit Event Log Sample 2223
Centrify Authentication Service UNIX Agent Audit Events 2223
Centrify Audit & Monitoring Service – Windows 2224

Centrify Audit & Monitoring Service – Windows Audit Event Log Sample 2224
Centrify Audit & Monitoring Service - Windows Audit Events 2224
Centrify Privilege Elevation Service – Windows 2225

Centrify Privilege Elevation Service Windows Audit Event Log Sample 2225
Centrify Privilege Elevation Service - Windows Audit Events 2225
Centrify Authentication Service UNIX Agent 2232
Centrify Authentication Service UNIX Agent Audit Event Log Sample 2232
Centrify Authentication Service UNIX Agent Audit Events 2232
dzdo 2233
dzdo Audit Event Log Sample 2233
dzdo Audit Events 2233
dzinfo 2234
dzinfo Audit Event Log Sample 2234
dzinfo Audit Events 2234
dzsh 2235
dzsh Audit Event Log Sample 2235
dzsh Audit Events 2235
License Management 2236

License Management Audit Event Log Sample 2236
License Management Audit Events 2236
Kerberos 2237
Kerberos Audit Event Log Sample 2237
Kerberos Audit Events 2237
Local Account Management 2239

Local Account Management Audit Event Log Sample 2239
Local Account Management Audit Events 2239
Multi-Factor Authentication 2241

Multi-Factor Authentication Audit Event Log Sample 2241
Multi-Factor Audit Events 2241
PAM 2243
PAM Audit Event Log Sample 2243
PAM Audit Events 2243
Trusted Path 2245

Trusted Path Audit Event Log Sample 2245
Trusted Path Audit Events 2245
What Report Services Provides 2246
Reporting Data Based on Domains or Zones 2247
gMSA Accounts 2247
Report Services and Report Center 2247
Report Services Tools Overview 2247
Overview of How to Set Up Reporting 2247

Evaluation Deployment Overview 2248
Production Deployment Overview 2249
How to Set up a Production Version of Delinea Report Services 2249
Upgrade Overview 2249
Installing and Configuring Report Services 2251
Before Install: Prerequisites 2252

Supported Versions of SQL Server and SSRS 2252
Supported Versions of PostgreSQL 2252
Supported Browser Versions 2252
Required User Permissions for Report Services 2252
Report Services Account Permissions 2252
Grant the Report Service Account Permissions 2253
Grant the Permission to Replicate Directory Changes in ADUC 2253
Grant the Permission To Replicate Directory Changes In ADSI 2254
Grant the Permission to Log on as a Service 2255
SQL Server permissions that are set by the Configuration Wizard 2255
Sql Server Permissions Set by the Report Services Configuration Wizard (table) 2255
PostgreSQL Permissions that are Set by the Configuration Wizard 2256
Memory Requirements 2256
Domain Controller Memory Requirements 2256
Windows Memory Requirements 2256
SQL Server Recovery Model Requirement 2257
Impact of Using a New or Existing SQL Server Instance 2257
Deploy in Multi-Forest Environments 2257
Enable Selective Authentication Across a Forest with a One-Way Selective Trust 2258
Virtual Machines and Report Services 2258
Installing Report Services 2259
Configuring Report Services and Deploying Your Reports 2260

Configuring a SQL Server Report Services Deployment 2260
Configuring a PostgreSQL Report Services Deployment 2263
Changing the Monitoring Mode for an Existing Report Services Deployment 2265
Doing a Silent Install and Configuration 2268

Doing a Silent Install of Report Services 2268
Configuring a New Report Services Deployment Silently 2268
Report Services Silent Configuration Parameters 2269
Upgrading from a Prior Version 2272

Upgrading Your Report Services Database 2272
Upgrading from Versions Before 2016 2273
Classic Zone Access Manager Reports 2273
Hierarchical Zone Access Manager Reports 2273
All Zone Access Manager Reports 2274
Reports that are New to Access Manager Report Users 2274
Upgrading the Reporting Database Silently 2275
Administering Report Services with the Report Control Panel 2276

General Tab 2276
Monitored Zones Tab 2276
Settings Tab 2276
Troubleshooting Tab 2276
Configuring SQL Server Reporting Services (SSRS) 2277

Adding Your Report Services Web Site to Your Internet Explorer Trusted Sites 2277
Granting Access in SSRS to Reports 2278
Providing Reports to Your Users or Auditors 2279
Sharing Reports by Email or File Sharing with Report Subscriptions 2279
Re-Deploying the SQL Server Reports to SSRS 2281
Viewing Default Reports 2282

Opening a Report 2282
Filtering Report Data by Zone 2282
Default Access Manager Reports 2282
Report Services Reports: Not Specific to Classic or Hierarchical Zones 2282
Delinea Report Services Reports: Classic Zone Reports 2283
Delinea Report Services Reports: Hierarchical Zone Reports 2283
Default SOX Attestation Reports 2284
Default PCI Attestation Reports 2285
How Objects are Counted for the PCI and SOX Report Charts 2286
Login Report Charts 2286
Login Report – By Computer charts 2287
Computers with Most Access chart 2287
User Roles Count for Computers with Most Access chart 2287
Users with Most Access chart 2287
Login Report – By Group charts 2287
Roles with Most Access chart (by Group) 2287
Groups with Most Members chart 2287
Login Report – By Role charts 2287
Roles with Most Access chart (by Role) 2287
Roles with Most Users chart 2287
Roles with Most Rights chart 2287
Login Report – By User charts 2287
Users with Most Access On Computers chart 2287
Login Roles Count for Users with Most Access On Computers chart 2287
Login Summary Report charts 2288
Computers With Most Access chart 2288
Users With Most Access chart 2288
Rights Report Charts 2288
Rights Report – By Computer Charts 2288
Computers with Most Privileged Access chart 2288
Computer Roles with Most Privileged Access Chart 2288
Privileged Access with Most Computers Chart 2288
Rights Report – By Group Charts 2288
Groups with Most Privileged Access Chart 2288
Rights Report – By Role Charts 2288
Computer Roles with Most Privileged Access Chart 2288
User Roles with Most Privileged Access Chart 2288
Rights Report – By User Charts 2289
Users with Most Privileged Access Chart 2289
Computer Role Count for Users with Most Privileged Access Chart 2289
Rights Summary Report Charts 2289
Computers with Most Privileged Access Chart 2289
Users with Most Privileged Access Chart 2289
Most Dominant Privileges on Computers chart 2289
Building Custom Reports 2290

Requirements and Recommendations 2290
An Overview of Report Building Tasks 2290
Migrating Custom Reports from SQL Server Express 2290
Views to Use in Custom Reports 2292
Understanding the Differences Between Views 2292
ADComputers View 2292
Adcomputers Columns Used in Other Views 2293
ADComputers_Stale View 2294
ADGroupComputerMembers View 2294
ADGroups View 2295
ADGroupUserMembers View 2297
ADUsers View 2297
ADUser Columns Used in Other Views 2299
ApplicationRight View 2300
AutoZoneComputers View 2300
CommandRight View 2301
ComputerRoleCustomAttribute View 2302
ComputerRoleEffectiveMembers View 2302
ComputerRoleMembership View 2302
ComputerRoles View 2303
DelegationTasks View 2303
DelegationTaskType View 2304
Domains View 2304
Domains Columns Used in Other Views 2304
EffectiveAuthorizedUserPrivilegesSummary View 2305
EffectiveAuthorizedUserPrivilegesSummary__Hierarchical View 2305
EffectiveAuthorizedUserPrivilegesSummary_Classic View 2305
EffectiveAuthorizedLocalUserPrivileges_Computer View 2305
EffectiveAuthorizedLocalUsers_Computer View 2306
EffectiveAuthorizedUserPrivileges_Computer View 2307
EffectiveAuthorizedUsers_Computer View 2307
EffectiveAuthorizedUsers_Computer_Classic View 2307
EffectiveAuthorizedUsers_Computer_Hierarchical View 2307
EffectiveAuthorizedZoneLocalUsers View 2307
EffectiveAuthorizedZoneUsers View 2308
EffectiveDelegationTasks View 2309
EffectiveGroupPrivileges_Computer View 2310
EffectiveLocalUserPrivilegesSummary View 2311
EffectiveLocalUsersRoleAssignment View 2312
EffectiveLoginUserPrivilege_Computer View 2312
EffectiveRoleAssignment View 2314
EffectiveRoleAssignment_Classic View 2315
EffectiveRoleAssignment_Hierarchical View 2315
EffectiveSysRights View 2317
EffectiveUserPrivileges_Computer View 2318
EffectiveUserPrivileges_ComputerRole_UNIX View 2321
EffectiveUserPrivileges_ComputerRole_Windows View 2322
EffectiveUserPrivileges_Zone_UNIX View 2324
EffectiveUserPrivileges_Zone_Windows View 2325
EffectiveZoneGroups View 2326
EffectiveZoneLocalGroupMembers View 2327
EffectiveZoneLocalGroups View 2327
EffectiveZoneLocalUsers View 2328
EffectiveZoneLocalWinGroupMembers View 2329
EffectiveZoneLocalWinGroups Views 2329
EffectiveZoneLocalWinUsers View 2330
EffectiveZoneUsers View 2331
RightType View 2332
RoleAssignmentCustomAttribute View 2333
RoleAssignments View 2333
RoleAssignments_Computer View 2334
RoleAssignments_ComputerRole View 2335
RoleAssignments_Zone View 2335
RoleCustomAttribute View 2336
RoleRights View 2336
Roles View 2337
Roles Columns Used in Other Views 2337
Roles_Classic View 2338
Roles_Hierarchical View 2338
TrusteeTypes View 2339
Zone_Classic View 2339
Zone_Hierarchical View 2340
Zones_Hierarchical Columns Used in Other Views 2341
ZoneComputers View 2341
ZoneComputer Columns Used in Other Views 2342
ZoneGroups View 2342
ZoneGroup Columns Used in Other Views 2342
ZoneLocalGroupMembers View 2343
ZoneLocalGroups View 2343
ZoneLocalUsers View 2344
ZoneLocalWinGroupMembers View 2344
ZoneLocalWinGroups View 2344
ZoneLocalWinUsers View 2345
ZoneRolePrivileges View 2345
Zones View 2346
ZoneUsers View 2348
ZoneUser Columns Used in Other Views 2349
Configuring Report Services for Large Active Directory Environments 2350

Memory Recommendations and Requirements for Large Active Directory Environments 2350
Domain Controller Memory 2350
Symptoms 2350
Resolution 2350
Windows Memory Requirements 2350
References 2350
Sql Server Memory 2350
Symptoms 2350
Resolution 2351
Configuration Recommendations for Large Active Directory Environments 2351
Setting the Maximum Server Memory for SQL Server 2352
Using Report Filters to Limit the Output Data of a Report 2352
Symptoms 2352
Resolution 2352
Increasing the Time-Out Value for Rebuild/Refresh Data Operations 2354
Symptom 2354
Resolution 2354
Increasing the Time-Out Values for Microsoft SQL Server Reporting Services 2354
Report Execution Time-out 2354
Symptoms 2354
Resolution 2355
HTTP Runtime Execution Timeout 2355
Symptoms 2355
Resolution 2355
Increasing the ReceiveTimeOut Value for Internet Explorer 2355
Symptoms 2355
Resolution 2355
Using a URL to Export Report Data to CSV 2356
Symptoms 2356
Resolution 2356
References 2356
Creating the Report Subscription for CSV Export 2356
Prerequisites 2356
Configuring The Report Data Source For Subscriptions 2357
Creating A CSV Report Subscription 2358
Skipping Chart Data From CSV Report Subscriptions 2359
Troubleshooting Reports 2361
You Don’t See Any data When You Open a Report 2361
You Don’t See the Report Builder Link in Internet Explorer 2361
You Can’t Log in to Report Services in Internet Explorer 2361
You Get a Server Error When You Try to Synchronize with Active Directory 2361
Port Conflicts 2362
SSRS Fails to Start on Windows 2008 R2 Systems 2362
SSRS Produces the Following Error 2362

SQL Server 2008 R2 Express Edition Produces an Installation Error 2362
The Report Services Configuration Wizard Cannot be Completed Due to an Error that Occurred 2362
Installing SQL Server from the Delinea Management Services Installer Generates Error Codes 2363
Can’t install SQL Server 2012 or 2014 instance on Windows 2008 SP2 2364
Report Services computation takes longer than it used to 2364

Frequently asked questions about report services 2364
Synchronized Active Directory Attributes for Reports 2366
AD Computer 2366
AD Group 2366
AD User 2366
Application Right 2366
Command Right 2367
Computer Role 2367
Computer SCP 2367
Computer Zone AzScope 2367

Computer Zone Container 2367
Container 2368
Desktop Right 2368
Domain 2368
Dzsh Command Right 2368

Group SCP 2368
License Container 2369
Local Group SCP 2369
Local User SCP 2369
Network Right 2369

Pam Right 2369
Privileged Command Right 2370
Restricted Environment 2370
Role 2370
Role Assignment 2370

Ssh Right 2370
User SCP 2371
Zone 2371
Auditing Guides 2372
Auditing and Monitoring Administration 2373

Overview of the Auditing Infrastructure 2374
Deciding Whether to Audit User Activity 2375
Capturing Detailed and Summary Information for User Sessions 2376
Reviewing Recorded Activity 2377
Auditing Requires a Scalable Architecture 2378

How Audited Sessions are Collected and Stored 2379
Auditing Architecture and Dataflow 2380
Deploying Auditing Components in an Audit Installation 2382

Planning Where to Install Auditing Components 2382
Using Multiple Databases in an Audit Store 2382
Using Multiple Consoles in an Installation 2382
Agent Components 2384

On Audited UNIX computers 2384
On Audited Windows Computers 2384
Planning an Audit Installation 2385

Deciding on the Scope of the Installation 2386
Deciding Where to Install Different Audit Components 2387
Deciding Where to Install the Management DDatabase 2388
Deciding Where to Install Collectors and Audit Stores 2389
Use Separate Computers for Collectors and Audit Store Databases 2389
Plan for Network Traffic and Default Ports 2389
Identify an Active Directory Site or Subnets 2390
Determining How Many Collectors and Audit Stores to Install 2390
Estimate the Number of Agents and Sessions Audited 2390
Guidelines for Linux and UNIX Computers 2390
Guidelines for Windows Computers or Mixed Environments 2390
Determine the Recommended Hardware Configuration 2391
Guidelines for Linux and UNIX Computers 2391
Guidelines for Windows Computers 2391
Guidelines for Storage 2391
Guidelines for Disk Layout 2392
Deciding where to install agents 2393
Deciding where to install consoles 2394
Audit and Monitoring Deployment Checklist 2395
Supported SQL Server Editions 2397

Checking SQL Server Logins for Auditing 2398
Auditing Permissions for SQL Server 2398
Creating Security Groups for Auditing 2398
Auditing Security Groups 2398
Determining Storage Requirements for Auditing 2400

What’s Involved in the Deployment Process 2401
Plan 2401
Prepare 2401
Deploy 2402
Validate 2402
Manage 2402
Installing the Audit and Monitoring Service 2403
Installation Preview 2404
Installing and configuring Microsoft SQL Server for Auditing 2406

Downloading and installing SQL Server manually 2406
Configuring SQL Server to prepare for auditing 2406
Configuring Amazon RDS for SQL Server for auditing 2406
Amazon RDS for SQL Server required permissions 2407
Permissions to the audit store database stored procedures service account 2407
Collector account permissions for audit store databases on Amazon RDS for SQL Server 2407
Management Database Account permissions for audit store databases on Amazon RDS for SQL Server 2407
Permissions to create the audit store database on Amazon RDS for SQL Server 2408
Permissions to upgrade the audit store database on Amazon RDS for SQL Server 2408
Installing the Audit Manager and Audit Analyzer Consoles 2409

Install Audit Manager Using the Individual Console Installer 2409
Install Audit Analyzer Using the Individual Console Installer 2409
Install Audit Manager and Audit Analyzer on the Same Computer Using the Main Installer 2410
Creating a Setup User Account for Installation 2411
Creating a New Installation 2412
To Create a New Installation and Management Database as a System Administrator 2412
How to Create an Installation without System Administrator Privileges 2413
To Create an Installation when you don’t have System Administrator Privileges 2413
Creating the First Audit Store 2414
Creating the First Audit Store Database 2414
Installing the Audit Collectors 2417

Set the Required Permission 2417
Install the Collector Service using the Setup Program 2417
Configure the Audit Collector Service 2417
Installing the Audit Management Server 2419

Configuring the Audit Management Server 2419
Installing the Centrify Agent for Windows 2420
Verify Prerequisites 2421
Installing Interactively Using the Setup Program 2422
Configuring the Agent Settings for Auditing 2422
Deciding to Install With or Without Joining the Computer to a Zone 2424
Installing Silently Without Joining a Zone 2424
Installing and Joining a Zone Silently 2425
Installing silently by Using the Microsoft Windows Installer 2425
Configuring Registry Settings 2425
Editing the Default Transform (MST) File 2426
Installing Silently from the Command Line 2427
Installing from a Central Location by Using Group Policy 2428
Enabling or Disabling Auditing on Windows Computers 2430
Enabling or Disabling Auditing on Linux and UNIX Computers 2431

Shell or Terminal Window Auditing 2431
Linux Desktop Auditing 2431
Installing an Centrify Agent for Unix/Linux 2434

Enabling or Disabling Video Capture Auditing 2435
Installing Additional Audit Manager or Audit Analyzer Consoles 2436
Checklist for Auditing Systems Outside of Active Directory 2437

Auditing Systems That are Inside a DMZ 2439
Managing an Installation 2441

Securing an Installation 2442
Securing an Audit Store with Trusted Collectors and Agents 2442
Disabling a Trusted List 2443
Using Security Groups to Define Trusted Computers 2443
Securing Network Traffic with Encryption 2444
Enabling Secure Socket Layer (SSL) communication 2444
Enabling Encryption for Microsoft SQL Server Express 2444
Using a Service Account for Microsoft SQL Server 2444
Configuring Selective Auditing 2446
Controlling Auditing by Using Group Policies 2446
Configuring agents to prefer collectors 2447
Specify Agents Use Collectors in the Same Site 2447
Audit License Enforcement 2448
Agents and Licenses from Previous Versions 2448
Enabling Audit Notification on Windows 2449
Preventing Users from Reviewing or Deleting Sessions 2450
Adding an Installation 2451
Delegating Administrative Tasks for a New Installation 2451
Opening an Installation in a New Console 2451
Closing an Installation 2451
Permission to Publish to Active Directory 2452
Synchronizing Installation Information 2452
Exporting installation information 2452
Removing or Deleting an Installation 2453
Managing Audit Store Databases 2454
Selecting a recovery model 2454
Configuring the Maximum Memory for Audit Store Databases 2454
Using Transact-SQL to Configure Minimum and Maximum Memory 2455
Estimating Database Requirements Based on the Data You Collect 2455
Reducing Color Depth to Decrease Disk Usage 2456
Adding New Audit Store Databases to an Installation 2456
Rotating the Active Database 2456
Creating a New Database for Rotation 2456
Database Archiving 2457
Queries During Rotation and Archiving 2457
Database Backups 2457
Reattaching a Restored Backup of a Database 2457
Allowed Incoming Accounts 2457
Detecting Data Tampering and Verifying Session Integrity 2458
Managing Audit Stores 2460
Configuring Audit Store Scope 2460
Configuring Permissions for an Audit Store 2460
Adding More Audit Stores to an Installation 2460
Managing the Audit Management Database 2462
Configuring Audit Management Database Scope 2462
Setting Audit Management Database Security 2462
Configuring the Maximum Memory for the Management Database 2463
Removing an Audit Management Database 2463
Maintaining Database Indexes 2464
Managing Collectors 2465
Monitoring Collector Status 2465
Modifying the Command Prompt Recognized by the Collector 2465
Removing Collectors 2466
Managing Audited Computers and Agents 2467
Monitoring Agent Status 2467
Configuring the UNIX Agent Off-line Database 2467
Removing an Audited Computer 2467
Delegating Administrative Permissions 2468
Permission to Publish to Active Directory 2468
Synchronizing installation information 2468
Managing Audit Roles 2469
Creating Custom Audit Roles 2469
Changing Audit Role Properties 2469
Granting Permissions to Manage Audit Roles 2470
Querying and Reviewing Audited Activity 2471
Accessing Audited Sessions 2472
Predefined Queries for Audit Events 2473
Predefined Queries for Audit Sessions 2474

Predefined Queries for Reports 2475
User Activity Report 2475
Privileged Activity Report 2475
Centrify Zone Administration Activity Report 2475
Login by User Report 2475
Login by Computer Report 2475
Authorization Failure Report 2475
Monitored Execution Report 2476
Detailed Execution Report 2476
File Monitor Report 2476
MFA Failure Report 2476
Creating New Session Queries 2477

Creating a new quick query 2477
Searching for a specific string 2477
Modifying a quick query 2477
Creating a new private query 2477
Adding multiple filters to the query criteria 2479
Editing and removing filters from the query criteria 2479
Specifying command or application filters in the query criteria 2479
Creating a New Shared Query 2479
Searching for shared queries 2480
Creating queries for audit events 2481

How Access Manager Roles Affect Audit Trail Events 2481
Querying by Audit Event Type or by Role 2482
Populating and Deleting the Roles Available 2482
Organizing queries in custom folders 2483
Exporting and Importing Query Definitions 2484
Displaying Session Information 2485
Adding Session Reviewers without Designating Auditing Roles 2486
Changing the Review Status for Audited Sessions 2487

Viewing status history 2487
Adding comments to a session 2487
Reviewing and deleting your own sessions 2487
Playing Back a Session 2488

Starting the Session Player Separately 2489
Using Window command line options 2489
Using the Uniform Resource Identifier (URI) 2489
Playing Back a Session from a Web Browser 2489
Exporting Sessions 2491

Export to Command List 2491
Export to Event List 2491
Copy Session URI 2491
Check Session Data Integrity 2491
Export to TXT 2491
Export Detailed Executions 2491
Export to CDF 2491
Export to WMV 2491
Deleting Sessions 2492
Viewing Sessions Outside of Audit Analyzer 2493

Viewing Sessions from Access Manager 2493
Viewing Sessions in Active Directory Users and Computers 2493
Using Find Sessions 2493
Specifying the Sessions to Find 2493
Using the Command Line Interface 2493
Using a web browser to access sessions 2493
Using Tags with Sessions 2495
Assigning Tags to Sessions 2495
Viewing Tags Associated with a Session 2495
Searching for Sessions Associated with Tags 2495
Advanced Monitoring 2496

Set up Advanced Monitoring 2496
Advanced Monitoring Requirements 2496
Configuring Advanced Monitoring 2496
Enabling Advanced Monitoring 2497
Using the Advanced Monitoring Reports 2497
Troubleshooting and Common Questions 2499
Checking the Status of the UNIX Agent 2499
Configuring the Installation for an Agent 2499
Checking for Disconnected Agents using Audit Manager 2499
Starting and Stopping the UNIX Agent 2499
Detecting the Server Suite Installation Status 2499
Viewing and Changing Log File Settings 2500
Enabling Detailed Logging for Linux and UNIX Computers 2500
Enabling Detailed Logging for the Collector Service 2501
Enabling Detailed Logging for Auditing Consoles 2501
Tracing Database Operations 2502
Starting a Database Trace 2502
Stopping the Database Trace 2502
Exporting the Database Trace for a Management Database 2502
Exporting the database trace for audit store databases 2503
Delegating Database Trace Management 2503
Stopping Auditing on a Computer 2503
Resuming Auditing if the Agent Stops 2503
Allowing Users to Log in when Auditing is Stopped 2503
Determining Collector Status and Connectivity 2504
Resolving Connectivity Issues between a Collector and an Audit Store 2504
Resolving Authentication Issues 2505
Monitoring Collector Performance Counters 2505
Managing Microsoft SQL Server Databases 2506
Selecting SQL Server or Windows Authentication 2506
Connecting to an Installation or Database 2506
Assigning the Service Principal name for SQL Server 2506
Publishing Installation Information in Active Directory 2506
Monitoring File System Disk Space Usage 2507
Command Line Programs for Managing Audited Sessions 2508

How to Use Command Line Programs 2508
Displaying Usage Information and Man Pages 2508
Using Commands for Administrative Tasks 2508
Configuring Duplicate Audit Session Cleanup 2509
Downloading the Tenant SSH Public Key 2509
Installing the UNIX Agent on Remote Computers 2511
Installing the Agent Silently using a Configuration File 2511
Using Other Programs to Install the UNIX Agent 2511
Permissions Required to Perform Administrative and Auditing Tasks 2513

Setting and Synchronizing Audit-related Permissions 2513
Component by Component Permissions 2513
Installation Permissions 2514
Setting Installation Permissions 2515
Management Database Permissions 2515
Setting Management Database Permissions 2516
Audit Store and Audit Store Database Permissions 2516
Audit Role Permissions 2517
Auditor Permissions 2517
Sizing Recommendations for Audit Installations 2518

Planning an Audit and Monitoring Service Deployment 2518
SQL Server 2518
Number of Concurrently Audited Users 2518
What Needs to be Captured 2518
Who Needs to be Audited 2519
UNIX/Linux and Windows 2519
Query Performance 2519
Audit Data Retention Policy 2519
System Overheads 2519
Latency 2519
Best Practices for an Audit Installation 2519
Plan Based on Concurrently Audited Users 2519
Avoid Single Box Deployment 2519
Control the Amount of Data 2520
Scope the Audit Stores Efficiently 2520
Estimate Storage Requirement based on Pilot Data 2520
Maintain Databases Periodically 2520
Control the Size of Active Databases 2520
Plan Database Rotation based on Retention Policy 2520
Configure SQL Server Optimally 2521
Other Recommendations 2521
Understand that any Hardware has its Limits 2521
Guidelines for determining hardware configuration 2521
Identifying Typical Deployment Issues 2523
Large Spool Files on Audited Systems 2523
Constant High CPU on Collector/SQL Server 2523
Low Despool Rate 2524
False “Agent disconnected” Alerts 2524
Too many SQL Server Tasks in Queue 2524
Settings to Adjust for Performance Improvement 2524
Conclusion 2525
Introduction to the Databases Used for Auditing 2526
Introduction to the Databases Used for Auditing 2527

Management Databases Store Installation Information 2528
Audit Store Databases Store Audited Sessions 2529
Using Multiple Databases for the Audit Store 2530
Detaching and Retiring Audit Store Databases 2531
Automating Database Rotation 2532

Audit-related object reference 2534
Account Class 2535

Syntax 2535
class Account 2535
Properties of the Account class 2535
Description of the Account class 2535
See also 2535
IsSystemAccount Property 2535
Syntax 2535
Return Value 2535
Discussion of the IsSystemAccount Property 2535
Example 2535
See also 2536
IsWindowsAccount Property 2536
Syntax 2536
Return Value 2536
Discussion 2536
Example 2536
See also 2537
UserName Property 2537
Syntax 2537
Return Value 2537
Discussion 2537
Example 2537
Accounts class 2538
Syntax 2538
Discussion 2538
Example 2538
See also 2538
AuditServer class 2539

Syntax 2539
Properties 2539
Discussion 2539
See also 2539
DatabaseName Property 2539
Syntax 2539
Return Value 2539
Discussion 2539
See also 2539
Name Property (management database) 2539
Syntax 2540
Return Value 2540
Discussion 2540
OutgoingAccount Property 2540
Syntax 2540
Return Value 2540
Discussion 2540
ServerName Property 2540
Syntax 2540
Return Value 2540
Discussion 2540
AuditServers class 2541

Syntax 2541
Discussion 2541
See also 2541
AuditStore class 2542
Syntax 2542
Properties 2542
Methods 2542
Discussion 2542
See also 2542
ActiveDatabase Property 2542
Syntax 2542
Return Value 2543
Discussion 2543
See also 2543
Databases Property 2543
Syntax 2543
Return Value 2543
Discussion 2543
See also 2543
Name property (audit store) 2543
Syntax 2543
Return Value 2543
Discussion 2543
See also 2543
AddDatabase Method 2543
Syntax 2543
Parameters 2544
Return Value 2544
Errors 2544
Discussion 2544
Example 2544
AddDatabaseByScript Method 2545
Syntax 2545
Parameters 2545
Return Value 2545
Errors 2545
Discussion 2545
Example 2545
AttachDatabase method 2546
Syntax 2546
Parameters 2546
Return Value 2546
Errors 2546
Discussion 2546
Example 2546
See also 2547
ChangeActiveDatabase Method 2547
Syntax 2547
Parameters 2547
Errors 2547
Discussion 2547
Example 2547
See also 2547
DetachDatabase Method 2548
Syntax 2548
Parameters 2548
Errors 2548
Discussion 2548
Example 2548
GetDatabase Method 2548
Syntax 2548
Parameters 2548
Return Value 2548
Errors 2549
Discussion 2549
Example 2549
AuditStoreDatabase Class 2550

Syntax 2550
Properties 2550
Methods 2550
Discussion 2550
See also 2550
ActiveEndTime Property 2550
Syntax 2551
Return Value 2551
See also 2551
ActiveStartTime Property 2551
Syntax 2551
Return Value 2551
See also 2551
AuditServerAccounts Property 2551
Syntax 2551
Return Value 2551
Discussion 2551
CollectorAccounts Property 2551
Syntax 2551
Return Value 2552
See also 2552
DatabaseName Property 2552
Syntax 2552
Return Value 2552
Discussion 2552
IsActive Property 2552
Syntax 2552
Return Value 2552
Discussion 2552
See also 2552
IsRetired Property 2552
Syntax 2553
Return Value 2553
Discussion 2553
See also 2553
Name Property (Audit Store Database) 2553
Syntax 2553
Return Value 2553
Discussion 2553
Example 2553
ServerName Property 2553
Syntax 2553
Return Value 2553
Discussion 2554
See also 2554
AddAuditServerAccount Method 2554
Syntax 2554
Parameters 2554
Errors 2554
Discussion 2554
Example 2554
See also 2555
AddCollectorAccount Method 2555
Syntax 2555
Parameters 2555
Errors 2555
Discussion 2556
Example 2556
See also 2556
AuditStoreDatabases class 2557

Syntax 2557
Example 2557
See also 2557
Connection class 2558

Syntax 2558
Constructors 2558
Methods 2558
Discussion 2558
Connection Constructor 2558
Syntax 2558
Parameters 2558
Discussion 2558
GetInstallation Method 2559
Syntax 2559
Parameters 2559
Return value 2559
Errors 2559
Discussion 2559
Example 2559
See also 2559
Installation class 2560
Syntax 2560
Properties 2560
Methods 2560
Discussion 2560
See also 2560
AuditServers property 2560
Syntax 2560
Return value 2560
Discussion 2560
See also 2560
CurrentAuditServer property 2561
Syntax 2561
Return value 2561
Discussion 2561
See also 2561
Name property (audit installation) 2561
Syntax 2561
Return value 2561
Discussion 2561
GetAuditStore method 2561
Syntax 2561
Parameters 2561
Errors 2561
Example 2562
See also 2562
Publish method 2562
Syntax 2562
Errors 2562
Discussion 2562
Example 2562
Using Find Sessions 2564
Starting Find Sessions 2565
Find Sessions Return Codes 2566

Specifying Advanced Criteria 2569
Adding Advanced Criteria 2570
Editing and Removing Advanced Criteria 2571
Finding Sessions From a Command Line 2572

Find Sessions Command Line Usage Examples 2573
Editing and removing advanced criteria 2575
Find sessions command line usage examples 2577
Finding sessions using AQL syntax 2579
Simplifying AQL queries 2580

Audit Query Language overview 2581
Backus-Naur Form (BNF) definition of AQL 2581
AQL usage examples 2582
AQL quick search terms 2583
AQL audit trail types example 2584
AQL group-by example 2584
AQL Predicates 2584
AQL predicate behavior examples 2585
AQL string predicate behavior 2585
AQL number predicate behavior 2585
AQL boolean predicate behavior 2586
AQL Date and time predicate behavior 2586
AQL IP predicate behavior 2586
AQL enumeration predicate behavior 2587
AQL keywords 2587
AQL usage examples 2588
Accessing sessions via web browser 2590
Opening Find Sessions from a web browser 2591
Playing back a session from a web browser 2592

To get the session identifier: 2592
To play back a specific session from a web browser: 2592
Exporting sessions and session data 2593
Exporting a session list 2594
Exporting Windows events 2595
Exporting UNIX command lists 2596

Searching for sessions by role or trouble-ticket information 2596
Exporting UNIX input 2597
Exporting UNIX input and output 2598
Suppressing warning messages 2599
Deleting sessions 2600
Sample script for deleting multiple sessions 2601
Using Windows and Linux/Unix 2602

User's Guide for Linux/Unix 2603
Getting started 2604
Verify You can Log in 2605

Multi-Factor Authentication 2605
Checking Your Rights and Role Assignments 2606
Working with Command Rights 2607
Using Command Rights in a Standard Shell 2607
Using Command Rights in a Restricted Shell Environment 2607
Running Unauthorized Commands 2607
Setting or Changing your Active Role 2607
Using PAM Application Rights 2608
Using Secure Shell Session Rights 2609
Role-based Auditing of Session Activity 2610
User's Guide for Windows 2611

Introduction to Delinea software 2612
What is Server Suite? 2612
Using Delinea software to Manage Access to Windows Computers 2612
Auditing Role-based Activity 2612
Roles Grant Different Types of Access Rights 2612

Computers Must be in a Zone for Roles to be Available 2613
Using the dzjoin Command 2613
Using the dzleave Command 2614
Why You Should Use Roles for Administrative Tasks 2614
What Gets Installed on a Managed Computer 2615

Getting Started 2616
Verify That You Can Log On 2616
What to Do if the Delinea Icon is Not Displayed 2616
What to Do if You Cannot Log On 2617
Checking Your Rights and Role Assignments 2617
Working with Desktop Access Rights 2618
Running an Individual Application Using a Role 2618
Creating a New Desktop 2620
Setting a Desktop Name 2621
Working with Server Core Computers 2630

Server Core supported platforms 2630
Joining a zone 2630
Viewing authorization details 2630
Troubleshooting 2632
Evaluations 2636
Evaluation Guide for Windows 2637
Setting up the Evaluation Environment 2638
Preview of Tasks 2638
Basic Requirements for the Evaluation 2638

Preparing an Active Directory Domain Controller 2639
Selecting a Windows Domain Computer 2639
Downloading Delinea Software for Windows Evaluations 2639
Downloading Server Suite Software for Windows Evaluations 2640
Creating an Active Directory User and Group 2640
Preparing to Evaluate Access Management 2640

Configuring Active Directory Using Access Manager 2641
Assigning Yourself the Default Windows Login Role 2642
Preparing to Evaluate Auditing 2643
Identifying a Microsoft SQL Server Instance 2643

Installing the Auditing Components 2643
Installing the Agent for Windows 2644
Configuring the Agent 2644
Configuring Agent Settings for Audit and Monitoring Service 2645
Selecting the Maximum Color Quality for Recorded Sessions 2646
Configuring Agent Settings for Offline Audit and Monitoring Service Storage 2646
Configuring Agent Settings for the Identity Platform 2646
Configuring Agent Settings for Privilege Elevation 2647
How Authentication Works for Windows 2648
Providing Access Control and Accountability 2648
Organizing Computers and Access Rights 2648

Restricting Access to Administrative Privileges 2648
Auditing User Activity on a Managed Computer 2649
Creating and Using Roles and Desktops 2650
Verifying that your Account is Assigned Basic Login Rights 2650
Assigning the Windows Login Role to a Group 2650

Adding Predefined Rights to a Zone 2651
Creating an Application Right 2651
Creating a Desktop Right 2654
Switching Among Active Desktops 2655
Creating a Network Right 2655

Reviewing Rights and Roles in the Authorization Center 2657
Auditing Sessions 2658
Using Audit Analyzer to Replay a Session 2658

Magnifying the Recorded Session 2658
Controlling Playback Speed or Session Location 2659
Marking Sessions for Review or Action 2659
Using the Indexed Event List 2659
Creating Custom Queries 2660
Creating a Quick Query 2660
Auditing Only Specific Events 2661

Specifying which Roles or Desktops to Audit 2661
Audit Trail of Privileged Events 2661
Additional Auditing Tools 2662
Evaluation Guide for Linux and Unix 2663

Preparing Hardware and Software for an Evaluation 2664
What You Need for the Evaluation 2665
Windows Computer Requirements 2666
Linux and UNIX Computer Requirements 2667
Domain Controller Requirements 2668
Verifying Administrative Access for the Evaluation 2669
Checking the DNS Environment 2670
Using a Virtual Environment 2671
Downloading Server Suite Software for UNIX Evaluations 2672

Downloading Server Suite Windows Software 2672
Downloading the Linux and UNIX Agents 2672
Verifying that You Have Active Directory Permissions 2673
Next Steps 2674
Configuring the Basic Evaluation Environment 2675

Creating an Organizational Unit 2676
Create Additional Organizational Units 2676
Delegating Control for the Organizational Unit 2677
Installing and Configuring Access Manager 2678
Installing the Server Suite Agent for 2680
Joining the Domain 2680
Verifying your Progress in Access Manager 2681
Adding and Provisioning an Evaluation User and Group 2682

Verify Access by Logging On 2682
Creating a UNIX Administrator Role 2684
Defining a Command Right and a New Role 2684
Verifying Administrative Privileges 2685
Viewing Effective Rights 2686
Creating Child Zones and a Service Administrator Role 2687
Defining Command Rights and a New Role for Apache Administrators 2687
Verifying the Success of the Script 2688
Adding Rights to the New Role Definition 2688
Assigning the Apache Administrator Role to a Group 2689
Deploying Group Policies to UNIX Computers 2690
Configuring User Mapping by Group Policy 2690
Configuring Password Prompts 2690
Next Steps 2691
Exploring Additional Management Tools 2692

Adding UNIX Profiles Automatically 2693
Managing UNIX Information from a UNIX Terminal 2695
Using UNIX Commands 2695
Using ADEdit 2695
ADEdit Application 2695
ade_lib Tcl Library 2696
Using adedit Sample Scripts 2696
Next Steps 2698
Auditing Sessions 2699
Install Auditing Components on Windows 2700
Configure a New Audit Installation 2701
Enabling Linux Desktop Auditing 2702
Verify that Auditing is Enabled 2703
Viewing Sessions with Predefined Queries 2704
Replaying a Session 2705
Managing Audited Sessions 2706

Using Command Summaries 2706
Exporting Sessions 2706
Viewing and Editing Session Properties 2706
Updating Review Status for a Session 2706
Deleting Sessions 2706
Creating Custom Queries 2707
Frequently Asked Questions 2708
How Do I Accommodate Legacy or Conflicting Identity Information? 2709

Can I have Separate Role Assignments for Specific Computers? 2710
How Can I Manage Access Rules for Computers in Different Zones? 2711
How do I Manage Access Privileges during Application Development? 2712
How do I Terminate a User Account but Keep the Account Profile? 2713
Can Active Directory Credentials be used to Log in to Applications? 2714

Can Active Directory Credentials be used for Phone and Tablet Users? 2715
How Do I Migrate from NIS Maps to Server Suite? 2716
Removing Software after an Evaluation 2717
Removing Authentication and Privilege Services 2718
Removing the Audit and Monitoring Service 2719

Removing Server Suite Agents 2720
Delinea Server Suite Free (formerly Centrify Express) 2721
Delinea Server Suite Free Administrator's Guide for Linux and UNIX 2722
Introduction 2723
Key Components 2723

Features Not Supported by Delinea Server Suite Free 2723
Managed Computers are Active Directory Clients 2723

What the Agent Does 2724
Agents Consist of Multiple Components 2724
Provisioning is Automatic 2724

Deciding Whether to Use Zones 2724
Working With a Single zone 2724
All Active Directory Users Have Access 2725
How the Agent Generates Profile Attributes 2725
Using Delinea Server Suite Free to Deploy Agents 2725

Comparing Delinea Server Suite Free to other services 2725
Installing Delinea Agents 2727
Selecting a Deployment Option 2727
Installing and Using Delinea Server Suite Free 2727

Minimum Hardware Requirements 2727
Network Connectivity Requirements 2727
Account Credential Requirements 2727
Download the Software and Run the Setup Program 2727
Options for Deploying Agent Packages 2727
Install Interactively on a Computer 2728
Using Other Programs to Install 2728
Verifying the Installation 2729
Troubleshooting adcheck Errors 2729

Correcting Errors for the Operating System Check 2729
Correcting Warnings and Errors for the Network Check 2729
Correcting errors for the domain controller check 2729
Joining a Domain After Installation 2730

Restarting Services 2730
Upgrading Delinea Server Suite Free 2730
Upgrading Windows Components 2730
Upgrading Agents on Managed Computers 2731
Adding Optional Packages After Installation 2731
Removing Delinea Server Suite Free 2732

Working with Managed Computers 2733
Logging on to Your Computer 2733
Getting Configuration Information 2733
Applying Password Policies 2733

Changing Passwords 2733
Changing Your Own Password 2733
Changing Another User’s Password 2734
Working in Disconnected Mode 2734
Mapping Local Accounts to Active Directory 2734
Using the pam.mapuser Parameter 2735
Setting a Local Override Account 2735
Using Samba 2735
Setting Auto Zone Configuration Parameters 2735
Troubleshooting Tips and Tools 2737
Addressing Log On Failures 2737
Understanding Diagnostic Tools and Log Files 2737
Configuring Logging 2738

Enabling Logging for the Agent 2738
Setting the Logging Level 2738
Logging Details for a Specific Component 2739
Logging to the Circular In-memory Buffer 2739
Collecting Diagnostic Information 2739
Resolving Domain Name Service (DNS) issues 2739
Using Command-Line Programs 2741
Understanding When to use Command-Line Programs 2741
Supported Command-Line Programs 2741
Displaying Usage Information and Man Pages 2742
Customizing Operations Using Configuration Parameters 2743
Auto Zone Configuration Parameters 2743
DNS-related configuration parameters 2744
Delinea Server Suite Free Quick Start 2745
Installing the Agent and Joining a Domain 2745
Next steps 2746
Integrations 2747
Authentication Guide for IBM DB2 2748
Contents 2748
Authentication and Authorization in IBM DB2 2749
Authentication for DB2 Security and Authentication Plug-Ins 2749

DB2 and Delinea Plug-In Compatibility 2749
Username-Password Plug-In 2749
GSSAPI Plug-In 2749
Group Plug-In 2750
Make Connections to the DB2 Administration Server 2750

Install and Configure the Server 2751
Software Requirements 2751
Unzip and Restore the Authentication Service for DB2 Package 2751
Unzip and Restore AIX Files 2751
Unzip and Restore Linux Files 2752
Unzip and Restore Solaris files 2752
Install Authentication Service for DB2 Using the Platform Install Program 2752
Install the AIX Files 2752
Install the Linux Files 2752
Install the Solaris Files 2752
Install and Configure Plug-Ins Using the setupdb2 Script 2753

Run the setupdb2.sh Script 2753
Install Manually 2758

Copy the plug-ins 2758
Setup for the Username-Password Plug-In 2758
Set up for the GSSAPI PlugIn 2759
Configure the DB2 Instance 2761
Verify the Setup 2762
Upgrade from an Earlier Release 2762

Upgrade Using the setupdb2.sh Script 2762
Upgrade Manually 2763
If an Installation Attempt Fails 2763
Set up the GSSAPI DB2 Client 2764
DB2 Client Installation on a UNIX Computer 2764
Install on UNIX Using the 2764
Install on UNIX Manually 2764
Test the Installation 2765
Uninstall DB2 Plug-Ins 2766
Execute the uninstalldb2 Script 2766

Determine the Instance Name 2766
Run the uninstalldb2.sh Script 2766
Manually Reset DB2 Configuration Variables 2767
References 2767
Adopt a Service Account 2768
Option 1: Reset the Service Account Password 2768
Option 2: Provide the Existing Service Account Password 2768

Delinea-Enabled PuTTY User’s Guide 2769
Using the Delinea PuTTY Client 2770
Accessing Remote Server Suite-Managed Computers 2770
Installing Delinea PuTTY 2770
Configuring the Delinea PuTTY Client 2771

Starting the Delinea PuTTY Client 2771
Configuring Kerberos Authentication for Secure Shell Connections 2771
Saving and Managing Passwords for Remote Sessions 2773
Configuring Group Policies for Delinea PuTTY 2773
Using Other Centrify-Enabled PuTTY Programs 2774
Getting More Information 2775
Configure Delinea Authentication Service and RSA SecurID 2776
Prerequisites 2777
RSA Installation Prerequisites 2777
Install and ConfigureAuthentication Service and RSA SecurID 2778
Installation Overview 2778
Configure the PAM Modules for Use with DirectControl and SecurID 2779
Configure the /etc/pam.d/system-auth File for Linux 2779

Configure the pam.conf File for Solaris and AIX 2779
Require Token Authentication for Specific Groups or Local Users 2779
Configure SSH to Require SecurID 2780
Configure SecurID for Use with Server Suite Zone-based Role and Privilege Execution 2782
Verify the Installation 2783

Control Machine Access with Server Suite 2784
Known Issues 2785
Introduction to Samba and Adbindproxy 2786
Using Server Suite technology with Samba 2787

What is Samba? 2787
What is Server Suite-enabled Samba? 2787
Server Suite-Enabled Samba Architecture 2787
Installing the Centrify Samba Integration Components 2789
Installation Process Overview 2789
Installation Overview for Computers New to both Server Suite and Samba 2789
Installation Overview for Computers New to Server Suite 2789
Upgrade Overview for Computers with Server Suite-Enabled Samba 2790
What’s in the adbindproxy Package 2791
Installing the adbindproxy Components 2791
Updating the Samba Files 2792
Migrating Existing Samba Users to Server Suite 2793

Migrating UNIX Profiles to Active Directory 2793
Migrating Users if Winbind is Configured in /etc/nsswitch.conf 2793
Migrating Users with the adbindproxy perl Script 2793
Migrating Samba Servers to Server Suite Zones 2794
Configuring the Samba integration 2795
Running the adbindproxy.pl Script 2796

Finishing Up 2799
Verifying the Samba Integration 2800

Accessing Samba from a UNIX Client Session 2800
Purging and Reissuing Kerberos Tickets on UNIX Computers 2800
Verifying the Version of Samba You Are Using 2800
If You Don’t See the Correct Samba Shares 2801
Accessing Samba Shares from a Windows Desktop 2801
Modifying the Samba smb.conf Configuration File 2802

A sample Samba smb.conf Configuration File 2802
SMB.conf File Variations for Different Platforms 2803
Testing Changes to the smb.conf File 2803
Using adbindproxy.pl 2805

Synopsis 2805
adbindroxy.pl Options 2805
Examples 2806
Developer Tools 2808
Adedit Command Reference and Scripting Guide 2809
About this Guide 2809
Viewing Command Help 2809
Introduction 2810
How ADEdit uses Tcl 2810
What ADEdit Provides 2810
Administration Across Domains and Forests 2810
Options for Execution 2810
Library of Predefined Procedures 2811
How ADEdit Works with Other Centrify Components 2811
Active Directory and ADEdit 2811
Managed Computers and ADEdit 2811
Other Administrative Options 2811
ADEdit Components 2812
The ADEdit Application 2812
The ade_lib Tcl Library 2812
ADEdit Context 2812
Context Persistence 2813
Pushing and Popping Contexts 2813
Context Cautions 2813
Logical Organization for ADEdit Commands 2813
Getting Started with ADEdit 2814
Starting ADEdit for the First Time 2814
Basic Command Syntax 2814
Arguments and Options 2814
Command Execution and Results 2814
Using Command Abbreviations 2814
Using the Command History 2815
Using the Help Command 2815
Learning to Use ADEdit 2815
Binding to a Domain and Domain Controller 2816
Authentication 2816
Binding Scope and Persistence 2817
Binding and Join Differences 2817
Controlling Binding Operation 2817
Selecting an Object 2817
Selection Commands 2817
Selection as Part of Context 2818
Persistence 2818
Creating a New Object 2818
Examining Objects and Context 2818
Getting Field Values for Objects 2818
Getting Current Context Information 2818
Modifying or Deleting Selected Objects 2819
Deleting an Object 2819
Saving Selected Objects 2819
Pushing and Popping Context 2819
Creating ADEdit Scripts 2820
Starting with a Simple Script 2820
Executing an ADEdit Script using ADEdit 2821
Running an ADEdit Script as an Executable from the Command Line 2821
Running an ADEdit Script as a Shell Script 2821
ADEdit Commands Organized By Type 2822

General Purpose Commands 2822
Context Commands 2822
Object Management Commands 2822
Zone Object Management Commands 2822
Zone User Object Management Commands 2823
Zone Group Object Management Commands 2824
Zone Computer Object Management Commands 2824
Computer Role Object Management Commands 2825
Role Object Management Commands 2825
Role Assignment Object Management Commands 2826
PAM Application Object Management Commands 2826
Command (dz) Object Management Commands 2827
NIS Map Object Management Commands 2827
Active Directory Object Management Commands 2828
Utility Commands 2828
Security Descriptor Commands 2829
Using the Demonstration Scripts 2830
Zone Containers and Nodes 2830
Create Tcl Procedures 2831
Create Active Directory Group Procedure 2832
Create Active Directory User Procedure 2832
Reading Command Line Input 2832
MktDept.sh 2832
getopt-example 2833
Create a Parent Zone 2833
CreateParentZone 2834
Create Child Zones 2834
CreateChildZones 2834
Create Privileged Commands and Roles 2835
Privileges and Role Defined in a File 2835
MakeRole 2836
Privileges and Roles Defined in the Script 2837
ApacheAdminRole 2837
Add and Provision UNIX Users 2838
users.txt 2838
AddUnixUsers 2838
Simple Tools 2839
computers-report 2839
useracc-report 2840
user-report 2841
GetComputers 2842
Run a Script from a Script 2842
setenv 2842
GetZones 2843
GetUsers 2843
GetGroups 2844
GetChildZones 2844
ADEdit Command Reference 2845

add_command_to_role 2845
Zone Type 2845
Syntax 2845
Abbreviation 2845
Options 2845
Arguments 2845
Return Value 2845
Examples 2846
Related Commands 2846
add_map_entry 2846
Zone Type 2846
Syntax 2846
Abbreviation 2846
Options 2846
Arguments 2846
Return Value 2847
Example 2847
add_map_entry_with_comment 2847
Zone Type 2847
Syntax 2847
Abbreviation 2847
Options 2847
Arguments 2847
Return Value 2848
Example 2848
add_object_value 2848
Zone Type 2848
Syntax 2848
Abbreviation 2848
Options 2848
Arguments 2848
Return Value 2849
Examples 2849
add_pamapp_to_role 2849
Zone Type 2849
Syntax 2849
Abbreviation 2849
Options 2849
Arguments 2849
Return Value 2850
Examples 2850
add_sd_ace 2850
Zone Type 2850
Syntax 2850
Abbreviation 2850
Options 2850
Arguments 2851
Return Value 2851
Examples 2851
bind 2851
Zone Type 2852
Syntax 2852
Abbreviation 2852
Options 2852
Arguments 2852
Return Value 2853
Examples 2853
clear_rs_env_from_role 2853
Zone Type 2853
Syntax 2853
Abbreviation 2853
Options 2853
Arguments 2853
Return Value 2854
Examples 2854
create_computer_role 2854
Zone Type 2854
Syntax 2854
Abbreviation 2854
Options 2854
Arguments 2854
Return Value 2855
Examples 2855
create_zone 2855
Zone Type 2855
Syntax 2856
Abbreviation 2856
Options 2856
Arguments 2856
Return Value 2856
Examples 2856
Classic Zone 2856
Hierarchical Zone 2857
Computer-specific Zone 2857
delegate_zone_right 2857
Zone Type 2857
Syntax 2857
Abbreviation 2857
Options 2857
Arguments 2857
Return Value 2858
Examples 2858
delete_dz_command 2859
Zone Type 2859
Syntax 2859
Abbreviation 2859
Options 2859
Arguments 2859
Return Value 2859
Examples 2859
delete_local_group_profile 2859
Zone Type 2860
Syntax 2860
Abbreviation 2860
Options 2860
Arguments 2860
Return Value 2860
Examples 2860
delete_local_user_profile 2861
Zone Type 2861
Syntax 2861
Abbreviation 2861
Options 2861
Arguments 2861
Return Value 2861
Examples 2861
delete_map_entry 2862
Zone Type 2862
Syntax 2862
Abbreviation 2862
Options 2862
Arguments 2862
Return Value 2862
Examples 2862
delete_nis_map 2862
Zone Type 2863
Syntax 2863
Abbreviation 2863
Options 2863
Arguments 2863
Return Value 2863
Examples 2863
delete_object 2863
Zone Type 2863
Syntax 2864
Abbreviation 2864
Options 2864
Arguments 2864
Return Value 2864
Examples 2864
delete_pam_app 2864
Zone Type 2864
Syntax 2864
Abbreviation 2864
Options 2864
Arguments 2865
Return Value 2865
Examples 2865
delete_role 2865
Zone Type 2865
Syntax 2865
Abbreviation 2865
Options 2865
Arguments 2865
Return Value 2865
Examples 2866
delete_role_assignment 2866
Zone Type 2866
Syntax 2866
Abbreviation 2866
Options 2866
Arguments 2866
Return Value 2866
Examples 2866
delete_rs_command 2867
Zone Type 2867
Syntax 2867
Abbreviation 2867
Options 2867
Arguments 2867
Return Value 2867
Examples 2867
delete_rs_env 2868
Zone Type 2868
Syntax 2868
Abbreviation 2868
Options 2868
Arguments 2868
Return Value 2868
Examples 2868
delete_sub_tree 2868
Zone Type 2869
Syntax 2869
Abbreviation 2869
Options 2869
Arguments 2869
Return Value 2869
Examples 2869
delete_zone 2870
Zone Type 2870
Syntax 2870
Abbreviation 2870
Options 2870
Arguments 2870
Return Value 2870
Examples 2870
delete_zone_computer 2871
Zone Type 2871
Syntax 2871
Abbreviation 2871
Options 2871
Arguments 2871
Return Value 2871
Examples 2871
delete_zone_group 2871
Zone Type 2872
Syntax 2872
Abbreviation 2872
Options 2872
Arguments 2872
Return Value 2872
Examples 2872
delete_zone_user 2872
Zone Type 2872
Syntax 2872
Abbreviation 2873
Options 2873
Arguments 2873
Return Value 2873
Examples 2873
dn_from_domain 2873
Zone Type 2873
Syntax 2873
Abbreviation 2873
Options 2873
Arguments 2873
Return Value 2874
Examples 2874
dn_to_principal 2874
Zone Type 2874
Syntax 2874
Abbreviation 2874
Options 2874
Arguments 2874
Return Value 2874
Examples 2875
domain_from_dn 2875
Zone Type 2875
Syntax 2875
Abbreviation 2875
Options 2875
Arguments 2875
Return Value 2875
Examples 2875
explain_sd 2875
Zone Type 2876
Syntax 2876
Abbreviation 2876
Options 2876
Arguments 2876
Return Value 2876
Examples 2876
forest_from_domain 2877
Zone Type 2877
Syntax 2877
Abbreviation 2877
Options 2877
Arguments 2877
Return Value 2877
Examples 2877
get_adinfo 2878
Zone Type 2878
Syntax 2878
Abbreviation 2878
Options 2878
Arguments 2878
Return Value 2878
Examples 2878
get_bind_info 2878
Zone Type 2879
Syntax 2879
Abbreviation 2879
Options 2879
Arguments 2879
Return Value 2879
Examples 2879
get_child_zones 2879
Zone Type 2880
Syntax 2880
Abbreviation 2880
Options 2880
Arguments 2880
Return Value 2880
Examples 2880
get_dz_commands 2881
Zone Type 2881
Syntax 2881
Abbreviation 2881
Options 2881
Arguments 2881
Return Value 2881
Examples 2881
get_dzc_field 2881
Zone Type 2882
Syntax 2882
Abbreviation 2882
Options 2882
Arguments 2882
Getting the cmd and path field values 2882
Getting environment variable field values 2882
Getting the command priority field value 2883
Getting the umask field value 2883
Getting command properties from the flags field value 2883
Return Value 2883
Examples 2883
get_group_members 2884
Zone Type 2884
Syntax 2884
Abbreviation 2884
Options 2884
Arguments 2884
Return Value 2885
Examples 2885
get_local_group_profile_field 2885
Zone Type 2885
Syntax 2885
Abbreviation 2885
Options 2885
Arguments 2885
Return Value 2886
Examples 2886
get_local_groups_profile 2886
Zone Type 2886
Syntax 2886
Abbreviation 2887
Options 2887
Arguments 2887
Return Value 2887
Examples 2887
get_local_user_profile_field 2887
Zone Type 2887
Syntax 2887
Abbreviation 2888
Options 2888
Arguments 2888
Return Value 2888
Examples 2888
get_local_users_profile 2889
Zone Type 2889
Syntax 2889
Abbreviation 2889
Options 2889
Arguments 2889
Return Value 2889
Examples 2889
get_nis_map 2890
Zone Type 2890
Syntax 2890
Abbreviation 2890
Options 2890
Arguments 2890
Return Value 2890
Examples 2890
get_nis_map_field 2891
Zone Type 2891
Syntax 2891
Abbreviation 2891
Options 2891
Arguments 2891
Return Value 2891
Examples 2891
get_nis_map_with_comment 2892
Zone Type 2892
Syntax 2892
Abbreviation 2892
Options 2892
Arguments 2892
Return Value 2892
Examples 2892
get_nis_maps 2893
Zone Type 2893
Syntax 2893
Abbreviation 2893
Options 2893
Arguments 2893
Return Value 2893
Examples 2893
get_object_field 2894
Zone Type 2894
Syntax 2894
Abbreviation 2894
Options 2894
Arguments 2894
Return Value 2894
Examples 2894
get_object_field_names 2895
Zone Type 2895
Syntax 2895
Abbreviation 2895
Options 2895
Arguments 2895
Return Value 2895
Examples 2895
get_objects 2896
Zone Type 2896
Syntax 2896
Abbreviation 2896
Options 2896
Arguments 2896
Return Value 2897
Examples 2897
get_pam_apps 2897
Zone Type 2897
Syntax 2897
Abbreviation 2897
Options 2897
Arguments 2897
Return Value 2898
Examples 2898
get_pam_field 2898
Zone Type 2898
Syntax 2898
Abbreviation 2898
Options 2898
Arguments 2898
Return Value 2899
Examples 2899
get_parent_dn 2899
Zone Type 2899
Syntax 2899
Abbreviation 2899
Options 2899
Arguments 2899
Return Value 2900
Examples 2900
get_pending_zone_groups 2900
Zone Type 2900
Syntax 2900
Abbreviation 2900
Options 2900
Arguments 2900
Return Value 2900
Examples 2900
get_pending_zone_users 2901
Zone Type 2901
Syntax 2901
Abbreviation 2901
Options 2901
Arguments 2901
Return Value 2901
Examples 2901
get_pwnam 2902
Zone Type 2902
Syntax 2902
Abbreviation 2902
Options 2902
Arguments 2902
Return Value 2902
Examples 2902
get_rdn 2902
Zone Type 2903
Syntax 2903
Abbreviation 2903
Options 2903
Arguments 2903
Return Value 2903
Examples 2903
get_role_apps 2903
Zone Type 2903
Syntax 2903
Abbreviation 2903
Options 2904
Arguments 2904
Return Value 2904
Examples 2904
get_role_assignment_field 2904
Zone Type 2904
Syntax 2904
Abbreviation 2905
Options 2905
Arguments 2905
Return Value 2905
Examples 2905
get_role_assignments 2906
Zone Type 2906
Syntax 2906
Abbreviation 2906
Options 2906
Arguments 2906
Return Value 2906
Examples 2907
get_role_commands 2907
Zone Type 2907
Syntax 2907
Abbreviation 2907
Options 2907
Arguments 2907
Return Value 2907
Examples 2908
get_role_field 2908
Zone Type 2908
Syntax 2908
Abbreviation 2908
Options 2908
Arguments 2908
Getting the system rights field for a role 2909
Return Value 2910
Examples 2910
get_role_rs_commands 2910
Zone Type 2910
Syntax 2910
Abbreviation 2910
Options 2911
Arguments 2911
Return Value 2911
Examples 2911
get_role_rs_env 2911
Zone Type 2911
Syntax 2911
Abbreviation 2911
Options 2911
Arguments 2911
Return Value 2911
Examples 2912
get_roles 2912
Zone Type 2912
Syntax 2912
Abbreviation 2912
Options 2912
Arguments 2912
Return Value 2912
Examples 2912
get_rs_commands 2913
Zone Type 2913
Syntax 2913
Abbreviation 2913
Options 2913
Arguments 2913
Return Value 2913
Examples 2913
get_rs_envs 2914
Zone Type 2914
Syntax 2914
Abbreviation 2914
Options 2914
Arguments 2914
Return Value 2914
Examples 2914
get_rsc_field 2915
Zone Type 2915
Syntax 2915
Abbreviation 2915
Options 2915
Arguments 2915
Return Value 2915
Examples 2915
get_rse_cmds 2916
Zone Type 2916
Syntax 2916
Abbreviation 2916
Options 2916
Arguments 2916
Return Value 2916
Examples 2916
get_rse_field 2917
Zone Type 2917
Syntax 2917
Abbreviation 2917
Options 2917
Arguments 2917
Return Value 2917
Examples 2917
get_schema_guid 2918
Zone Type 2918
Syntax 2918
Abbreviation 2918
Options 2918
Arguments 2918
Return Value 2918
Examples 2918
get_zone_computer_field 2918
Zone Type 2919
Syntax 2919
Abbreviation 2919
Options 2919
Arguments 2919
Return Value 2919
Examples 2919
get_zone_computers 2920
Zone Type 2920
Syntax 2920
Abbreviation 2920
Options 2920
Arguments 2920
Return Value 2920
Examples 2920
get_zone_field 2920
Zone Type 2921
Syntax 2921
Abbreviation 2921
Options 2921
Arguments 2921
Return Value 2921
Examples 2923
get_zone_group_field 2923
Zone Type 2923
Syntax 2923
Abbreviation 2923
Options 2923
Arguments 2923
Return Value 2924
Examples 2924
get_zone_groups 2924
Zone Type 2924
Syntax 2924
Abbreviation 2925
Options 2925
Arguments 2925
Return Value 2925
Examples 2925
get_zone_nss_vars 2925
Zone Type 2925
Syntax 2925
Abbreviation 2925
Options 2925
Arguments 2926
Return Value 2926
Examples 2926
get_zone_user_field 2926
Zone Type 2926
Syntax 2926
Abbreviation 2926
Options 2926
Arguments 2926
Argument values 2926
Return Value 2927
Examples 2927
get_zone_users 2927
Zone Type 2927
Syntax 2927
Abbreviation 2928
Options 2928
Arguments 2928
Return Value 2928
Examples 2928
get_zones 2928
Zone Type 2928
Syntax 2928
Abbreviation 2928
Options 2929
Arguments 2929
Return Value 2929
Examples 2929
getent_passwd 2929
Zone Type 2929
Syntax 2929
Abbreviation 2929
Options 2929
Arguments 2930
Return Value 2930
Examples 2930
guid_to_id 2930
Zone Type 2930
Syntax 2930
Abbreviation 2930
Options 2930
Arguments 2930
Return Value 2930
Examples 2930
help 2931
Zone Type 2931
Syntax 2931
Abbreviation 2931
Options 2931
Arguments 2931
Return Value 2931
Examples 2931
is_dz_enabled 2932
Zone Type 2932
Syntax 2932
Abbreviation 2932
Options 2932
Arguments 2932
Return Value 2932
Examples 2932
joined_get_user_membership 2932
Zone Type 2933
Syntax 2933
Abbreviation 2933
Options 2933
Arguments 2933
Return Value 2933
Examples 2933
joined_name_to_principal 2933
Zone Type 2933
Syntax 2933
Abbreviation 2933
Options 2934
Arguments 2934
Return Value 2934
Examples 2934
joined_user_in_group 2934
Zone Type 2934
Syntax 2934
Abbreviation 2934
Options 2934
Arguments 2935
Return Value 2935
Examples 2935
list_dz_commands 2935
Zone Type 2935
Syntax 2935
Abbreviation 2935
Options 2935
Arguments 2935
Return Value 2935
Examples 2936
list_local_groups_profile 2936
Zone Type 2936
Syntax 2936
Abbreviation 2936
Options 2936
Arguments 2936
Return Value 2936
Examples 2936
list_local_users_profile 2937
Zone Type 2937
Syntax 2937
Abbreviation 2937
Options 2937
Arguments 2937
Return Value 2937
Examples 2937
list_nis_map 2938
Zone Type 2938
Syntax 2938
Abbreviation 2938
Options 2938
Arguments 2938
Return Value 2938
Examples 2939
list_nis_map_with_comment 2939
Zone Type 2939
Syntax 2939
Abbreviation 2939
Options 2939
Arguments 2939
Return Value 2939
Examples 2940
list_nis_maps 2940
Zone Type 2940
Syntax 2940
Abbreviation 2940
Options 2940
Arguments 2940
Return Value 2940
Examples 2941
list_pam_apps 2941
Zone Type 2941
Syntax 2941
Abbreviation 2941
Options 2941
Arguments 2941
Return Value 2941
Examples 2942
list_pending_zone_groups 2942
Zone Type 2942
Syntax 2942
Abbreviation 2942
Options 2942
Arguments 2942
Return Value 2943
Examples 2943
list_pending_zone_users 2943
Zone Type 2943
Syntax 2943
Abbreviation 2943
Options 2943
Arguments 2943
Return Value 2943
Examples 2944
list_role_assignments 2944
Zone Type 2944
Syntax 2944
Abbreviation 2944
Options 2944
Arguments 2945
Return Value 2945
Examples 2945
list_role_rights 2945
Zone Type 2945
Syntax 2945
Abbreviation 2945
Options 2945
Arguments 2946
Return Value 2946
Examples 2946
list_roles 2946
Zone Type 2946
Syntax 2946
Abbreviation 2946
Options 2947
Arguments 2947
Return Value 2947
Examples 2947
list_rs_commands 2947
Zone Type 2947
Syntax 2947
Abbreviation 2947
Options 2948
Arguments 2948
Return Value 2948
Examples 2948
list_rs_envs 2948
Zone Type 2948
Syntax 2948
Abbreviation 2949
Options 2949
Arguments 2949
Return Value 2949
Examples 2949
list_zone_computers 2949
Zone Type 2949
Syntax 2949
Abbreviation 2949
Options 2949
Arguments 2950
Return Value 2950
Examples 2950
list_zone_groups 2950
Zone Type 2950
Syntax 2950
Abbreviation 2950
Options 2950
Arguments 2950
Return Value 2951
Examples 2951
list_zone_users 2951
Zone Type 2951
Syntax 2951
Abbreviation 2951
Options 2951
Arguments 2952
Return Value 2952
Examples 2952
manage_dz 2952
Zone Type 2953
Syntax 2953
Abbreviation 2953
Options 2953
Arguments 2953
Return Value 2953
Examples 2953
move_object 2953
Zone Type 2953
Syntax 2953
Abbreviation 2954
Options 2954
Arguments 2954
Return Value 2954
Example 2954
new_dz_command 2954
Zone Type 2954
Syntax 2954
Abbreviation 2954
Options 2954
Arguments 2954
Return Value 2955
Examples 2955
new_local_group_profile 2955
Zone Type 2955
Syntax 2955
Abbreviation 2955
Options 2955
Arguments 2956
Return Value 2956
Examples 2956
new_local_user_profile 2956
Zone Type 2957
Syntax 2957
Abbreviation 2957
Options 2957
Arguments 2957
Return Value 2957
Examples 2957
new_nis_map 2958
Zone Type 2958
Syntax 2958
Abbreviation 2958
Options 2958
Arguments 2958
Return Value 2958
Examples 2959
new_object 2959
Zone Type 2959
Syntax 2959
Abbreviation 2959
Options 2959
Arguments 2959
Return Value 2959
Examples 2960
new_pam_app 2960
Zone Type 2960
Syntax 2960
Abbreviation 2960
Options 2960
Arguments 2960
Return Value 2961
Examples 2961
new_role 2961
Zone Type 2961
Syntax 2961
Abbreviation 2961
Options 2961
Arguments 2961
Return Value 2962
Examples 2962
new_role_assignment 2962
Zone Type 2962
Syntax 2962
Abbreviation 2962
Options 2962
Arguments 2962
Return Value 2963
Examples 2963
new_rs_command 2963
Zone Type 2963
Syntax 2964
Abbreviation 2964
Options 2964
Arguments 2964
Return Value 2964
Examples 2964
new_rs_env 2964
Zone Type 2964
Syntax 2965
Abbreviation 2965
Options 2965
Arguments 2965
Return Value 2965
Examples 2965
new_zone_computer 2965
Zone Type 2965
Syntax 2965
Abbreviation 2966
Options 2966
Arguments 2966
Return Value 2966
Examples 2966
new_zone_group 2966
Zone Type 2967
Syntax 2967
Abbreviation 2967
Options 2967
Arguments 2967
Return Value 2967
Examples 2967
new_zone_user 2967
Zone Type 2968
Syntax 2968
Abbreviation 2968
Options 2968
Arguments 2968
Return Value 2968
Examples 2968
pop 2969
Zone Type 2969
Syntax 2969
Abbreviation 2969
Options 2969
Arguments 2969
Return Value 2969
Examples 2969
principal_from_sid 2969
Zone Type 2969
Syntax 2969
Abbreviation 2970
Options 2970
Arguments 2970
Return Value 2970
Examples 2970
principal_to_dn 2970
Zone Type 2970
Syntax 2970
Abbreviation 2970
Options 2970
Arguments 2970
Return Value 2971
Examples 2971
principal_to_id 2971
Zone Type 2971
Syntax 2971
Abbreviation 2971
Options 2971
Arguments 2971
Return Value 2972
Examples 2972
push 2972
Zone Type 2972
Syntax 2972
Abbreviation 2972
Options 2972
Arguments 2972
Return Value 2972
Examples 2972
quit 2973
Zone Type 2973
Syntax 2973
Abbreviation 2973
Options 2973
Arguments 2973
Return Value 2973
Examples 2973
remove_command_from_role 2973
Zone Type 2973
Syntax 2973
Abbreviation 2974
Options 2974
Arguments 2974
Return Value 2974
Examples 2974
remove_object_value 2974
Zone Type 2975
Syntax 2975
Abbreviation 2975
Options 2975
Arguments 2975
Return Value 2975
Examples 2975
remove_pamapp_from_role 2975
Zone Type 2976
Syntax 2976
Abbreviation 2976
Options 2976
Arguments 2976
Return Value 2976
Examples 2976
remove_sd_ace 2977
Zone Type 2977
Syntax 2977
Abbreviation 2977
Options 2977
Arguments 2977
Return Value 2977
Examples 2977
rename_object 2978
Zone Type 2978
Syntax 2978
Abbreviation 2978
Options 2978
Arguments 2978
Return Value 2978
Examples 2978
save_dz_command 2979
Zone Type 2979
Syntax 2979
Abbreviation 2979
Options 2979
Arguments 2979
Return Value 2979
Examples 2979
save_local_group_profile 2980
Zone Type 2980
Syntax 2980
Abbreviation 2980
Options 2980
Arguments 2980
Return Value 2980
Examples 2980
save_local_user_profile 2981
Zone Type 2981
Syntax 2981
Abbreviation 2981
Options 2981
Arguments 2981
Return Value 2981
Examples 2981
save_nis_map 2982
Zone Type 2982
Syntax 2982
Abbreviation 2982
Options 2982
Arguments 2982
Return Value 2982
Examples 2982
save_object 2983
Zone Type 2983
Syntax 2983
Abbreviation 2983
Options 2983
Arguments 2983
Return Value 2983
Examples 2983
save_pam_app 2984
Zone Type 2984
Syntax 2984
Abbreviation 2984
Options 2984
Arguments 2984
Return Value 2984
Examples 2984
save_role 2984
Zone Type 2985
Syntax 2985
Abbreviation 2985
Options 2985
Arguments 2985
Return Value 2985
Examples 2985
save_role_assignment 2985
Zone Type 2986
Syntax 2986
Abbreviation 2986
Options 2986
Arguments 2986
Return Value 2986
Examples 2986
save_rs_command 2986
Zone Type 2986
Syntax 2986
Abbreviation 2987
Options 2987
Arguments 2987
Return Value 2987
Examples 2987
save_rs_env 2987
Zone Type 2987
Syntax 2987
Abbreviation 2987
Options 2987
Arguments 2987
Return Value 2988
Examples 2988
save_zone 2988
Zone Type 2988
Syntax 2988
Abbreviation 2988
Options 2988
Arguments 2988
Return Value 2988
Examples 2988
save_zone_computer 2989
Zone Type 2989
Syntax 2989
Abbreviation 2989
Options 2989
Arguments 2989
Return Value 2989
Examples 2989
save_zone_group 2990
Zone Type 2990
Syntax 2990
Abbreviation 2990
Options 2990
Arguments 2990
Return Value 2990
Examples 2990
save_zone_user 2991
Zone Type 2991
Syntax 2991
Abbreviation 2991
Options 2991
Arguments 2991
Return Value 2991
Examples 2991
select_dz_command 2992
Zone Type 2992
Syntax 2992
Abbreviation 2992
Options 2992
Arguments 2992
Return Value 2992
Examples 2992
select_local_group_profile 2993
Zone Type 2993
Syntax 2993
Abbreviation 2993
Options 2993
Arguments 2993
Return Value 2993
Examples 2993
select_local_user_profile 2994
Zone Type 2994
Syntax 2994
Abbreviation 2994
Options 2994
Arguments 2994
Return Value 2994
Examples 2994
select_nis_map 2995
Zone Type 2995
Syntax 2995
Abbreviation 2995
Options 2995
Arguments 2995
Return Value 2995
Examples 2995
select_object 2996
Zone Type 2996
Syntax 2996
Abbreviation 2996
Options 2996
Arguments 2996
Return Value 2996
Examples 2996
select_pam_app 2997
Zone Type 2997
Syntax 2997
Abbreviation 2997
Options 2997
Arguments 2997
Return Value 2997
Examples 2998
select_role 2998
Zone Type 2998
Syntax 2998
Abbreviation 2998
Options 2998
Arguments 2998
Return Value 2999
Examples 2999
select_role_assignment 2999
Zone Type 2999
Syntax 2999
Abbreviation 2999
Options 3000
Arguments 3000
Return Value 3000
Examples 3000
select_rs_command 3000
Zone Type 3000
Syntax 3001
Abbreviation 3001
Options 3001
Arguments 3001
Return Value 3001
Examples 3001
select_rs_env 3001
Zone Type 3001
Syntax 3002
Abbreviation 3002
Options 3002
Arguments 3002
Return Value 3002
Examples 3002
select_zone 3002
Zone Type 3003
Syntax 3003
Abbreviation 3003
Options 3003
Arguments 3003
Return Value 3003
Examples 3003
select_zone_computer 3004
Zone Type 3004
Syntax 3004
Abbreviation 3004
Options 3004
Arguments 3004
Return Value 3004
Examples 3004
select_zone_group 3005
Zone Type 3005
Syntax 3005
Abbreviation 3005
Options 3005
Arguments 3005
Return Value 3005
Examples 3005
select_zone_user 3006
Zone Type 3006
Syntax 3006
Abbreviation 3006
Options 3006
Arguments 3006
Return Value 3006
Examples 3006
set_dzc_field 3007
Zone Type 3007
Syntax 3007
Abbreviation 3007
Options 3007
Arguments 3007
Setting the cmd and path field values 3008
Specifying the environment variables to use 3008
Specifying the command priority 3008
Specifying the umask value 3008
Specifying command properties using the flags field 3008
Return Value 3009
Examples 3009
set_ldap_timeout 3009
Zone Type 3009
Syntax 3009
Abbreviation 3010
Options 3010
Arguments 3010
Return Value 3010
Examples 3010
set_local_group_profile_field 3010
Zone Type 3010
Syntax 3010
Abbreviation 3010
Options 3010
Arguments 3010
Return Value 3011
Examples 3011
set_local_user_profile_field 3011
Zone Type 3012
Syntax 3012
Abbreviation 3012
Options 3012
Arguments 3012
Return Value 3012
Examples 3012
set_object_field 3013
Zone Type 3013
Syntax 3013
Abbreviation 3013
Options 3013
Arguments 3013
Return Value 3014
Examples 3014
set_pam_field 3014
Zone Type 3014
Syntax 3014
Abbreviation 3014
Options 3014
Arguments 3015
Return Value 3015
Examples 3015
set_role_assignment_field 3015
Zone Type 3015
Syntax 3016
Abbreviation 3016
Options 3016
Arguments 3016
Return Value 3016
Examples 3016
set_role_field 3016
Zone Type 3017
Syntax 3017
Abbreviation 3017
Options 3017
Arguments 3017
Setting the system rights field value for a role 3018
Return Value 3018
Examples 3018
set_rs_env_for_role 3019
Zone Type 3019
Syntax 3019
Abbreviation 3019
Options 3019
Arguments 3019
Return Value 3019
Examples 3019
set_rsc_field 3020
Zone Type 3020
Syntax 3020
Abbreviation 3020
Options 3020
Arguments 3020
Setting the cmd and path field values for a restricted command 3021
Specifying the environment variables for a restricted command 3021
Specifying the restricted command priority 3021
Specifying the umask value for restricted commands 3021
Specifying restricted command properties using the flags field 3021
Return Value 3022
Examples 3022
set_rse_field 3022
Zone Type 3022
Syntax 3022
Abbreviation 3022
Options 3022
Arguments 3022
Return Value 3023
Examples 3023
set_sd_owner 3023
Zone Type 3023
Syntax 3023
Abbreviation 3023
Options 3023
Arguments 3023
Return Value 3024
Examples 3024
set_user_password 3024
Zone Type 3024
Syntax 3024
Abbreviation 3024
Options 3025
Arguments 3025
Return Value 3025
Examples 3025
set_zone_computer_field 3025
Zone Type 3025
Syntax 3025
Abbreviation 3025
Options 3025
Arguments 3025
Return Value 3026
Examples 3026
set_zone_field 3026
Zone Type 3026
Syntax 3026
Abbreviation 3026
Options 3026
Arguments 3027
Return Value 3027
Examples 3027
set_zone_group_field 3028
Zone Type 3028
Syntax 3028
Abbreviation 3028
Options 3028
Arguments 3028
Return Value 3028
Examples 3028
set_zone_user_field 3029
Zone Type 3029
Syntax 3029
Abbreviation 3029
Options 3029
Arguments 3029
Return Value 3030
Examples 3030
show 3030
Zone Type 3030
Syntax 3030
Abbreviation 3030
Options 3030
Arguments 3031
Return Value 3031
Examples 3031
sid_to_escaped_string 3031
Zone Type 3031
Syntax 3031
Abbreviation 3031
Options 3031
Arguments 3032
Return Value 3032
Examples 3032
sid_to_uid 3032
Zone Type 3032
Syntax 3032
Abbreviation 3032
Options 3032
Arguments 3033
Return Value 3033
Examples 3033
validate_license 3033
Zone Type 3033
Syntax 3033
Abbreviation 3033
Options 3033
Arguments 3033
Return Value 3034
Examples 3034
write_role_assignment 3034
Zone Type 3034
Syntax 3034
Abbreviation 3034
Options 3034
Arguments 3034
Return Value 3034
Examples 3034
ADEdit Tcl Procedure Library Reference 3036
add_user_to_group 3036
Syntax 3036
Options 3036
Arguments 3036
Return value 3036
Examples 3036
Related Tcl library commands 3036
convert_msdate 3036
Syntax 3036
Options 3036
Arguments 3037
Return value 3037
Examples 3037
create_adgroup 3037
Syntax 3037
Options 3037
Arguments 3037
Return value 3037
Examples 3037
create_aduser 3038
Syntax 3038
Options 3038
Arguments 3038
Return value 3038
Examples 3038
create_assignment 3039
Syntax 3039
Options 3039
Arguments 3039
Return value 3039
Examples 3039
create_dz_command 3040
Syntax 3040
Options 3040
Arguments 3040
Return value 3040
Examples 3041
create_group 3041
Syntax 3041
Options 3041
Arguments 3041
Return value 3041
Examples 3041
create_nismap 3041
Syntax 3042
Options 3042
Arguments 3042
Return value 3042
Examples 3042
create_pam_app 3042
Syntax 3042
Options 3042
Arguments 3042
Return value 3043
Examples 3043
create_role 3043
Syntax 3043
Options 3043
Arguments 3043
Return value 3044
Examples 3044
create_rs_command 3044
Syntax 3044
Options 3044
Arguments 3044
Return value 3045
Examples 3045
create_rs_env 3045
Syntax 3045
Options 3045
Arguments 3045
Return value 3045
Examples 3045
create_user 3045
Syntax 3046
Options 3046
Arguments 3046
Return value 3046
Examples 3046
decode_timebox 3047
Syntax 3047
Options 3047
Arguments 3047
Return value 3047
Examples 3047
encode_timebox 3047
Syntax 3048
Options 3048
Arguments 3048
Return value 3048
Examples 3048
Related ade_lib Tcl library commands 3048
explain_groupType 3048
Syntax 3048
Options 3048
Arguments 3048
Return value 3049
Examples 3049
explain_ptype 3049
Syntax 3049
Options 3049
Arguments 3049
Return value 3049
Examples 3049
explain_trustAttributes 3050
Syntax 3050
Options 3050
Arguments 3050
Return value 3050
Examples 3050
explain_trustDirection 3051
Syntax 3051
Options 3051
Arguments 3051
Return value 3051
Examples 3051
explain_userAccountControl 3051
Syntax 3051
Options 3051
Arguments 3051
Return value 3052
Examples 3052
get_all_zone_users 3052
Syntax 3052
Abbreviation 3052
Options 3052
Arguments 3052
Return value 3052
Examples 3053
get_effective_groups 3053
Syntax 3053
Options 3053
Return value 3053
Example 3053
get_effective_users 3053
Syntax 3054
Options 3054
Return value 3054
Example 3054
get_user_groups 3054
Syntax 3054
Abbreviation 3054
Options 3054
Arguments 3054
Return value 3054
Examples 3055
get_user_role_assignments 3055
Syntax 3055
Abbreviation 3055
Options 3055
Arguments 3055
Return value 3056
Examples 3056
list_zones 3056
Syntax 3056
Options 3056
Arguments 3056
Return value 3056
Examples 3057
lmerge 3057
Syntax 3057
Options 3057
Arguments 3057
Return value 3057
Examples 3057
modify_timebox 3058
Syntax 3058
Options 3058
Arguments 3058
Return value 3058
Examples 3058
precreate_computer 3059
Syntax 3059
Options 3059
Arguments 3060
Return value 3060
Examples 3060
remove_user_from_group 3061
Syntax 3061
Options 3061
Arguments 3061
Return value 3061
Examples 3061
set_change_pwd_allowed 3061
Syntax 3061
Options 3061
Arguments 3062
Return value 3062
Examples 3062
set_change_pwd_denied 3062
Syntax 3062
Options 3062
Arguments 3062
Return value 3062
Examples 3062
Timebox Value Format 3064

Hex string 3064
Hour mapping 3064
Byte 0 3064
Byte 1 3064
Byte 2 3065
Day mapping 3065
Using ADEdit with Classic Zones 3067
Enabling Authorization in Classic Zones 3067
Working with privileged Commands and PAM Applications 3067
Working with Restricted Shell Environments and Commands 3067
Setting up the restricted shell environment 3067
Using restricted commands 3068
Creating computer-level role assignments in classic zones 3068
Quick reference for commands and library procedures 3070
PowerShell Scripting 3078

Scripting Access Control and Privilege Management with PowerShell 3079
Introduction 3079
Overview 3079
Intended audience 3079
Subtopics 3079
Compatibility and Limitations 3079
Developing Scripts for Administrative Tasks 3079
Getting Started with cmdlets for PowerShell 3080
Managing UNIX information from a Windows Computer 3080
Writing Programs in Other Languages 3080
Accessing information stored in Active Directory 3080
Installing the PowerShell Access Module 3081
Selecting and Downloading a Standalone Package 3081
Running the Setup program 3081
Importing cmdlets into the Windows PowerShell Console 3082
Managing Delinea Objects Using Windows PowerShell Scripts 3082
Using cmdlets to Manage Access 3083
Creating and Using a Connection 3083
Managing Connections 3084
Specifying Credentials 3084
Organizing cmdlet Operations in a Sequence 3084
Confirming Licenses 3084
Working with Sample Scripts 3084
Introduction 3084
Running a Sample Script 3085
Modifying the Backup and Restore Scripts for Your Needs 3085
Using the Default Windows PowerShell Console 3085
Creating New Zones with the Sample CreateZoneAndDelegate Script 3086
Generating Reports from Predefined Scripts 3086
Writing Custom Scripts 3086
Enabling Logging for cmdlets 3087
Viewing a Summary of cmdlet Commands 3087
Objects and Properties 3090
CdmAdObject Object 3090
CdmAdPrincipal Object 3091
CdmApplicationRight Object 3091
CdmCommandRight Object 3091
CdmComputer Object 3092
CdmComputerRole Object 3093
CdmDesktopRight Object 3093
CdmEffectiveUnixRights Object 3094
CdmEffectiveWindowsRights Object 3094
CdmGroup Object 3095
CdmGroupProfile Object 3095
CdmLocalGroupProfile Object 3096
CdmLocalUserProfile Object 3096
CdmLocalWindowsGroup Object 3097
CdmLocalWindowsUser Object 3097
CdmManagedComputer Object 3098
CdmMatchCriteria Object 3098
CdmNetworkRight Object 3100
CdmPamRight Object 3100
CdmRole Object 3100
CdmRoleAssignment Object 3101
CdmSshRight Object 3102
CdmUser Object 3102
CdmUserProfile Object 3103
CdmZone Object 3103
Adding Users in a One-Way Trust Environment 3105
Using One Account Credential 3105
Using Two Account Credentials 3105
Using Predefined Scripts to Generate Reports 3105
Provided Report Scripts 3105
Running Report Scripts 3107
Formatting Reports 3108
Export-Csv cmdlet 3108
Out-GridView cmdlet 3108
Format-Table cmdlet 3108
ConvertTo-Html cmdlet 3109
Generating a PDF report 3109
Overview 3109
Procedure Details 3109
Auditing and Analysis Scripting Guide 3112

Compatibility and Limitations of This Guide 3112
Developing Scripts for Administrative Tasks 3113
Getting Started with cmdlets For Powershell 3113
Managing Unix Information from a Windows Computer 3113
Writing Programs in Other Languages 3113
Accessing Audit Information Using Native Interfaces 3113
Installing the Audit Module for PowerShell 3115
About the Standalone Package 3115
Running the Setup Program 3115
Importing the cmdlets into the Windows PowerShell Console 3115
Managing Audit-Related Objects with Windows PowerShell Scripts 3117
Using cmdlets to Manage Auditing 3117
Preparing the Environment to Run cmdlets 3117
Setting the Preferred Domain Controller 3117
Setting the Logging Level 3117
Running cmdlets under Another Account 3118
Organizing cmdlet Operations in a Sequence 3118
Checking for Valid Licenses 3118
Specifying Parameters using Different Formats 3118
Working with Sample Scripts 3119
Writing Your Own Scripts 3120
Exporting Specific Session Fields For A Report 3120
Checking the status of agents and collectors 3120
Recommendations for Writing Custom Scripts 3121
Executing Custom Scripts 3121
Getting Information about the cmdlet Available 3122
AuditIng-Related Objects and Properties 3123
CdaAccessAccount 3123
CdaAdPrincipal 3123
CdaAgent 3123
CdaAuditEvent 3124
CdaAuditRole 3124
CdaAuditRoleAssignment 3125
CdaAuditRoleRight 3125
CdaAuditScope 3125
CdaAuditSession 3125
CdaAuditSessionTag 3126
CdaAuditSessionDataIntegrityStatus 3127
CdaAuditStore 3127
CdaAuditStoreRight 3127
CdaCollector 3128
CdaDatabase 3128
CdaDetailedExecution 3129
CdaInstallation 3129
CdaInstallationRight 3130
CdaManagementDatabase 3130
CdaManagementDatabaseRight 3131
CdaMonitoredExecution 3131
CdaMonitoredFile 3131
CdaQuery 3132
CdaQueryRight 3132
CdaSearchCriteria 3132
CdaUnixCommand 3133
CdaUnixCommandTranscript 3134
CdaUserEvent 3134
CdaWindowsEvent 3134
Windows API Reference 3136
Adding Users in a One-Way Trust Environment 3138
Data Storage for Delinea Zones 3139

Classic RFC 2307 Zones (3.x, 4.x) 3140
Zone Attributes in Classic RFC 2307 Zones 3141
User Attributes in Classic RFC 2307 Zones 3142
Group Attributes in Classic RFC 2307 Zones 3143
Computer Attributes in Classic RFC 2307 Zones 3144
Classic Delinea Zones (2.x, 3.x, 4.x) 3145
Parent link Attributes 3147
Zone Attributes in Classic Delinea Zones 3148
User Attributes in Classic Delinea Zones 3149
Group Attributes in Classic Delinea Zones 3150
Computer Attributes in Classic Delinea Zones 3151
Hierarchical Delinea Zones (5.x) 3152
Zone Attributes in Standard Hierarchical Zones 3153
User Attributes in Hierarchical Zones 3155
Group Attributes in Hierarchical Zones 3157
Computer Attributes in Hierarchical Zones 3158
Computer-Specific Zone Attributes in Standard Hierarchical Zones 3159
User Attributes in RFC 2307-Compliant Zones 3160
Group Attributes in RFC 2307-Compliant Zones 3161
User Attributes in Hierarchical SFU Zones 3162
Group Attributes in Hierarchical SFU Zones 3163
The Logical Data Model for Objects 3164
Use of Existing Attributes 3165
Logical Data Attributes for Zones 3166
Logical Data Attributes for Users 3167
Logical Data Attributes for Groups 3168
Logical Data Attributes for Computers 3169
Logical Data Attributes for NIS Maps 3170
Classic SFU-Compliant Zones (version 3.5) 3171
Zone Attributes in Classic SFU-Compliant Zones 3172
User Attributes in Classic SFU-Compliant Zones 3173
Group Attributes in Classic SFU-Compliant Zones 3174
Classic SFU-Compliant Zones (version 4.0) 3175
Zone Attributes in Classic SFU 4.0 Zones 3176
User Attributes in Classic SFU 4.0 Zones 3177
Group Attributes in Classic SFU 4.0 Zones 3178
Using Commands and Scripts to Perform Tasks 3179
Getting Started 3180
Creating a Classic Zone 3181
Add a User to a Classic Zone 3182
Basic requirements 3183

Differences between Types of Zones 3184
Delinea SDK 3188
Development Platform 3189
Windows SDK 3190
UNIX SDK 3191

Overview of the Delinea Windows API Object Model 3192
How the Delinea Windows API Relies on COM Interfaces 3193
Administrative Tasks You Can Perform 3194
Delinea-specific Objects Classes 3195
Creating Objects in the Proper Order 3197

Getting and setting object properties 3198
Interface naming conventions 3198
Creating the Top-level Cims Object 3200
Working With NIS Maps 3201
Writing Scripts that Use Delinea Windows API Calls 3202
Delinea Object Reference 3206
AzRoleAssignment 3208
Syntax 3208
Methods 3208
Properties 3208
Discussion 3209
GetComputerRole 3210
Syntax 3210
Return value 3210
Discussion 3210
Exceptions 3210
Example 3210
Cims 3211
Syntax 3211
Discussion 3211
Methods 3211
Properties 3212
AddComputer 3213
Syntax 3213
Parameters 3213
Return value 3213
Exceptions 3213
AddComputerZone 3214
Syntax 3214
Parameters 3214
Return value 3214
Discussion 3214
Exceptions 3214
AddWindowsComputer 3215
Syntax 3215
Parameters 3215
Return value 3215
Exceptions 3215
ConfigureForest 3216
Syntax 3216
Parameters 3216
Discussion 3216
Exceptions 3216
Connect 3217
Syntax 3217
Parameters 3217
Discussion 3217
Example 3217
CreateZone 3218
Syntax 3218
Parameters 3218
Return value 3218
Discussion 3218
Exceptions 3218
Example 3218
CreateZoneWithSchema 3219
Syntax 3219
Parameters 3219
Return value 3219
Discussion 3219
Exceptions 3219
Example 3219
GetComputer 3220
Syntax 3220
Parameter 3220
Return value 3220
Discussion 3220
Exceptions 3220
Example 3220
GetComputerByComputerZone 3221
Syntax 3221
Parameter 3221
Return value 3221
Discussion 3221
Exceptions 3221
GetComputerByPath 3222
Syntax 3222
Parameter 3222
Return value 3222
Discussion 3222
Exceptions 3222
Example 3222
GetGroup 3223
Syntax 3223
Parameter 3223
Return value 3223
Discussion 3223
Exceptions 3223
Example 3223
GetGroupByPath 3224
Syntax 3224
Parameter 3224
Return value 3224
Discussion 3224
Exceptions 3224
Example 3224
GetUser 3225
Syntax 3225
Parameter 3225
Return value 3225
Discussion 3225
Exceptions 3225
Example 3225
GetUserByPath 3226
Syntax 3226
Parameter 3226
Return value 3226
Exceptions 3226
Discussion 3226
Example 3226
GetWindowsUser 3228
Syntax 3228
Parameter 3228
Return value 3228
Exceptions 3228
Discussion 3228
GetWindowsUserByPath 3229
Syntax 3229
Parameter 3229
Return value 3229
Exceptions 3229
Discussion 3229
GetZone 3230
Syntax 3230
Parameter 3230
Return value 3230
Discussion 3230
Exceptions 3230
Example 3230
GetZoneByPath 3231
Syntax 3231
Parameter 3231
Return value 3231
Discussion 3231
Exceptions 3231
Example 3231
IsForestConfigured 3233
Syntax 3233
Return value 3233
Exceptions 3233
Example 3233
LoadLicenses 3234
Syntax 3234
Return value 3234
Discussion 3234
Exceptions 3234
Example 3234
Password 3235
Syntax 3235
Property value 3235
Example 3235
Server 3236
Syntax 3236
Property value 3236
Example 3236
UserName 3237
Syntax 3237
Property value 3237
Example 3237
Command 3238
Syntax 3238
Methods 3238
Properties 3238
Discussion 3239
AllowNestedExecution 3240
Syntax 3240
Property value 3240
AuthenticationType 3241
Syntax 3241
Property value 3241
CommandPattern 3242
Syntax 3242
Property value 3242
Discussion 3242
Exceptions 3242
Example 3242
CommandPatternType 3243
Syntax 3243
Property value 3243
DzdoRunAsGroupList 3244
Syntax 3244
Property value 3244
DzdoRunAsUserList 3245
Syntax 3245
Property value 3245
Discussion 3245
DzshRunAsUser 3246
Syntax 3246
Property value 3246
Guid 3247
Syntax 3247
Property value 3247
IsResetVariables 3248
Syntax 3248
Property value 3248
Discussion 3248
MatchPath 3249
Syntax 3249
Property value 3249
PreserveGroupMembership 3250
Syntax 3250
Property value 3250
UMask 3251
Syntax 3251
Property value 3251
Exceptions 3251
VariablesToAdd 3252
Syntax 3252
Property value 3252
Exceptions 3252
VariablesToKeepOrDelete 3253
Syntax 3253
Property value 3253
Discussion 3253
Exceptions 3253
Weight 3254
Syntax 3254
Property value 3254
Discussion 3254
Commands 3255
Syntax 3255
Methods 3255
GetEnumerator 3256
Syntax 3256
Return value 3256
Computer 3257
Syntax 3257
Methods 3257
Properties 3257
Commit 3259
Syntax 3259
Discussion 3259
Exceptions 3259
Example 3259
Delete 3260
Syntax 3260
Discussion 3260
Exceptions 3260
Example 3260
GetDirectoryEntry 3261
Syntax 3261
Return value 3261
Discussion 3261
Example 3261
Refresh 3262
Syntax 3262
Discussion 3262
Exceptions 3262
Example 3262
AdsiInterface 3263
Syntax 3263
Property value 3263
Example 3263
ADsPath 3264
Syntax 3264
Property value 3264
Example 3264
AgentVersion 3265
Syntax 3265
Property value 3265
Example 3265
CanonicalName 3266
Syntax 3266
Property value 3266
Example 3266
IsOrphan 3267
Syntax 3267
Property value 3267
Discussion 3267
Example 3267
IsReadable 3268
Syntax 3268
Property value 3268
Discussion 3268
Example 3268
IsWritable 3269
Syntax 3269
Property value 3269
Discussion 3269
Example 3269
BossEnabled 3270
Syntax 3270
Property value 3270
Exceptions 3270
Example 3270
Name 3271
Syntax 3271
Property value 3271
Example 3271
ProfileADsPath 3272
Syntax 3272
Property value 3272
Example 3272
SchemaVersion 3273
Syntax 3273
Property value 3273
Discussion 3273
Example 3273
TomcatEnabled 3274
Syntax 3274
Property value 3274
Exceptions 3274
Example 3274
Version 3275
Syntax 3275
Property value 3275
Discussion 3275
Example 3275
WebLogicEnabled 3276
Syntax 3276
Property value 3276
Exceptions 3276
Example 3276
WebSphereEnabled 3277
Syntax 3277
Property value 3277
Exceptions 3277
Example 3277
Zone 3278
Syntax 3278
Property value 3278
Discussion 3278
Exceptions 3278
Example 3278
ZoneMode 3279
Syntax 3279
Property value 3279
Possible values: 3279
ComputerGroupUnixProfiles 3280
Syntax 3280
Methods 3280
Properties 3280
Find 3281
Syntax 3281
Parameter 3281
Return value 3281
ComputerRole 3282
Syntax 3282
Methods 3282
Properties 3282
Discussion 3283
AddAccessGroup 3284
Syntax 3284
Parameters 3284
Discussion 3284
Return value 3284
Exceptions 3284
AddRoleAssignment 3285
Syntax 3285
Return value 3285
Discussion 3285
AddUser 3286
Syntax 3286
Parameters 3286
Return value 3286
Discussion 3286
Exceptions 3286
ClearCustomAttributes 3287
Syntax 3287
Commit 3288
Syntax 3288
Discussion 3288
Exceptions 3288
Delete 3289
Syntax 3289
Exceptions 3289
GetAccessGroup 3290
Syntax 3290
Parameters 3290
Return value 3290
Discussion 3290
Exceptions 3290
GetAccessGroups 3291
Syntax 3291
Return value 3291
GetCustomAttributeContainer 3292
Syntax 3292
Return value 3292
Discussion 3292
GetGroup 3293
Syntax 3293
Return value 3293
Discussion 3293
GetRoleAssignment 3294
Syntax 3294
Parameters 3294
Return value 3294
Discussion 3294
Exceptions 3294
GetRoleAssignmentById 3295
Syntax 3295
Parameter 3295
Return value 3295
Discussion 3295
Exceptions 3295
GetRoleAssignments 3296
Syntax 3296
Return value 3296
GetRoleAssignmentToAllADUsers 3297
Syntax 3297
Parameter 3297
Return value 3297
Exceptions 3297
GetRoleAssignmentToEveryone 3298
Syntax 3298
Parameter 3298
Return value 3298
Discussion 3298
Exceptions 3298
GetUser 3299
Syntax 3299
Parameters 3299
Return value 3299
Discussion 3299
Exceptions 3299
GetUsers 3300
Syntax 3300
Return value 3300
SetCustomAttribute 3301
Syntax 3301
Parameters 3301
Return value 3301
Validate 3302
Syntax 3302
Exceptions 3302
CustomAttributes 3303
Syntax 3303
Property value 3303
Description 3304
Syntax 3304
Property value 3304
Group 3305
Syntax 3305
Property value 3305
IsOrphan 3306
Syntax 3306
Property value 3306
Name 3307
Syntax 3307
Property value 3307
Zone 3308
Syntax 3308
Property value 3308
ComputerRoles 3309
Syntax 3309
Methods 3309
Properties 3309
GetEnumerator 3310
Syntax 3310
Return value 3310
IsEmpty 3311
Syntax 3311
Property value 3311
Computers 3312
Syntax 3312
Methods 3312
Properties 3312
GetEnumerator 3313
Syntax 3313
Return value 3313
IsEmpty 3314
Syntax 3314
Property value 3314
ComputerUserUnixProfiles 3315
Syntax 3315
Methods 3315
Properties 3315
Find 3316
Syntax 3316
Parameter 3316
Return value 3316
CustomAttribute 3317
Properties 3317
CustomAttributeContainer 3318
Methods 3318
GetCustomAttributes 3319
Syntax 3319
Parameter 3319
Return value 3319
ValidateCustomAttributes 3320
Syntax 3320
Parameter 3320
Return value 3320
CustomAttributes 3321
Methods 3321
GetEnumerator 3322
Syntax 3322
Return value 3322
Entry 3323
Syntax 3323
Discussion 3323
Methods 3323
Properties 3323
Commit 3324
Syntax 3324
Exceptions 3324
Example 3324
Syntax 3325
Return value 3325
Discussion 3325
Comment 3326
Syntax 3326
Property value 3326
Discussion 3326
Exceptions 3326
Example 3326
IsReadable 3327
Syntax 3327
Property value 3327
Discussion 3327
Example 3327
IsWritable 3328
Syntax 3328
Property value 3328
Discussion 3328
Example 3328
Key 3329
Syntax 3329
Property value 3329
Discussion 3329
Exceptions 3329
Example 3329
Map 3330
Syntax 3330
Property value 3330
Value 3331
Syntax 3331
Property value 3331
Discussion 3331
Exceptions 3331
Example 3331
Group 3332
Syntax 3332
Discussion 3332
Methods 3332
Properties 3332
AddUnixProfile 3333
Syntax 3333
Parameters 3333
Return value 3333
Discussion 3333
Exceptions 3333
Example 3333
Commit 3334
Syntax 3334
Discussion 3334
Exceptions 3334
Example 3334
CommitWithoutCheck 3335
Syntax 3335
Discussion 3335
Exceptions 3335
Example 3335
Syntax 3336
Return value 3336
Discussion 3336
Exceptions 3336
Example 3336
GetRoleAssignmentsFromDomain 3337
Syntax 3337
Parameters 3337
Return value 3337
Discussion 3337
Example 3337
GetRoleAssignmentsFromForest 3338
Syntax 3338
Parameters 3338
Return value 3338
Discussion 3338
Example 3338
Refresh 3339
Syntax 3339
Discussion 3339
Example 3339
AdsiInterface 3340
Syntax 3340
Property value 3340
Example 3340
ADsPath 3341
Syntax 3341
Property value 3341
Example 3341
ID 3342
Syntax 3342
Property value 3342
Example 3342
UnixProfiles 3343
Syntax 3343
Property value 3343
Discussion 3343
Example 3343
GroupInfo 3344
Syntax 3344
Methods 3344
Properties 3344
Commit 3346
Syntax 3346
Delete 3347
Syntax 3347
Discussion 3347
Exceptions 3347
GetMembers 3348
Syntax 3348
Return value 3348
Discussion 3348
Import 3349
Syntax 3349
Parameter 3349
Discussion 3349
UpdateStatus 3350
Syntax 3350
Discussion 3350
CandidateDN 3351
Syntax 3351
Property value 3351
Discussion 3351
GID 3352
Syntax 3352
Property value 3352
Discussion 3352
ID 3353
Syntax 3353
Property value 3353
IsImported 3354
Syntax 3354
Property value 3354
Discussion 3354
Members 3355
Syntax 3355
Property value 3355
Name 3356
Syntax 3356
Property value 3356
Source 3357
Syntax 3357
Property value 3357
Discussion 3357
Status 3358
Syntax 3358
Property value 3358
Discussion 3358
StatusDescription 3359
Syntax 3359
Property value 3359
Discussion 3359
TimeStamp 3360
Syntax 3360
Property value 3360
Example 3360
GroupInfos 3361
Syntax 3361
Methods 3361
Properties 3361
Find 3362
Syntax 3362
Parameter 3362
Return value 3362
GetEnumerator 3363
Syntax 3363
Return value 3363
Count 3364
Syntax 3364
Property value 3364
Discussion 3364
IsEmpty 3365
Syntax 3365
Property value 3365
Discussion 3365
GroupMember 3366
Syntax 3366
Methods 3366
Properties 3366
CandidateDN 3367
Syntax 3367
Property value 3367
Discussion 3367
Name 3368
Syntax 3368
Property value 3368
GroupMembers 3369
Syntax 3369
Methods 3369
Properties 3369
Add 3370
Syntax 3370
Parameter 3370
Return value 3370
AddRange 3371
Syntax 3371
Parameter 3371
Clear 3372
Syntax 3372
Discussion 3372
Remove 3373
Syntax 3373
Parameter 3373
Count 3374
Syntax 3374
Property value 3374
Discussion 3374
GroupUnixProfile 3375
Syntax 3375
Discussion 3375
Methods 3375
Properties 3375
Commit 3377
Syntax 3377
Discussion 3377
Exceptions 3377
Example 3377
Delete 3378
Syntax 3378
Discussion 3378
Example 3378
Syntax 3379
Return value 3379
Discussion 3379
Example 3379
Refresh 3380
Syntax 3380
Discussion 3380
Example 3380
Validate 3381
Syntax 3381
Discussion 3381
Exceptions 3381
Example 3381
ADsPath 3382
Syntax 3382
Property value 3382
Example 3382
Cims 3383
Syntax 3383
Property value 3383
Discussion 3383
Example 3383
Group 3384
Syntax 3384
Property value 3384
Example 3384
GroupID 3385
Syntax 3385
Property value 3385
Discussion 3385
Exceptions 3385
ID 3386
Syntax 3386
Property value 3386
Example 3386
IsForeign 3387
Syntax 3387
Property value 3387
Discussion 3387
Example 3387
IsMembershipRequired 3388
Syntax 3388
Property value 3388
Discussion 3388
Exceptions 3388
Example 3388
IsOrphan 3389
Syntax 3389
Property value 3389
Discussion 3389
Exceptions 3389
Example 3389
IsReadable 3390
Syntax 3390
Property value 3390
Discussion 3390
Example 3390
IsSFU 3391
Syntax 3391
Property value 3391
Discussion 3391
IsWritable 3392
Syntax 3392
Property value 3392
Discussion 3392
Example 3392
Members 3393
Syntax 3393
Property value 3393
Exceptions 3393
ProfileState 3394
Syntax 3394
Property value 3394
Exceptions 3394
Name 3395
Syntax 3395
Property value 3395
Example 3395
Type 3396
Syntax 3396
Property value 3396
Discussion 3396
Example 3396
UnixEnabled 3397
Syntax 3397
Property value 3397
Example 3397
Zone 3398
Syntax 3398
Property value 3398
Discussion 3398
GroupUnixProfiles 3399
Syntax 3399
Discussion 3399
Methods 3399
Properties 3399
GetEnumerator 3400
Syntax 3400
Return value 3400
Refresh 3401
Syntax 3401
Discussion 3401
Count 3402
Syntax 3402
Property value 3402
Discussion 3402
Example 3402
IsEmpty 3403
Syntax 3403
Property value 3403
Discussion 3403
Example 3403
HierarchicalGroup 3404
Syntax 3404
Methods 3404
Properties 3404
GetComputer 3407
Syntax 3407
Return value 3407
InheritFromParent 3408
Syntax 3408
Discussion 3408
ResolveEffectiveProfile 3409
Syntax 3409
Discussion 3409
EffectiveGid 3410
Syntax 3410
Property value 3410
Exceptions 3410
EffectiveMembers 3411
Syntax 3411
Property value 3411
Exceptions 3411
EffectiveIsMembershipRequired 3412
Syntax 3412
Property value 3412
Discussion 3412
Exceptions 3412
EffectiveName 3413
Syntax 3413
Property value 3413
EffectiveProfileState 3414
Syntax 3414
Property value 3414
Exceptions 3414
IsEffectiveGidDefined 3415
Syntax 3415
Property value 3415
Discussion 3415
IsEffectiveIsMembershipRequiredDefined 3416
Syntax 3416
Property value 3416
Discussion 3416
IsEffectiveMembersDefined 3417
Syntax 3417
Property value 3417
Discussion 3417
Exceptions 3417
IsEffectiveNameDefined 3418
Syntax 3418
Property value 3418
Discussion 3418
IsEffectiveProfileStateDefined 3419
Syntax 3419
Property value 3419
Discussion 3419
Exceptions 3419
IsGidDefined 3420
Syntax 3420
Property value 3420
Exceptions 3420
IsMembersDefined 3421
Syntax 3421
Property value 3421
Exceptions 3421
IsMembershipRequiredDefined 3422
Syntax 3422
Property value 3422
Exceptions 3422
IsNameDefined 3423
Syntax 3423
Property value 3423
Exceptions 3423
IsProfileStateDefined 3424
Syntax 3424
Property value 3424
Discussion 3424
Exceptions 3424
Zone 3425
Syntax 3425
Property value 3425
HierarchicalUser 3426
Syntax 3426
Discussion 3426
Methods 3426
Properties 3427
AddUserRoleAssignment 3431
Syntax 3431
Return value 3431
Discussion 3431
Example 3431
GetComputer 3432
Syntax 3432
Return value 3432
GetEffectiveUserRoleAssignments 3433
Syntax 3433
Return value 3433
Discussion 3433
GetUserRoleAssignment 3434
Syntax 3434
Parameter 3434
Return value 3434
Exceptions 3434
Example 3434
GetUserRoleAssignments 3435
Syntax 3435
Return value 3435
Discussion 3435
InheritFromParent 3436
Syntax 3436
Discussion 3436
ResolveEffectiveProfile 3437
Syntax 3437
Discussion 3437
ResolveEffectiveRoles 3438
Syntax 3438
Parameters 3438
Discussion 3438
EffectiveGecos 3439
Syntax 3439
Property value 3439
Discussion 3439
EffectiveGecosZone 3440
Syntax 3440
Property value 3440
Discussion 3440
EffectiveHomeDirectory 3441
Syntax 3441
Property value 3441
Discussion 3441
EffectiveHomeDirectoryZone 3442
Syntax 3442
Property value 3442
Discussion 3442
EffectiveIsUseAutoPrivateGroup 3443
Syntax 3443
Property value 3443
Discussion 3443
EffectiveName 3444
Syntax 3444
Property value 3444
Discussion 3444
EffectiveNameZone 3445
Syntax 3445
Property value 3445
Discussion 3445
EffectivePrimaryGroup 3446
Syntax 3446
Property value 3446
Discussion 3446
EffectiveProfileState 3447
Syntax 3447
Property value 3447
Discussion 3447
Exceptions 3447
EffectiveProfileStateZone 3448
Syntax 3448
Property value 3448
Discussion 3448
Exceptions 3448
EffectivePrimaryGroupZone 3449
Syntax 3449
Property value 3449
Discussion 3449
EffectiveShell 3450
Syntax 3450
Property value 3450
Discussion 3450
EffectiveShellZone 3451
Syntax 3451
Property value 3451
Discussion 3451
EffectiveUid 3452
Syntax 3452
Property value 3452
Discussion 3452
EffectiveUidZone 3453
Syntax 3453
Property value 3453
Discussion 3453
Gecos 3454
Syntax 3454
Property value 3454
Discussion 3454
IsEffectiveGecosDefined 3455
Syntax 3455
Property value 3455
Discussion 3455
IsEffectiveHomeDirectoryDefined 3456
Syntax 3456
Property value 3456
Discussion 3456
IsEffectiveNameDefined 3457
Syntax 3457
Property value 3457
Discussion 3457
IsEffectivePrimaryGroupDefined 3458
Syntax 3458
Property value 3458
Discussion 3458
IsEffectiveProfileStateDefined 3459
Syntax 3459
Property value 3459
Exceptions 3459
IsEffectiveShellDefined 3460
Syntax 3460
Property value 3460
Discussion 3460
IsEffectiveUidDefined 3461
Syntax 3461
Property value 3461
Discussion 3461
IsEffectiveUseAutoPrivateGroupDefined 3462
Syntax 3462
Property value 3462
Discussion 3462
IsGecosDefined 3463
Syntax 3463
Property value 3463
Exceptions 3463
IsHomeDirectoryDefined 3464
Syntax 3464
Property value 3464
Exceptions 3464
IsNameDefined 3465
Syntax 3465
Property value 3465
Exceptions 3465
IsProfileStateDefined 3466
Syntax 3466
Property value 3466
Exceptions 3466
IsPrimaryGroupDefined 3467
Syntax 3467
Property value 3467
Discussion 3467
Exceptions 3467
IsSecondary 3468
Syntax 3468
Property value 3468
IsShellDefined 3469
Syntax 3469
Property value 3469
Exceptions 3469
IsUidDefined 3470
Syntax 3470
Property value 3470
Exceptions 3470
IsUseAutoPrivateGroup 3471
Syntax 3471
Property value 3471
Discussion 3471
IsUseAutoPrivateGroupDefined 3472
Syntax 3472
Property value 3472
Discussion 3472
Exceptions 3472
Zone 3473
Syntax 3473
Property value 3473
HierarchicalZone 3474
Syntax 3474
Discussion 3474
Methods 3474
Properties 3477
AddAccessGroup 3482
Syntax 3482
Parameters 3482
Return value 3482
Discussion 3482
Exceptions 3482
Example 3482
AddComputerRole 3484
Syntax 3484
Parameters 3484
Return value 3484
AddGroupPartialProfile 3485
Syntax 3485
Parameters 3485
Return value 3485
Discussion 3485
Exceptions 3485
Example 3485
Syntax 3487
Return value 3487
AddLocalGroupPartialProfile 3488
Syntax 3488
Parameters 3488
Return value 3488
Exceptions 3488
AddLocalUserPartialProfile 3489
Syntax 3489
Parameters 3489
Return value 3489
Exceptions 3489
AddUserPartialProfile 3490
Syntax 3490
Parameters 3490
Return value 3490
Discussion 3490
Exceptions 3490
Example 3490
CreateCommand 3492
Syntax 3492
Return value 3492
Discussion 3492
Example 3492
CreateNetworkAccess 3493
Syntax 3493
Return value 3493
Discussion 3493
Example 3493
CreatePamAccess 3494
Syntax 3494
Return value 3494
Discussion 3494
Example 3494
CreateRole 3495
Syntax 3495
Parameter 3495
Return value 3495
Discussion 3495
Example 3495
CreateSshRight 3496
Syntax 3496
Return value 3496
Discussion 3496
CreateWindowsApplication 3497
Syntax 3497
Return value 3497
Discussion 3497
Example 3497
CreateWindowsDesktop 3498
Syntax 3498
Return value 3498
Discussion 3498
Example 3498
GeneratePredefinedRights 3499
Syntax 3499
Discussion 3499
GeneratePredefinedRoles 3500
Syntax 3500
Discussion 3500
GetAccessGroup 3501
Syntax 3501
Parameters 3501
Return value 3501
Discussion 3501
Exceptions 3501
Example 3501
Syntax 3502
Return value 3502
GetChildZones 3503
Syntax 3503
Return value 3503
Exceptions 3503
GetCommand 3504
Syntax 3504
Parameter 3504
Return value 3504
Exceptions 3504
Example 3504
GetCommands 3505
Syntax 3505
Return value 3505
GetComputerRole 3506
Syntax 3506
Parameter 3506
Return value 3506
Exceptions 3506
Example 3506
GetComputerRoles 3507
Syntax 3507
Return value 3507
GetEffectiveCommands 3508
Syntax 3508
Return value 3508
Exceptions 3508
GetEffectiveNetworkAccesses 3509
Syntax 3509
Return value 3509
Exceptions 3509
GetEffectivePamAccesses 3510
Syntax 3510
Return value 3510
Exceptions 3510
GetEffectiveRoles 3511
Syntax 3511
Return value 3511
Exceptions 3511
GetEffectiveSshs 3512
Syntax 3512
Return value 3512
Exceptions 3512
GetEffectiveUserUnixProfiles 3513
Syntax 3513
Return value 3513
GetEffectiveWindowsApplications 3514
Syntax 3514
Return value 3514
Exceptions 3514
GetEffectiveWindowsDesktops 3515
Syntax 3515
Return value 3515
Exceptions 3515
GetEffectiveWindowsUsers 3516
Syntax 3516
Return value 3516
GetNetworkAccess 3517
Syntax 3517
Parameter 3517
Return value 3517
Exceptions 3517
Example 3517
GetNetworkAccesses 3518
Syntax 3518
Return value 3518
Discussion 3518
GetNSSVariable 3519
Syntax 3519
Parameter 3519
Return value 3519
GetNSSVariables 3520
Syntax 3520
Return value 3520
GetPamAccess 3521
Syntax 3521
Parameter 3521
Return value 3521
Exceptions 3521
Example 3521
GetPamAccesses 3522
Syntax 3522
Return value 3522
GetPrimaryUser 3523
Syntax 3523
Parameters 3523
Return value 3523
Discussion 3523
Exceptions 3523
GetRole 3524
Syntax 3524
Parameter 3524
Return value 3524
Exceptions 3524
Example 3524
Syntax 3525
Parameter 3525
Return value 3525
Exceptions 3525
Syntax 3526
Parameter 3526
Return value 3526
Exceptions 3526
GetRoleAssigments 3527
Syntax 3527
Return value 3527
Syntax 3528
Parameter 3528
Return value 3528
Exceptions 3528
GetRoleAssignmentToAllUnixUsers 3529
Syntax 3529
Parameter 3529
Return value 3529
Discussion 3529
Exceptions 3529
GetRoles 3530
Syntax 3530
Return value 3530
GetSecondaryUsers 3531
Syntax 3531
Parameters 3531
Return value 3531
Discussion 3531
Exceptions 3531
GetSshRight 3532
Syntax 3532
Parameter 3532
Return value 3532
Exceptions 3532
GetSshRights 3533
Syntax 3533
Return value 3533
GetSubTreeRoleAssignments 3534
Syntax 3534
Return value 3534
Exceptions 3534
GetUserProfiles 3535
Syntax 3535
Parameters 3535
Return value 3535
Exceptions 3535
Syntax 3536
Parameters 3536
Return value 3536
Exceptions 3536
GetWindowsApplication 3537
Syntax 3537
Parameter 3537
Return value 3537
Exceptions 3537
GetWindowsApplications 3538
Syntax 3538
Return value 3538
GetWindowsComputers 3539
Syntax 3539
Return value 3539
GetWindowsDesktop 3540
Syntax 3540
Parameter 3540
Return value 3540
Exceptions 3540
GetWindowsDesktops 3541
Syntax 3541
Return value 3541
PrecreateComputerZone 3542
Syntax 3542
Parameters 3542
Return value 3542
Discussion 3542
Exceptions 3542
SetNSSVariable 3543
Syntax 3543
Parameter 3543
GroupDefaultName 3544
Syntax 3544
Property value 3544
IsChild 3545
Syntax 3545
Property value 3545
Discussion 3545
IsGroupDefaultNameDefined 3546
Syntax 3546
Property value 3546
Exceptions 3546
IsNextGidDefined 3547
Syntax 3547
Property value 3547
Exceptions 3547
IsNextUidDefined 3548
Syntax 3548
Property value 3548
Exceptions 3548
IsUseAutoPrivateGroupDefined 3549
Syntax 3549
Property value 3549
Discussion 3549
Exceptions 3549
IsUserDefaultGecosDefined 3550
Syntax 3550
Property value 3550
Exceptions 3550
IsUserDefaultHomeDirectoryDefined 3551
Syntax 3551
Property value 3551
Exceptions 3551
IsUserDefaultNameDefined 3552
Syntax 3552
Property value 3552
Exceptions 3552
IsUserDefaultPrimaryGroupDefined 3553
Syntax 3553
Property value 3553
Exceptions 3553
IsUserDefaultRoleDefined 3554
Syntax 3554
Property value 3554
Exceptions 3554
IsUserDefaultShellDefined 3555
Syntax 3555
Property value 3555
Exceptions 3555
NssVariables 3556
Syntax 3556
Property value 3556
Discussion 3556
Example 3556
Parent 3557
Syntax 3557
Property value 3557
Discussion 3557
Exceptions 3557
Example 3557
UseAppleGid 3558
Syntax 3558
Property value 3558
UseAppleUid 3559
Syntax 3559
Property value 3559
UseAutoGid 3560
Syntax 3560
Property value 3560
UseAutoPrivateGroup 3561
Syntax 3561
Property value 3561
Discussion 3561
Exceptions 3561
UseAutoUid 3562
Syntax 3562
Property value 3562
UseNextGid 3563
Syntax 3563
Property value 3563
Discussion 3563
Example 3563
UseNextUid 3564
Syntax 3564
Property value 3564
Discussion 3564
Example 3564
UserDefaultGecos 3565
Syntax 3565
Property value 3565
Example 3565
UserDefaultGid 3566
Syntax 3566
Property value 3566
Discussion 3566
Exceptions 3566
UserDefaultName 3567
Syntax 3567
Property value 3567
UserDefaultPrimaryGroup 3568
Syntax 3568
Property value 3568
Discussion 3568
Exceptions 3568
UserDefaultRole 3569
Syntax 3569
Property value 3569
HzRoleAssignment 3570
Syntax 3570
Methods 3570
Properties 3570
Zone 3571
Syntax 3571
Property value 3571
InheritedRoleAsg 3572
Syntax 3572
Methods 3572
Properties 3572
GetTrustee 3573
Syntax 3573
Return value 3573
EndTime 3574
Syntax 3574
Property value 3574
IsRoleOrphaned 3575
Syntax 3575
Property value 3575
IsTrusteeOrphaned 3576
Syntax 3576
Property value 3576
Role 3577
Syntax 3577
Property value 3577
Source 3578
Syntax 3578
Property value 3578
StartTime 3579
Syntax 3579
Property value 3579
TrusteeDn 3580
Syntax 3580
Property value 3580
Key 3581
Syntax 3581
Discussion 3581
Properties 3581
Count 3582
Syntax 3582
Property value 3582
Discussion 3582
Example 3582
ExpiryDate 3583
Syntax 3583
Property value 3583
Discussion 3583
Example 3583
IsEval 3584
Syntax 3584
Property value 3584
Discussion 3584
Example 3584
IsValid 3585
Syntax 3585
Property value 3585
Discussion 3585
Example 3585
SerialNumber 3586
Syntax 3586
Property value 3586
Discussion 3586
Example 3586
Type 3587
Syntax 3587
Property value 3587
Discussion 3587
Example 3587
Keys 3588
Syntax 3588
Discussion 3588
Methods 3588
Properties 3588
Add 3589
Syntax 3589
Parameter 3589
Return value 3589
Exceptions 3589
GetEnumerator 3590
Syntax 3590
Return value 3590
Remove 3591
Syntax 3591
Parameter 3591
Return value 3591
Exceptions 3591
Count 3592
Syntax 3592
Property value 3592
Item 3593
Syntax 3593
Parameter 3593
Property value 3593
License 3594
Syntax 3594
Discussion 3594
Properties 3594
Count 3595
Syntax 3595
Property value 3595
Example 3595
IsEval 3596
Syntax 3596
Property value 3596
Discussion 3596
Keys 3597
Syntax 3597
Property value 3597
Type 3598
Syntax 3598
Property value 3598
Discussion 3598
Example 3598
UsedCount 3599
Syntax 3599
Property value 3599
Discussion 3599
Exceptions 3599
Example 3599
Licenses 3600
Syntax 3600
Discussion 3600
Methods 3600
Properties 3600
AddLicenseKey 3601
Syntax 3601
Parameter 3601
Return value 3601
Exceptions 3601
Commit 3602
Syntax 3602
Discussion 3602
Exceptions 3602
Syntax 3603
Return value 3603
Discussion 3603
Refresh 3604
Syntax 3604
Discussion 3604
RemoveLicenseKey 3605
Syntax 3605
Parameter 3605
Return value 3605
Exceptions 3605
Count 3606
Syntax 3606
Property value 3606
HasEvaluation 3607
Syntax 3607
Property value 3607
HasMachineLicense 3608
Syntax 3608
Property value 3608
ID 3609
Syntax 3609
Property value 3609
IsReadable 3610
Syntax 3610
Property value 3610
Discussion 3610
IsWritable 3611
Syntax 3611
Property value 3611
Discussion 3611
Item 3612
Syntax 3612
Parameter 3612
Return value 3612
Discussion 3612
LicensesCollection 3613
Syntax 3613
Discussion 3613
Methods 3613
Properties 3613
Find 3614
Syntax 3614
Parameter 3614
Return value 3614
Discussion 3614
GetEnumerator 3615
Syntax 3615
Return value 3615
GetLicensedCount 3616
Syntax 3616
Parameter 3616
Return value 3616
GetUsedCount 3617
Syntax 3617
Parameter 3617
Return value 3617
Exceptions 3617
Count 3618
Syntax 3618
Property value 3618
HasEvaluation 3619
Syntax 3619
Property value 3619
HasMachineLicense 3620
Syntax 3620
Property value 3620
Item 3621
Syntax 3621
Parameter 3621
Return value 3621
Map 3622
Syntax 3622
Discussion 3622
Methods 3622
Properties 3622
Add 3623
Syntax 3623
Parameters 3623
Return value 3623
Discussion 3623
Example 3623
Commit 3625
Syntax 3625
Discussion 3625
Exceptions 3625
Example 3625
Exists 3626
Syntax 3626
Parameter 3626
Return value 3626
Get 3627
Syntax 3627
Parameter 3627
Return value 3627
Example 3627
GetByID 3628
Syntax 3628
Parameter 3628
Return value 3628
Syntax 3629
Return value 3629
Discussion 3629
GetEnumerator 3630
Syntax 3630
Return value 3630
GetRedirectMap 3631
Syntax 3631
Parameter 3631
Return value 3631
Import 3632
Syntax 3632
Parameters 3632
Return value 3632
Discussion 3632
Exceptions 3632
Example 3632
Remove 3633
Syntax 3633
Parameter 3633
Exceptions 3633
Example 3633
RemoveByID 3634
Syntax 3634
Parameter 3634
Exceptions 3634
IsReadable 3635
Syntax 3635
Property value 3635
Discussion 3635
Example 3635
IsWritable 3636
Syntax 3636
Property value 3636
Discussion 3636
Example 3636
Name 3637
Syntax 3637
Property value 3637
Discussion 3637
Exceptions 3637
Example 3637
Store 3638
Syntax 3638
Property value 3638
Type 3639
Syntax 3639
Property value 3639
Discussion 3639
Example 3639
MzRoleAssignment 3640
Syntax 3640
Methods 3640
Properties 3640
GetComputer 3641
Syntax 3641
Return value 3641
Exceptions 3641
NetworkAccess 3642
Syntax 3642
Properties 3642
Discussion 3642
Priority 3643
Syntax 3643
Property value 3643
Discussion 3643
RequirePassword 3644
Syntax 3644
Property value 3644
RunAs 3645
Syntax 3645
Property value 3645
Discussion 3645
RunAsList 3646
Syntax 3646
Property value 3646
Discussion 3646
RunAsType 3647
Syntax 3647
Property value 3647
Discussion 3647
NetworkAccesses 3648
Syntax 3648
Methods 3648
GetEnumerator 3649
Syntax 3649
Return value 3649
Pam 3650
Syntax 3650
Discussion 3650
Methods 3650
Properties 3650
Application 3651
Syntax 3651
Property value 3651
Exceptions 3651
Example 3651
Pams 3652
Syntax 3652
Methods 3652
GetEnumerator 3653
Syntax 3653
Return value 3653
Right 3654
Syntax 3654
Methods 3654
Properties 3654
Commit 3655
Syntax 3655
Discussion 3655
Exceptions 3655
Delete 3656
Syntax 3656
Exceptions 3656
Description 3657
Syntax 3657
Property value 3657
IsReadable 3658
Syntax 3658
Property value 3658
IsWritable 3659
Syntax 3659
Property value 3659
Name 3660
Syntax 3660
Property value 3660
Exceptions 3660
Zone 3661
Syntax 3661
Property value 3661
Role 3662
Syntax 3662
Methods 3662
Properties 3663
AddCommand 3664
Syntax 3664
Parameter 3664
Discussion 3664
Exceptions 3664
Example 3664
AddNetworkAccess 3665
Syntax 3665
Parameter 3665
Discussion 3665
Exceptions 3665
AddPamAccess 3666
Syntax 3666
Parameter 3666
Discussion 3666
Exceptions 3666
AddSsh 3667
Syntax 3667
Parameter 3667
Discussion 3667
Exceptions 3667
AddWindowsApplication 3668
Syntax 3668
Parameter 3668
Discussion 3668
Exceptions 3668
AddWindowsDesktop 3669
Syntax 3669
Parameter 3669
Discussion 3669
Exceptions 3669
Example 3669
Assign 3670
Syntax 3670
Parameters 3670
Return value 3670
Discussion 3670
Exceptions 3670
Commit 3671
Syntax 3671
Discussion 3671
Exceptions 3671
Delete 3672
Syntax 3672
Exceptions 3672
GetCommands 3673
Syntax 3673
Return value 3673
GetNetworkAccesses 3674
Syntax 3674
Return value 3674
GetPamAccesses 3675
Syntax 3675
Return value 3675
GetSshRights 3676
Syntax 3676
Return value 3676
GetWindowsApplications 3677
Syntax 3677
Return value 3677
GetWindowsDesktops 3678
Syntax 3678
Return value 3678
IsApplicable 3679
Syntax 3679
Parameter 3679
Return value 3679
Discussion 3679
RemoveAllRights 3680
Syntax 3680
Discussion 3680
RemoveCommand 3681
Syntax 3681
Parameter 3681
Discussion 3681
RemoveNetworkAccess 3682
Syntax 3682
Parameter 3682
Discussion 3682
RemovePamAccess 3683
Syntax 3683
Parameter 3683
Discussion 3683
RemoveSshRight 3684
Syntax 3684
Parameter 3684
Discussion 3684
RemoveWindowsApplication 3685
Syntax 3685
Parameter 3685
Discussion 3685
RemoveWindowsDesktop 3686
Syntax 3686
Parameter 3686
Discussion 3686
SetApplicableDay 3687
Syntax 3687
Parameter 3687
Discussion 3687
SetApplicableHour 3688
Syntax 3688
Parameter 3688
Discussion 3688
AllowLocalUser 3689
Syntax 3689
Property value 3689
ApplicableTimeHexString 3690
Syntax 3690
Property value 3690
Discussion 3690
Exceptions 3690
Description 3691
Syntax 3691
Property value 3691
Guid 3692
Syntax 3692
Property value 3692
IsReadable 3693
Syntax 3693
Property value 3693
Discussion 3693
IsWritable 3694
Syntax 3694
Property value 3694
Discussion 3694
Name 3695
Syntax 3695
Property value 3695
Exceptions 3695
SystemRights 3696
Syntax 3696
Property value 3696
Discussion 3696
Zone 3697
Syntax 3697
Property value 3697
RoleAssignment 3698
Syntax 3698
Methods 3698
Properties 3698
Commit 3699
Syntax 3699
Discussion 3699
Exceptions 3699
Delete 3700
Syntax 3700
Exceptions 3700
GetTrustee 3701
Syntax 3701
Return value 3701
Exceptions 3701
Validate 3702
Syntax 3702
Exceptions 3702
EndTime 3703
Syntax 3703
Property value 3703
Exceptions 3703
Id 3704
Syntax 3704
Property value 3704
IsRoleOrphaned 3705
Syntax 3705
Property value 3705
IsTrusteeOrphaned 3706
Syntax 3706
Property value 3706
LocalTrustee 3707
Syntax 3707
Property value 3707
Exceptions 3707
Role 3708
Syntax 3708
Property value 3708
Exceptions 3708
StartTime 3709
Syntax 3709
Property value 3709
Exceptions 3709
TrusteeDn 3710
Syntax 3710
Property value 3710
Exceptions 3710
TrusteeType 3711
Syntax 3711
Property value 3711
Exceptions 3711
RoleAssignments 3712
Syntax 3712
Methods 3712
GetEnumerator 3713
Syntax 3713
Return value 3713
Exceptions 3713
Roles 3714
Syntax 3714
Methods 3714
GetEnumerator 3715
Syntax 3715
Return value 3715
Exceptions 3715
Ssh 3716
Syntax 3716
Discussion 3716
Methods 3716
Properties 3716
Application 3717
Syntax 3717
Property value 3717
Exceptions 3717
Sshs 3718
Syntax 3718
Methods 3718
GetEnumerator 3719
Syntax 3719
Return value 3719
Store 3720
Syntax 3720
Discussion 3720
Methods 3720
Properties 3720
Attach 3721
Syntax 3721
Parameters 3721
Exceptions 3721
Example 3721
Create 3722
Syntax 3722
Parameters 3722
Return value 3722
Discussion 3722
Exceptions 3722
Example 3722
Delete 3724
Syntax 3724
Parameter 3724
Exceptions 3724
Example 3724
Exists 3725
Syntax 3725
Parameter 3725
Return value 3725
Exceptions 3725
Example 3725
Syntax 3726
Return value 3726
Discussion 3726
Open 3727
Syntax 3727
Parameter 3727
Return value 3727
Exceptions 3727
Example 3727
IsReadable 3728
Syntax 3728
Property value 3728
Discussion 3728
Exceptions 3728
Example 3728
IsWritable 3729
Syntax 3729
Property value 3729
Discussion 3729
Exceptions 3729
Example 3729
User 3730
Syntax 3730
Discussion 3730
Methods 3730
Properties 3730
AddUnixProfile 3731
Syntax 3731
Parameters 3731
Return value 3731
Discussion 3731
Exceptions 3731
Example 3731
Commit 3733
Syntax 3733
Discussion 3733
Exceptions 3733
Example 3733
CommitWithoutCheck 3734
Syntax 3734
Discussion 3734
Exceptions 3734
Example 3734
Syntax 3735
Return value 3735
Discussion 3735
Exceptions 3735
GetRoleAssignmentsFromDomain 3736
Syntax 3736
Parameters 3736
Return value 3736
Discussion 3736
Example 3736
GetRoleAssignmentsFromForest 3737
Syntax 3737
Parameters 3737
Return value 3737
Discussion 3737
Example 3737
Refresh 3738
Syntax 3738
Discussion 3738
Exceptions 3738
Example 3738
AdsiInterface 3739
Syntax 3739
Property value 3739
Example 3739
ADsPath 3740
Syntax 3740
Property value 3740
Discussion 3740
Example 3740
ID 3741
Syntax 3741
Property value 3741
Example 3741
UnixProfiles 3742
Syntax 3742
Property value 3742
Discussion 3742
Example 3742
UserInfo 3743
Syntax 3743
Methods 3743
Properties 3743
Commit 3745
Syntax 3745
Delete 3746
Syntax 3746
Discussion 3746
Exceptions 3746
GetCandidate 3747
Syntax 3747
Return value 3747
Import 3748
Syntax 3748
Parameter 3748
Discussion 3748
SetCandidate 3749
Syntax 3749
Parameters 3749
Discussion 3749
UpdateStatus 3750
Syntax 3750
Discussion 3750
CandidateDN 3751
Syntax 3751
Property value 3751
Discussion 3751
Gecos 3752
Syntax 3752
Property value 3752
HomeDirectory 3753
Syntax 3753
Property value 3753
ID 3754
Syntax 3754
Property value 3754
Name 3755
Syntax 3755
Property value 3755
PrimaryGroupID 3756
Syntax 3756
Property value 3756
Discussion 3756
Shell 3757
Syntax 3757
Property value 3757
Source 3758
Syntax 3758
Property value 3758
Discussion 3758
Status 3759
Syntax 3759
Property value 3759
Discussion 3759
StatusDescription 3760
Syntax 3760
Property value 3760
Discussion 3760
TimeStamp 3761
Syntax 3761
Property value 3761
Example 3761
UID 3762
Syntax 3762
Property value 3762
Discussion 3762
UserInfos 3763
Syntax 3763
Methods 3763
Properties 3763
Find 3764
Syntax 3764
Parameter 3764
Return value 3764
GetEnumerator 3765
Syntax 3765
Return value 3765
Count 3766
Syntax 3766
Property value 3766
Discussion 3766
IsEmpty 3767
Syntax 3767
Property value 3767
Discussion 3767
UserUnixProfile 3768
Syntax 3768
Discussion 3768
Methods 3768
Properties 3768
Commit 3770
Syntax 3770
Discussion 3770
Exceptions 3770
Example 3770
Delete 3771
Syntax 3771
Discussion 3771
Example 3771
Syntax 3772
Return value 3772
Discussion 3772
GetPrimaryGroup 3773
Syntax 3773
Return value 3773
Example 3773
Refresh 3774
Syntax 3774
Discussion 3774
Example 3774
Validate 3775
Syntax 3775
Discussion 3775
Exceptions 3775
Example 3775
ADsPath 3776
Syntax 3776
Property value 3776
Example 3776
Cims 3777
Syntax 3777
Property value 3777
Discussion 3777
HomeDirectory 3778
Syntax 3778
Property value 3778
Example 3778
ID 3779
Syntax 3779
Property value 3779
Example 3779
IsForeign 3780
Syntax 3780
Property value 3780
Discussion 3780
Example 3780
IsOrphan 3781
Syntax 3781
Property value 3781
Discussion 3781
Example 3781
IsReadable 3782
Syntax 3782
Property value 3782
Discussion 3782
Example 3782
IsSFU 3783
Syntax 3783
Property value 3783
IsWritable 3784
Syntax 3784
Property value 3784
Discussion 3784
Example 3784
Name 3785
Syntax 3785
Property value 3785
Example 3785
PrimaryGroup 3786
Syntax 3786
Property value 3786
Discussion 3786
Example 3786
ProfileState 3787
Syntax 3787
Property value 3787
Exceptions 3787
Shell 3788
Syntax 3788
Property value 3788
Example 3788
Type 3789
Syntax 3789
Property value 3789
Discussion 3789
Example 3789
UnixEnabled 3790
Syntax 3790
Property value 3790
Discussion 3790
Exceptions 3790
Example 3790
User 3791
Syntax 3791
Property value 3791
UserId 3792
Syntax 3792
Property value 3792
Zone 3793
Syntax 3793
Property value 3793
Example 3793
UserUnixProfiles 3794
Syntax 3794
Discussion 3794
Methods 3794
Properties 3794
GetEnumerator 3795
Syntax 3795
Return value 3795
Refresh 3796
Syntax 3796
Discussion 3796
Count 3797
Syntax 3797
Property value 3797
Example 3797
IsEmpty 3798
Syntax 3798
Property value 3798
Discussion 3798
WindowsApplication 3799
Syntax 3799
Methods 3799
Properties 3799
Discussion 3799
CreateApplicationCriteria 3800
Syntax 3800
Discussion 3800
Example 3800
ApplicationCriteriaList 3801
Syntax 3801
Property value 3801
Example 3801
Priority 3802
Syntax 3802
Property value 3802
Discussion 3802
Example 3802
Syntax 3803
Property value 3803
Example 3803
RunAs 3804
Syntax 3804
Property value 3804
Discussion 3804
RunAsList 3805
Syntax 3805
Property value 3805
Discussion 3805
RunAsType 3806
Syntax 3806
Property value 3806
Discussion 3806
Example 3806
WindowsApplicationCriteria 3807
Syntax 3807
Methods 3807
Properties 3807
Discussion 3808
Validate 3809
Syntax 3809
Discussion 3809
Exception 3809
Argument 3810
Syntax 3810
Property value 3810
CompanyName 3811
Syntax 3811
Property value 3811
Example 3811
CompanyNameMatchOption 3812
Syntax 3812
Property value 3812
Example 3812
Description 3813
Syntax 3813
Property value 3813
Example 3813
FileDescriptionMatchOption 3814
Syntax 3814
Property value 3814
FileDescriptionMatchOption 3815
Syntax 3815
Property value 3815
FileHash 3816
Syntax 3816
Property value 3816
FileName 3817
Syntax 3817
Property value 3817
FileType 3818
Syntax 3818
Property value 3818
Example 3818
FileVersion 3819
Syntax 3819
Property value 3819
FileVersionMatchOption 3820
Syntax 3820
Property value 3820
IsArgumentCaseSensitive 3821
Syntax 3821
Property value 3821
IsArgumentExactMatch 3822
Syntax 3822
Property value 3822
LocalOwner 3823
Syntax 3823
Property value 3823
OwnerDN 3824
Syntax 3824
Property value 3824
OwnerSid 3825
Syntax 3825
Property value 3825
OwnerType 3826
Syntax 3826
Property value 3826
Path 3827
Syntax 3827
Property value 3827
ProductName 3828
Syntax 3828
Property value 3828
ProductNameMatchOption 3829
Syntax 3829
Property value 3829
ProductVersion 3830
Syntax 3830
Property value 3830
ProductVersionMatchOption 3831
Syntax 3831
Property value 3831
Publisher 3832
Syntax 3832
Property value 3832
PublisherMatchOption 3833
Syntax 3833
Property value 3833
RequireAdministrator 3834
Syntax 3834
Property value 3834
SerialNumber 3835
Syntax 3835
Property value 3835
SerialNumberMatchOption 3836
Syntax 3836
Property value 3836
WindowsApplications 3837
Syntax 3837
Methods 3837
GetEnumerator 3838
Syntax 3838
Return value 3838
WindowsDesktop 3839
Syntax 3839
Properties 3839
Discussion 3839
Priority 3840
Syntax 3840
Property value 3840
Discussion 3840
Syntax 3841
Property value 3841
RunAs 3842
Syntax 3842
Property value 3842
Discussion 3842
RunAsList 3843
Syntax 3843
Property value 3843
Discussion 3843
RunAsType 3844
Syntax 3844
Property value 3844
Discussion 3844
WindowsDesktops 3845
Syntax 3845
Methods 3845
GetEnumerator 3846
Syntax 3846
Return value 3846
WindowsUser 3847
Syntax 3847
Methods 3847
Properties 3847
Discussion 3847
AddUserRoleAssignment 3848
Syntax 3848
Parameters 3848
Return value 3848
Discussion 3848
Exceptions 3848
Syntax 3849
Return value 3849
Discussion 3849
Exceptions 3849
GetEffectiveUserRoleAssignments 3850
Syntax 3850
Return value 3850
Discussion 3850
Name 3851
Syntax 3851
Property value 3851
WindowsUsers 3852
Syntax 3852
Methods 3852
GetEnumerator 3853
Syntax 3853
Return value 3853
Zone 3854
Syntax 3854
Discussion 3854
Methods 3854
Properties 3855
AddMitUser 3858
Syntax 3858
Parameters 3858
Return value 3858
Discussion 3858
Exceptions 3858
Example 3858
Commit 3860
Syntax 3860
Discussion 3860
Exceptions 3860
Example 3860
CreateImportPendingGroup 3861
Syntax 3861
Parameters 3861
Return value 3861
Discussion 3861
Example 3861
CreateImportPendingUser 3862
Syntax 3862
Parameters 3862
Return value 3862
Discussion 3862
Example 3862
Delete 3863
Syntax 3863
Discussion 3863
Exceptions 3863
Example 3863
GetComputerByDN 3864
Syntax 3864
Parameter 3864
Return value 3864
Discussion 3864
Example 3864
GetComputers 3865
Syntax 3865
Return value 3865
Example 3865
GetComputersContainer 3866
Syntax 3866
Return value 3866
Discussion 3866
Exceptions 3866
Syntax 3867
Return value 3867
Discussion 3867
GetDisplayName 3868
Syntax 3868
Return value 3868
Discussion 3868
Example 3868
GetGroupsContainer 3869
Syntax 3869
Return value 3869
Discussion 3869
Exceptions 3869
GetGroupUnixProfile 3870
Syntax 3870
Parameter 3870
Return value 3870
Discussion 3870
Exceptions 3870
Example 3870
GetGroupUnixProfileByDN 3871
Syntax 3871
Parameter 3871
Return value 3871
Discussion 3871
Exceptions 3871
Example 3871
GetGroupUnixProfileByName 3872
Syntax 3872
Parameter 3872
Return value 3872
Discussion 3872
Exceptions 3872
Example 3872
GetGroupUnixProfiles 3873
Syntax 3873
Return value 3873
Example 3873
GetImportPendingGroup 3874
Syntax 3874
Parameter 3874
Return value 3874
Discussion 3874
Example 3874
GetImportPendingGroups 3875
Syntax 3875
Return value 3875
Example 3875
GetImportPendingUser 3876
Syntax 3876
Parameter 3876
Return value 3876
Discussion 3876
Example 3876
GetImportPendingUsers 3877
Syntax 3877
Return value 3877
Example 3877
GetLocalGroupsContainer 3878
Syntax 3878
Return value 3878
Discussion 3878
Exceptions 3878
GetLocalGroupUnixProfile 3879
Syntax 3879
Parameter 3879
Return value 3879
Exceptions 3879
GetLocalGroupUnixProfileByDN 3880
Syntax 3880
Parameter 3880
Return value 3880
GetLocalGroupUnixProfileByGid (Int32) 3881
Syntax 3881
Parameter 3881
Return value 3881
GetLocalGroupUnixProfiles 3882
Syntax 3882
Return value 3882
GetLocalUsersContainer 3883
Syntax 3883
Return value 3883
Discussion 3883
Exceptions 3883
GetLocalUserUnixProfile 3884
Syntax 3884
Parameter 3884
Return value 3884
GetLocalUserUnixProfileByDN 3885
Syntax 3885
Parameter 3885
Return value 3885
GetLocalUserUnixProfileByUid (Int32) 3886
Syntax 3886
Parameter 3886
Return value 3886
GetLocalUserUnixProfiles 3887
Syntax 3887
Return value 3887
GetUsersContainer 3888
Syntax 3888
Return value 3888
Discussion 3888
Exceptions 3888
GetUserUnixProfileByDN 3889
Syntax 3889
Parameter 3889
Return value 3889
Discussion 3889
Exceptions 3889
Example 3889
GetUserUnixProfileByName 3890
Syntax 3890
Parameter 3890
Return value 3890
Exceptions 3890
Example 3890
GetUserUnixProfiles 3891
Syntax 3891
Return value 3891
Example 3891
GroupUnixProfileExists 3892
Syntax 3892
Parameter 3892
Return value 3892
Exceptions 3892
Example 3892
LocalGroupUnixProfileExists 3893
Syntax 3893
Parameter 3893
Return value 3893
Exceptions 3893
LocalUserUnixProfileExists 3894
Syntax 3894
Parameter 3894
Return value 3894
Exceptions 3894
PrecreateComputer 3895
Syntax 3895
Parameters 3895
Return value 3895
Discussion 3895
PrecreateWindowsComputer 3896
Syntax 3896
Parameters 3896
Return value 3896
Refresh 3897
Syntax 3897
Discussion 3897
Exceptions 3897
Example 3897
UserUnixProfileExists 3898
Syntax 3898
Parameter 3898
Return value 3898
Exceptions 3898
Example 3898
AdsiInterface 3899
Syntax 3899
Property value 3899
Discussion 3899
Example 3899
ADsPath 3900
Syntax 3900
Property value 3900
Example 3900
AgentlessAttribute 3901
Syntax 3901
Property value 3901
Discussion 3901
Exceptions 3901
Example 3901
AvailableShells 3902
Syntax 3902
Property value 3902
Discussion 3902
Example 3902
Cims 3903
Syntax 3903
Property value 3903
Discussion 3903
DefaultGroup 3904
Syntax 3904
Property value 3904
Discussion 3904
Example 3904
DefaultHomeDirectory 3905
Syntax 3905
Property value 3905
Discussion 3905
Example 3905
DefaultShell 3906
Syntax 3906
Property value 3906
Discussion 3906
Example 3906
DefaultValueZone 3907
Syntax 3907
Property value 3907
Discussion 3907
Example 3907
Description 3908
Syntax 3908
Property value 3908
Discussion 3908
Example 3908
FullName 3909
Syntax 3909
Property value 3909
Discussion 3909
Example 3909
GroupAutoProvisioningEnabled 3910
Syntax 3910
Property value 3910
Discussion 3910
ID 3911
Syntax 3911
Property value 3911
Discussion 3911
Example 3911
IsHierarchical 3912
Syntax 3912
Property value 3912
IsReadable 3913
Syntax 3913
Property value 3913
Discussion 3913
Example 3913
IsSFU 3914
Syntax 3914
Property value 3914
Discussion 3914
Example 3914
IsTruncateName 3915
Syntax 3915
Property value 3915
Discussion 3915
IsWritable 3916
Syntax 3916
Property value 3916
Discussion 3916
Example 3916
Licenses 3917
Syntax 3917
Property value 3917
MasterDomainController 3918
Syntax 3918
Property value 3918
Example 3918
MustMaintainADGroupMembership 3919
Syntax 3919
Property value 3919
Discussion 3919
Example 3919
Name 3920
Syntax 3920
Property value 3920
Exceptions 3920
Example 3920
NextAvailableGID 3921
Syntax 3921
Property value 3921
Discussion 3921
Example 3921
NextAvailableUID 3922
Syntax 3922
Property value 3922
Discussion 3922
Example 3922
NextGID 3923
Syntax 3923
Property value 3923
Discussion 3923
NextUID 3924
Syntax 3924
Property value 3924
Discussion 3924
NISDomain 3925
Syntax 3925
Property value 3925
Discussion 3925
Exceptions 3925
Example 3925
ReservedGID 3926
Syntax 3926
Discussion 3926
Example 3926
ReservedUID 3927
Syntax 3927
Discussion 3927
Example 3927
Schema 3928
Syntax 3928
Property value 3928
Discussion 3928
Exceptions 3929
Example 3929
SFUDomain 3930
Syntax 3930
Property value 3930
Example 3930
UserAutoProvisioningEnabled 3931
Syntax 3931
Property value 3931
Discussion 3931
Version 3932
Syntax 3932
Property value 3932
Example 3932
HierarchicalZoneComputer 3933
Syntax 3933
Discussion 3933
Methods 3933
Properties 3934
AddAccessGroup 3936
Syntax 3936
Parameters 3936
Return value 3936
Discussion 3936
Exceptions 3936
AddGroupPartialProfile 3937
Syntax 3937
Parameters 3937
Return value 3937
Discussion 3937
Exceptions 3937
Example 3937
AddLocalGroupPartialProfile 3938
Syntax 3938
Parameters 3938
Return value 3938
Exceptions 3938
AddLocalUserPartialProfile 3939
Syntax 3939
Parameters 3939
Return value 3939
Exceptions 3939
Syntax 3940
Return value 3940
AddUserPartialProfile 3941
Syntax 3941
Parameters 3941
Return value 3941
Discussion 3941
Exceptions 3941
Example 3941
CreateImportPendingGroup 3942
Syntax 3942
Parameters 3942
Return value 3942
Discussion 3942
CreateImportPendingUser 3943
Syntax 3943
Parameters 3943
Return value 3943
Discussion 3943
DeleteAllProfiles 3944
Syntax 3944
Discussion 3944
DeleteZone 3945
Syntax 3945
Discussion 3945
GetAccessGroup 3946
Syntax 3946
Parameters 3946
Return value 3946
Discussion 3946
Exceptions 3946
Example 3946
Syntax 3947
Return value 3947
GetEffectiveUserUnixProfiles 3948
Syntax 3948
Return value 3948
GetGroupUnixProfile 3949
Syntax 3949
Parameter 3949
Return value 3949
Discussion 3949
Exceptions 3949
GetGroupUnixProfileByDN 3950
Syntax 3950
Parameter 3950
Return value 3950
Discussion 3950
Exceptions 3950
GetGroupUnixProfileByName 3951
Syntax 3951
Parameter 3951
Return value 3951
Discussion 3951
Exceptions 3951
GetGroupUnixProfiles 3952
Syntax 3952
Return value 3952
GetImportPendingGroup 3953
Syntax 3953
Parameter 3953
Return value 3953
Discussion 3953
GetImportPendingGroups 3954
Syntax 3954
Return value 3954
GetImportPendingUser 3955
Syntax 3955
Parameter 3955
Return value 3955
Discussion 3955
GetImportPendingUsers 3956
Syntax 3956
Return value 3956
GetIPendingGroupID 3957
Syntax 3957
Return value 3957
GetIPendingUserID 3958
Syntax 3958
Return value 3958
GetLocalGroupUnixProfile 3959
Syntax 3959
Parameter 3959
Return value 3959
Exceptions 3959
GetLocalGroupUnixProfileByDN 3960
Syntax 3960
Parameter 3960
Return value 3960
GetLocalGroupUnixProfileByGid (Int32) 3961
Syntax 3961
Parameter 3961
Return value 3961
GetLocalGroupUnixProfiles 3962
Syntax 3962
Return value 3962
GetLocalUserUnixProfile 3963
Syntax 3963
Parameter 3963
Return value 3963
GetLocalUserUnixProfileByDN 3964
Syntax 3964
Parameter 3964
GetLocalUserUnixProfileByUid (Int32) 3965
Syntax 3965
Parameter 3965
Return value 3965
GetLocalUserUnixProfiles 3966
Syntax 3966
Return value 3966
GetNssVariable 3967
Syntax 3967
Parameter 3967
Return value 3967
GetNSSVariables 3968
Syntax 3968
Return value 3968
GetPrimaryUser 3969
Syntax 3969
Parameters 3969
Return value 3969
Discussion 3969
Exceptions 3969
Syntax 3970
Parameter 3970
Return value 3970
Exceptions 3970
Syntax 3971
Parameter 3971
Return value 3971
Exceptions 3971
GetRoleAssigments 3972
Syntax 3972
Return value 3972
Syntax 3973
Parameter 3973
Return value 3973
Exceptions 3973
GetRoleAssignmentToAllUnixUsers 3974
Syntax 3974
Parameter 3974
Return value 3974
Discussion 3974
Exceptions 3974
GetSecondaryUsers 3975
Syntax 3975
Parameters 3975
Return value 3975
Discussion 3975
Exceptions 3975
GetUserProfiles 3976
Syntax 3976
Parameters 3976
Return value 3976
Discussion 3976
Exceptions 3976
Syntax 3977
Parameters 3977
Return value 3977
Discussion 3977
Exceptions 3977
GetUserUnixProfile 3978
Syntax 3978
Parameter 3978
Return value 3978
Discussion 3978
Exceptions 3978
GetUserUnixProfileByDN 3979
Syntax 3979
Parameter 3979
Return value 3979
Discussion 3979
Exceptions 3979
GetUserUnixProfileByName 3980
Syntax 3980
Parameter 3980
Return value 3980
Exceptions 3980
GetUserUnixProfileByUid 3981
Syntax 3981
Parameter 3981
Return value 3981
Discussion 3981
Exceptions 3981
GetUserUnixProfiles 3982
Syntax 3982
Return value 3982
GroupUnixProfileExists 3983
Syntax 3983
Parameter 3983
Return value 3983
Exceptions 3983
LocalGroupUnixProfileExists 3984
Syntax 3984
Parameter 3984
Return value 3984
Exceptions 3984
LocalUserUnixProfileExists 3985
Syntax 3985
Parameter 3985
Return value 3985
Exceptions 3985
SetNSSVariable 3986
Syntax 3986
Parameter 3986
UserUnixProfileExists 3987
Syntax 3987
Parameter 3987
Return value 3987
Exceptions 3987
ComputerZoneADsPath 3988
Syntax 3988
Property value 3988
Discussion 3988
IsOrphanZone 3989
Syntax 3989
Property value 3989
Discussion 3989
NssVariables 3990
Syntax 3990
Property value 3990
Discussion 3990
UserHomeDirectory 3991
Syntax 3991
Property value 3991
UserShell 3992
Syntax 3992
Property value 3992
Zone 3993
Syntax 3993
Property value 3993
Discussion 3993
Exceptions 3993
Timebox 3994
Hex string 3994
Hour mapping 3994
Day mapping 3995
Server Suite - All Release Notes 3997
Server Suite Product Component Version Table 3998

Support Versions 4000
Server Suite 2022.1 Release Notes 4009
About this Release 4009
Media 4009
Server Suite for 64-bit Windows 4009

Server Suite Agents for UNIX/Linux 4010
Support Statement 4011
Supported Platforms 4011
Newly Added Supported Platforms 4011
Supported UNIX/Linux Platforms 4011

Additional Information 4013
Supported Windows Platforms 4013
Notice of Termination of Support 4014
Security Advisories 4014
Release Notes for Server Suite Components 4014
Download Center 4014
Bugs Fixed 4015
Known Issues 4015
Additional Information and Support 4015
Authentication and Privilege Elevation Release Notes 4016
Authentication Service and Privilege Elevation Service 5.9.1 Release Notes (Server Suite 2022.1) 4017
Feature Changes in this Release 4017

General 4017
Security Fix 4017
Server Suite DirectControl Agent for 4017
DirectControl Command Line Utilities 4017
New Parameters 4017
New Parameters for DirectControl 4017
New Parameters for OpenLDAP Proxy 4018
Modified Parameters 4018
Audit Trail Events 4018
Server Suite Access Manager 4018
Server Suite Access Module for PowerShell 4018
Server Suite Group Policy Management 4018
Server Suite Licensing Service 4018
Server Suite OpenLDAP Proxy 4018
Server Suite OpenSSH 4018
Server Suite OpenSSL 4018
Server Suite Report Services 4018
Server Suite Smart Card 4018
Server Suite Windows Installer 4018
Server Suite Windows SDK 4018
Server Suite Zone Provisioning Agent 4019
Fixed Issues in this Release 4019
General 4019
Security Fixes 4019
DirectControl Installation 4019
Server Suite ADEdit 4019
Server Suite NIS 4020
Fixes in Release 2022.1 Component Update 4020
Known Issues 4020

Smart Card 4021
Report Services 4022
Authentication Service and Privilege Elevation Service 5.9.0 Release Notes (Server Suite 2022) 4023
Feature Changes in this Release 4023

General 4023
Security Fix 4023
New Parameters 4023
Modified Parameters 4023
Server Suite OpenSSL 4024
Fixed Issues in this Release 4024

General 4024
Security Fix 4024
DirectControl Installation 4025
Server Suite NIS 4025
Fixes in Release 2022 Component Update 4026
Known Issues 4026

Smart Card 4027
Report Services 4028
Windows Agent Release Notes 4029
Agent for Windows 5.9.1 Release Notes (Server Suite 2022.1) 4030
About Server Suite Agent for Windows 4030
Feature Changes 4030

Security Fixes 4030
General Changes 4030
Fixed Issues 4030
Known Issues 4030
Installation and Uninstallation 4030
Configuration 4031
Environment 4032
RunAsRole 4032
Desktop with Elevated Privileges 4033
Roles and Rights 4034
Compatibility with 3rd Party Products 4034
Endpoint Enrollment 4035
Server Suite Agent for Windows 4035
Agent for Windows 5.9.0 Release Notes (Server Suite 2022) 4037
About Server Suite Agent for Windows 4037

Security Fixes 4037
General Changes 4037
Fixed Issues 4037

Fixed Issues in the 2022 Component Update 4037
Known Issues 4037

Installation and Uninstallation 4037
Configuration 4038
Environment 4039
RunAsRole 4039
Desktop with Elevated Privileges 4040
Roles and Rights 4041
Compatibility with 3rd Party Products 4041
Endpoint Enrollment 4042
Windows Agent Release Notes 4044

Audit and Monitoring Service 5.9.1 Release Notes (Server Suite 2022.1) 4045
About Server Suite Auditing & Monitoring Service 4045
Feature Changes in Auditing & Monitoring Service 5.9.1 (Release 2022.1) 4045
General 4045
Compatibility 4045
Security Fix 4045
Audit Collector 4045
Audit Analyzer and Session Player 4045
Audit Manager 4045
DirectAudit Agent for 4046
Database 4046
FindSessions Tool 4046
Audit Module for PowerShell 4046
Audit Management Server 4046
Bugs Fixed in this Release 4046

General 4046
Windows Install / Upgrade / Uninstall 4046
Audit Manager 4046
Database 4046
Known Issues 4047
General 4047
Collector 4047
Audit Manager 4048
Server Suite DirectAudit Agent for 4048
General 4048
RedHat Linux 4049
Debian Linux 4050
Solaris 4050
AIX 4051
HPUX 4051
Database 4051
FindSession Tools 4052
Delinea Audit Module for PowerShell 4053
Audit and Monitoring Service 5.9.0 Release Notes (Server Suite 2022) 4054
About Server Suite Auditing & Monitoring Service 4054
Feature Changes in Auditing & Monitoring Service 5.9.0 (Release 2022) 4054
General 4054
Compatibility 4054
Security Fix 4055
Audit Manager 4055
Database 4055
Bugs Fixed in this Release 4055

General 4055
Audit Manager 4055
Database 4056
Known Issues 4056

General 4056
Collector 4056
Audit Manager 4057
Server Suite DirectAudit Agent for 4057
General 4057
RedHat Linux 4058
Debian Linux 4059
Solaris 4059
AIX 4060
HPUX 4060
Database 4060
FindSession Tools 4061
Delinea Audit Module for PowerShell 4062
Server Suite 2022 Release Notes 4063

Media 4063
Server Suite for 64-bit Windows 4063
Server Suite Agents for UNIX/Linux 4064
Support Statement 4065

Newly Added Supported Platforms 4065
Supported UNIX/Linux Platforms 4065

Additional Information 4067
Supported Windows Platforms 4067
Security Advisories 4068

Release Notes for Server Suite Components 4068
Download Center 4068
Bugs Fixed 4069
Known Issues 4069

Adbindproxy Release Notes 4070
Release 2022 - Adbindproxy Release Notes 4071

Package Contents 4071
Bugs Fixed 4071
Known Issues 4071

Mac Release Notes 4073

Server Suite for Mac 2022 Release Notes 4074
What's Included in this Release 4074
Supported Platforms and System Requirements 4074
Installing on macOS 12 Monterey 4074
Setting Full Disk Access for the DirectControl Agent 4074
Feature Changes and Notable Fixes in this Release 4075
Known macOS Issues 4076

Server Suite for Mac 2022.1 Release Notes 4077
What's Included in this Release 4077
Supported Platforms and System Requirements 4077
Installing on macOS 13 Ventura 4077

Setting Full Disk Access for the DirectControl Agent 4077
Feature Changes and Notable Fixes in this Release (Release 2022.1 Component Update) 4079
Known macOS Issues 4079

Putty Release Notes 4080

PuTTY Release Notes (Server Suite 2022) 4081

Fixed Issues 4081
Known Issues 4081

PuTTY Release Notes (Server Suite 2022.1) 4082

Fixed Issues 4082
Known Issues 4082
Welcome to Server Suite
This area includes the following sections:
Install and Upgrade
Configuration and Policy Guides
Admin Guides
Reports and Events
Auditing
User Guides
Evaluations
Server Suite Free
Integrations
Developer Tools
Release Notes
Welcome to Server Suite
This area includes the following sections:
Install and Upgrade
Configuration and Policy Guides
Admin Guides
Reports and Events
Auditing
User Guides
Evaluations
Server Suite Free
Integrations
Developer Tools
Release Notes
Install and Upgrade
Planning and Deployment Guide
Licensing Guide
Upgrade Guide
Using this Planning and Deployment Guide
Most large-scale deployments rely on a project team to design and articulate a project plan, and team members take on specific roles and responsibilities.
Depending on your role and responsibilities, you may want to read portions of this guide selectively.
Note: Most of the information in this guide applies to all platforms. However, there are some deployment scenarios and tasks that are unique to
Mac OS X computers. If you manage Mac OS X computers and users, refer to the Unexpected Link Text for additional information.
The guide provides the following information:
Planning Deployment for an Enterprise provides an overview of key concepts and the deployment lifecycle, including suggestions for who should
participate in the planning process and factors to consider that will affect your deployment strategy.
Architecture and Basic Operations describes the key components of the Server Suite software architecture and how the components work together to
provide authentication and authorization services.
Deployment Process Overview provides an overview of the steps involved in a deployment project and a preview of the tasks you can expect to
complete.
Planning organizational units and security groups discusses the Active Directory objects and organizational model that is recommended to ensure a
separation of duties for UNIX administrators.
Installing Authentication & Privilege Services provides step-by-step instructions for installing and configuring Server Suite software components on
Windows computers.
Installing Agents on Computers to be Managed describes the installation options available and provides instructions for installing Server Suite software
components on UNIX and Linux computers.
Planning to use Server Suite zones describes the importance of zones and how you can use classic and hierarchical zone for identity management,
access control, and delegated administration.
Preparing To Migrate Existing Users And Groups describes the steps to take to prepare for migrating existing users and groups, including collecting and
analyzing existing profile information and creating the first zone.
Migrating Existing Users To Hierarchical Zones describes how to import and migrate an existing user population into hierarchical zones and enable
authentication using Active Directory and Server Suite software.
Joining Computers to a Domain and Zone describes how to complete the initial migration by joining the Active Directory domain and a Server Suite zone.
Provisioning New User and Group Profiles After Migration describes how to use the Zone Provisioning Agent and Active Directory groups to automate
provisioning of new users and groups.
Validating Operations After Deploying provides suggestions for formal testing and validation activities you can perform to move from a pilot deployment
to a production environment.
Defining Role-Based Access for Users and Computers describes the most common roles that organizations create to complete the initial deployment
and how to configure the appropriate rights and assign the roles to appropriate groups.
Migrating And Managing Service Accounts describes the strategies you can use if you want to migrate local service accounts to Active Directory to
improve security for those accounts.
Planning to Deploy in a Demilitarized Zone (DMZ) describes how to deploy Server Suite components to allow communication between a perimeter
(DMZ) zone and an internal zone.
Managing and Evolving Operations After Deployment describes management activity for operations staff and additional services you may want to
implement after deployment as you evolve the Server Suite software solution.
Templates and Sample Forms provides examples of common documents and notification messages that you can customize and use throughout the
deployment process.
Permissions Required for Administrative Tasks provides information about the specific Active Directory permissions required to perform administrative
tasks on objects specific to Server Suite.
Planning Deployment for an Enterprise
This section provides a brief review of the information you should have to begin planning a successful enterprise deployment of Server Suite. It includes an
overview of the deployment life cycle, roles and responsibilities to consider in assembling a deployment team, and the factors you should consider during the
planning phase that will affect how you deploy Centrify software.
For an overview of Centrify software and an introduction to basic tasks, see the Evaluation Guide for Linux and UNIX. For a general introduction to identity,
access, and configuration management or more detailed information about performing administrative tasks, see the Administrator’s Guide for Linux and
UNIX.
What You Should Know Before Planning a Deployment
Before you begin planning a full scale deployment of Centrify software, you should be familiar with key concepts, terminology, and components for Server
Suite and Active Directory. You should also have information about your existing environment.
Before you continue planning the deployment, verify you have information about:
How Active Directory is used to store user, group, and computer information in your organization and the Active Directory schema you currently have
deployed.
How you currently manage services and provision users for both Windows and nonWindows computers.
How the Centrify Agent installed on a UNIX, Linux, or Mac OS X computer makes that computer part of an Active Directory domain.
How zones enable you to manage user profiles, control access to computer and application resources, and delegate administrative tasks.
If you are not familiar with Centrify architecture and the components that make up the Server Suite, see Architecture and basic operations to be sure you
understand the concepts, core components, and operations that enable Active Directory users to log on to UNIX, Linux, and Mac OS X computers. This guide
assumes you also have access to the Administrator’s Guide for Linux and UNIX and can refer to it, as needed, for additional details.
Why Planning a Deployment is Important
Because Centrify software becomes a critical part of your IT infrastructure once deployed, it is important that you plan and test your deployment strategy
and validate the results you expect before placing Centrify components into a production environment.
After you deploy Centrify software in a production environment, the rights and roles you define will control whether users can log on and what they can do on
specific computers if they are allowed to log on. Because preventing users from accessing critical resources or services can affect business operations, you
should analyze the requirements of your environment as thoroughly as possible before moving from a pilot deployment into production.
The deployment process described in this guide is intended to help you to migrate existing users and groups to Active Directory with minimal disruption to
end-user activity and ongoing business services. The recommendations presented are designed to give you flexibility and provide you with a framework for
deploying that minimizes the effect of the deployment on the existing user population.
Note: Planning is important regardless of whether you are deploying on Windows, UNIX, Linux, or Mac computers. However, some deployment
steps can be skipped if you are only deploying on Windows computers or if you aren’t migrating any local users or groups. For more information
about deploying only on Windows computers, see the Administrator’s Guide for Windows. For information that is specifically about deploying on
Mac computers, see the Administrator’s Guide for Mac.
What to Expect During Deployment
In most organizations, a deployment takes place in the following stages:
Evaluation
A primary senior analyst or small group installs the software in an isolated test environment. The main goal of this stage is to learn basic concepts,
terminology, and operations and validate any specific functionality that is critical to the organization adopting the software. The lab environment also allows
you to test the planned changes to system and user management processes without affecting user access. This proof-of-concept stage often takes place
before the decision to purchase the software or with the decision to purchase a small number of licenses for extended testing.
Analysis and Design
During this stage, a planning team does deeper analysis into the goals and requirements of the organization, the current state of the environment, and the
deployment and management options that best suit the organization. The main goal of this stage is to design how you will use zones, import user account
information, and assign rights and roles through a combination of Active Directory groups and zone definitions. Most of the information in this guide is
intended to help you make those decisions and validate them in a pilot deployment.
Pilot Deployment
The pilot deployment is intended to be more robust than the evaluation stage. The pilot deployment is typically 10 to 20 computers, often with a common
administrative owner or administrative group. The main goal of this stage is to verify your analysis accurately described your environment and to uncover any
gaps that might have been missed or special circumstances that require adjustment to the design planned for zones, user account information, or rights and
roles. You can include more than 20 computers in the pilot deployment, but limiting the number makes the initial migration of the user population more
manageable while you become familiar with the process.
Testing and Validation
After deploying the software, most organizations perform at least some formal testing of specific scenarios to ensure the authentication and authorization
rules they have defined operate as expected and users are not locked out of computers they need access to but are prevented from logging on where they
don’t have access rights. The main goal of this stage is to execute a test plan that exercises software operations in a number of different use cases.
Roll-Out Deployment
After sufficient testing and verification of the pilot deployment, the deployment team can use a software delivery method to install Centrify Agent packages
on remote computers and join an Active Directory domain. Typically, the roll-out is done in phases, so that Centrify software is deployed on a set of
computers in one subnet, IP range, or administrative domain, then later deployed on another set of computers on a different subnet, with a different IP range,
or in a different administrative domain. The goal of this stage is to deploy in a controlled manner, so that any issues can be resolved before they affect
additional users or computers.
Ongoing Management and Evolution
As your environment changes and evolves, it is likely that you will want to refine, customize, and extend your deployment and your authentication,
authorization, computer, and user management policies. You may also develop or enhance scripts that automate provisioning and decommissioning of
accounts, or update business processes to take advantage of additional functionality, such as integration with other tools to capture Centrify data or
configuring database applications to use PAM-based authentication. The goal of this stage is continuous improvement to streamline business processes and
operational efficiency.
Preparing a Deployment Team
In large organizations, the network architecture and Active Directory infrastructure is often highly complex and sophisticated. Adding UNIX, Linux, and Mac
OS X computers and users to this infrastructure requires careful planning and is handled best with a clearly documented deployment plan. This guide is
intended to help you develop such a plan and to suggest the issues you should consider in designing a deployment that suits your organization. For an example
of what a deployment plan might look like, see Simplified environment analysis and zone design template.
Depending on the size of your organization, you might want to assemble a cross-functional deployment team to plan and implement a deployment strategy,
set up and test a pilot deployment program, and refine, document, and roll-out operations across the organization. In addition, a deployment team might
include project leads and IT staff members who will be responsible for maintaining and managing Server Suite and Active Directory on an ongoing basis after
deployment or developers who will extend or integrate applications to work with Server Suite and Active Directory.
A typical deployment team might consist of members in the following roles:
Active Directory Enterprise or Domain Administrators
Know the structure and trust relationships of one or more Active Directory forests, including the topology of the Active Directory site and the roles of the
domain controllers. These administrators may also be responsible for provisioning and decommissioning accounts or maintaining the tools for these
business processes.
UNIX Administrators or Administrators with Specific Expertise
Manage access for all or specific groups of UNIX, Linux, or Mac OS X computers. These administrators may be responsible for specific resources, such as the
servers that host mission-critical applications or a web farm, or have specific knowledge, such Oracle database administration or AIX administrative tools.
Security Administrators
Establish security policies and audit trails and define the procedures for securing computer resources and user account information. These administrators
may also define the provisioning rules for the organization or have detailed knowledge of the existing provisioning process.
IT or Network Architects
Understand the overall layout of the organization’s network, including internal connectivity and access to the Internet, firewalls, port usage, bandwidth and
latency issues.
Application Developers
Write programs that require authentication and authorization services. Application developers might also include UNIX programmers who will be responsible
for writing scripts to automate administrative tasks, such as creating zones or adding new users to a zone.
Functional Testers
Develop test cases for the user scenarios the deployment team wants to validate.
Centrify Administrative Operators
Use Access Manager and other consoles on Windows, UNIX command line programs, ADEdit library, or PowerShell scripts to manage users, groups,
computers, or zones. These operators might be delegated administrators for specific zones after deployment or existing Active Directory administrators who
add and remove users from groups or manage Active Directory containers.
Database Administrators
Install and manage database instances and control access to database records. If you are planning a deployment that includes auditing user activity, the
deployment team should include at least one database administrator to plan for and create the databases that will store captured sessions and audit meta-
data. A database administrator can also provide procedures and guidance for backing up, archiving, and removing historical data as appropriate for your
organization’s record retention policies.
Internal or External Auditors
Understand regulatory compliance requirements for the organization and industry. Auditors typically know the type of information they need and can define
the reports that will satisfy their needs.
Assembling a cross-functional team with members who have expertise in working with Active Directory and Windows architecture and members who have
expertise in managing UNIX, Linux, or Mac OS X servers and workstations is often a key component of a successful deployment.
Preparing Deployment Documentation
In addition to deploying the software, the deployment team should prepare materials that document the solutions they are deploying and the processes and
procedures to assist others in migrating. The deployment documentation might include training materials for new users and test plans to verify a successful
deployment that can be reused when updating the software after the initial deployment.
In general, members of the deployment team should focus on the following activities to prepare for a roll-out of Server Suite to a production environment:
Document the configuration settings you plan to use and update the documentation as needed based on the pilot experience. For example, during the
planning phase you might have drafted a plan for user and group filtering or access controls that in practice you find must be adjusted. The pilot
deployment gives you the opportunity to implement your planned solution but change it, if needed.
Document and prototype any deployment scripts that you intend to use and any processes or policy decisions that impact using those scripts. For
example, you might want to automate the join process or how new users are added to a zone or modify existing scripts that provision users.
Document issues that require troubleshooting during the pilot deployment and the resolution for each issue. You can collect this information as an
organization-specific operations manual for IT staff.
Prepare training materials for testers, operations personnel, and end-users based on the experience gained in the pilot deployment and tailored to your
organization’s specific needs and internal policies.
Prepare test plans that sufficiently cover the types of scenarios that are specific to your organization’s needs and internal policies. For example, if you
plan to use group policies, your test plans should include scenarios for testing the group policies you plan to implement.
Update planning documents, such as the zone structure or role definitions that you developed during the planning phase in response to the practical
experience gained in the pilot deployment.
Create checklists or instructions that are specific to your organization’s deployment. For example, you may want to create a “site preparation checklist”
that covers specific steps administrators should take before deploying, a “deployment checklist” that includes site-specific naming conventions and
migration instructions, and a “handoff to operations checklist” to ensure a smooth hand-over to data center staff after deployment is complete.
Defining Goals for the Deployment
One of the first tasks of the deployment team should be to define the goals you want to achieve and the criteria you will use to measure whether you have met
those goals. As part of this process, you should define:
The primary reason for deploying Centrify in your organization. For example, if providing centralized directory service or a single point of
account administration is your most important goal, you may make different deployment decisions than if auditing and restricting user access to
specific computers is your primary goal. That is, you want to be sure the deployment addresses your most pressing concerns first.
Priorities for any additional goals you want to set for the deployment. For example, you may want to transition to a rationalized namespace
over time, but this may be a lower priority for your organization than moving from decentralized computer administration to delegated administration of
the tasks users can perform on specific computers.
Any specific auditing requirements or security requirements that are unique to your organization or industry. For example, the way
you organize computers into groups may be determined by specific reports you need to produce.
Internal policies for how you update and distribute software. For example, you should define how frequently you apply operating system
patches and whether you automate software distribution.
Internal policies for how you assign UNIX attributes and Active Directory account information. For example, you should identify how
you have assigned UIDs, GIDs, and other UNIX-specific attributes and whether there are existing naming conventions for Active Directory users and
groups.
Plans for who will manage UNIX profiles after deployment. For example, you should identify the group or groups that will manage which UNIX
users and computers and whether there will be separate UNIX and Active Directory administrators with shared responsibilities or a clearly defined
division of responsibilities. In most cases, Centrify recommends a separation of duties model that enables UNIX administrators to manage zones and
Active Directory administrators to manage user objects and group membership.
Architecture and Basic Operations
This section provides an overview of the Server Suite architecture and the components for Windows and non-Windows computers. It also describes the basic
flow of operation when users log in or access applications, and what happens when an Active Directory domain controller goes down.
The information in this section is not required for planning a deployment. It is intended as background information that can help you understand the
authentication and authorization process in some detail. If you want to proceed directly to planning the deployment, you can skip this section.
Server Suite Platform-Specific Components
Server Suite provide an integration layer between Active Directory in a Windows environment and computers running other operating systems or application
environments. Because of this, Server Suite includes components for managing Active Directory-based objects in the Windows environment and agents that
run on each server or workstation to be integrated into Active Directory.
Server Suite Components for Windows
On Windows, Server Suite includes management consoles and services to simplify the management and integration of Linux and UNIX computers and users
into Active Directory.
The key components for Windows that you use in deployment are:
Access Manager console

Zone Provisioning Agent configuration panel and Windows service
There are several additional Windows components available for you to use, depending on the version of Server Suite software you install and the
requirements of your environment. For example, Server Suite offers extensions for working with NIS maps and Active Directory group policies, as well as
components to support a multi-tier architecture for auditing activity in user sessions and the Network Information Service to support agentless
authentication service.
Components Installed on Managed Computers
On non-Windows computers, Server Suite software consists of the core Server Suite Agent (adclient), related libraries, and optional tools. The Server Suite
Agent enables the local host computer—most commonly a Linux or UNIX computer—to join an Active Directory domain.
After the agent is deployed on a server or workstation, that computer is considered a managed computer and it can join any Active Directory domain you
choose.
When a Server Suite-managed computer joins an Active Directory domain, it essentially becomes an Active Directory client and relies on Active Directory to
provide authentication, authorization, policy management, and directory services. The interaction between the agent on the local computer and Active
Directory is similar to the interaction between a Windows workstation and its Active Directory domain controller, including failover to a backup domain
controller if the managed computer is unable to connect to its primary domain controller.
The following figure provides a simplified view of the integration between Windows and non-Windows computers through Server Suite software.
To use Microsoft Active Directory to centrally manage access across different platforms, you need to do the following:
Prepare the Active Directory environment by installing the Access Manager console on at least one Windows computer and using the Setup Wizard to
update the Active Directory forest.
Ensure each UNIX, Linux, or Mac OS X computer can communicate with an appropriate Active Directory domain controller through DNS.
Install the agent (adclient) on the UNIX, Linux, or Mac OS X computers that will be joining an Active Directory domain.
Run the join command and specify the Active Directory domain on each UNIX, Linux, or Mac OS X computers that needs to join an Active Directory
domain.
Use Active Directory Users and Computers or Access Manager to authorize access to the UNIX, Linux, and Mac OS X computers for specific users and
groups.
The next sections provide a more detailed discussion of the Server Suite architecture and a summary of what happens when a user logs on to a UNIX
computer that has joined the Active Directory domain.
Storing Server Suite Properties in Active Directory
The Active Directory schema defines the object classes that can be stored in Active Directory, and the attributes that each object class must have, plus any
additional attributes the object can have, and the object class that can be its parent. Schema definitions are also stored as objects in Active Directory. To
store UNIX-specific attributes within the Active Directory schema, the schema must be able to include the properties that are associated with a UNIX user or
group. For example, for a UNIX user, the schema needs to accommodate the following information fields:
UNIX user name

Password hash (optional)
Numeric user identifier (UID)
Primary group identifier (GID)
General information (GECOS)
Home directory
Default shell
Some of these information fields are similar to standard user class attributes in Active Directory. For example, the Active Directory Display Name
(displayName) attribute typically stores a user’s full name—the same information typically stored in the GECOS field in an /etc/passwd file on a UNIX
computer, so the displayName is used to define the contents of the GECOS field in a user’s UNIX profile. Depending on the Active Directory schema you have
installed, some of the information fields required for logging on to UNIX computers might not have an equivalent Active Directory attribute.
If you are using the default Active Directory schema, Server Suite stores UNIX-specific attributes in an Active Directory class under its own parent container
for zones. Server Suite then organizes the information about individual UNIX computers, users, and groups by zone.
If your organization has already deployed a Microsoft-supported set of UNIX schema extensions, such as those defined in the Windows Services for UNIX
(SFU) schema extension, you can store UNIX attributes in the fields defined by that schema as an alternative to using the zones container.
If you have deployed the RFC 2307-compliant Active Directory schema, you can store UNIX attributes in the fields defined by that schema and organized
into RFC 2307-compliant zones.
After you have installed Server Suite components on a Windows computer, the first time you open the Access Manager administrative console, a Setup
Wizard updates the Active Directory forest to include the Server Suite properties for UNIX attributes. You can then use Access Manager, the Active Directory
Users and Computers MMC snap-in, ADEdit commands, or PowerShell scripts to view and modify the UNIX properties for any user, group, or computer.
Note: For RFC 2307-compliant zones, the group name and UNIX name are stored in the same CN attribute. Therefore, if you change a group’s
name with its Active Directory Users and Computers’ property page, the UNIX name is changed in Access Manager as well.
Using Access Manager
Access Manager is the primary user interface for managing all of the Server Suite-specific information stored in Active Directory. With Access Manager, you
can:
Manage access to all of your UNIX, Linux, and Mac OS X computers.

Set and modify user and group properties for all of your UNIX, Linux, and Mac OS X users and groups.
Create and manage zones and zone properties to simplify the process of giving users access to specific computers and migrating UNIX user accounts
to Active Directory.
Add Active Directory users and groups to zones.
Import user and group information from local password and groups files or from NIS and NIS+ servers and domains.
Import and maintain network information from NIS maps such as netgroup, auto.master, and automount or create custom NIS maps.
Define and assign rights and roles that authorize or restrict access to specific computers and operations on managed computers.
You can also add other snap-ins to Access Manager or add Access Manager to another Microsoft management console snap-in. For example, you can add the
Active Directory Sites and Services and Active Directory Domains and Trusts snap-ins to Access Manager to consolidate management activity.
Allowing and Blocking Domains for Access Manager
You can configure Access Manager so that it can connect to trusted domains by setting the following registry key with a list of trusted domains and/or
forests. The type of key is REG_MULTI_SZ:
HKLM\SOFTWARE\Centrify\CIMS\AllowedTrusts
Configuring a list of domains this way can be particularly useful and faster when you have a large amount of domains. Enter each domain as a separate line in
the Registry Editor window.
For example, to specify a single domain:
acme.com
For example, to specify multiple domains:
acme.com
foo.com
To block access to domains, you use the IgnoreTrusts key: HKLM\SOFTWARE\Centrify\CIMS\AllowedTrusts.
Core Agent Components and Services
The Server Suite Agent makes a UNIX, Linux, or Mac OS X computer look and behave like a Windows computer to Active Directory. Once installed, the agent
performs the following key tasks:
Joins UNIX, Linux, or Mac OS X computers to an Active Directory domain.

Communicates with Active Directory to authenticate users logging on to the UNIX, Linux, or Mac OS X computer, and caches credentials for offline
access.
Enforces Active Directory authentication and password policies.
Extends Active Directory group policies to manage the configuration of UNIX users and computers.
Provides a Kerberos environment so that existing Kerberos applications work transparently with Active Directory.
Individual agents are platform-specific, but provide an integrated a set of services to extend Active Directory authentication, authorization, and directory
service to managed computers. The following figure provides a closer look at the services provided through the Server Suite Agent:
As this figure suggests, the agent typically includes the following core components:
The core component of the agent is the adclient process that handles all of the direct communication with Active Directory. The agent contacts Active
Directory when there are requests for authentication, authorization, directory assistance, or policy updates, and then passes valid credentials or other
requested information along to the programs or applications that need this information.
The core component of the agent is the adclient process that handles all of the direct communication with Active Directory. The agent contacts Active
Directory when there are requests for authentication, authorization, directory assistance, or policy updates, and then passes valid credentials or other
requested information along to the programs or applications that need this information.
The Centrify Pluggable Authentication Module, pam_centrifydc, enables any PAM-enabled program, such as ftpd, telnetd, login, and sshd, to
authenticate using Active Directory.
Note: For AIX and Mac OS X, the implementation is slightly different. For example, the agent for AIX can use PAM interfaces if you have configured
the computer to use PAM modules or the interfaces in the Loadable Authentication Module (LAM) to handle behavior that on other platforms is
done through PAM or NSS. Similarly, the agent for Mac OS X uses native interfaces where appropriate to provide services from Active Directory to
the local computer.
The Centrify NSS module is added to nsswitch.conf so that system look-up requests use the agent to look up and validate information using Active
Directory through LDAP.
The ADEdit Tcl application and procedure library and individual UNIX command line programs enable you to perform common
administrative tasks, such as join and leave the Active Directory domain or change user passwords for Active Directory accounts interactively or within
scripts to automate tasks.
The Server Suite-managed Kerberos environment generates a Kerberos configuration file (etc/krb5.conf) and a default key table (krb5.keytab)
file to enable your Kerberos-enabled applications to authenticate through Active Directory. These files are maintained by the agent and are updated to
reflect any changes in the Active Directory forest configuration.
The Server Suite local cache stores user credentials and other information for offline access and network efficiency.
In addition to these core components, the agent can also be extended with the additional software packages, including modified versions of programs such
as Kerberos command line tools, OpenSSH, OpenLDAP, and PuTTY utilities. Server Suite-enabled versions of these programs allow you to use Active
Directory accounts and Kerberos credentials for authentication, authorization, and policy enforcement services. Server Suite also provides authentication
modules that enable you to configure single sign-on for web and database applications, and specialized extensions such as the adnisd Network Information
Service, which enables you to publish information stored in Active Directory to NIS clients.
Key Operations Handled by the Adclient Process
The most important element in the agent is the adclient process. The adclient process runs as a single trusted service. This process is automatically added as
a boot service and is started whenever you reboot a managed computer. The adclient process handles all of the direct communication with Active Directory
and manages all of the operations provided through the other services.
The adclient process performs the following key tasks on managed computers:
Locates the appropriate domain controllers for the local computer based on the Active Directory forest and site topology published by the Windows DNS
server. If a domain controller becomes unavailable, the adclient process automatically locates the next available domain controller to ensure
uninterrupted service.
Provides Active Directory with credentials for the local computer account to verify the computer is a valid member of the domain.
Delivers and stores user credentials so that users can be authenticated by Active Directory and, once authenticated successfully, can sign on even if
the computer is disconnected from the network for mobile access or if Active Directory is unavailable.
Caches query responses and other information, including positive and negative search results, to reduce network traffic and the number of connections
to Active Directory and to ensure users can work uninterrupted and start new application sessions using their existing login credentials. All
communication with Active Directory is encrypted to ensure security, and you can manage the cache through configuration parameters or group policy.
Creates and maintains the Kerberos configuration and service ticket files to allow existing Kerberos-enabled applications to work with Active Directory
without any manual configuration.
Synchronizes the local computer’s time with the clock maintained by Active Directory to ensure the timestamp on Kerberos tickets issued by the KDC
are within a valid range.
Resets the password for the local computer account in Active Directory at a regular interval to maintain security for the account’s credentials.
Provides all the authentication, authorization, and directory look-up services retrieved from Active Directory to the other Server Suite Agent services,
such as the PAM service or the Apache authentication module.
How PAM Applications Work with Server Suite
Pluggable Authentication Modules (PAM) are a common mechanism for configuring authentication and authorization used by many UNIX programs and
applications. If a program or application uses PAM for authentication and authorization, the rules for authenticating the user are configured in either the PAM
configuration file, /etc/pam.conf or in application-specific files in the /etc/pam.d directory.
The Server Suite Agent for *NIX includes its own Pluggable Authentication Module (pam_centrifydc) that enables any application that uses PAM, such as
ftpd, telnetd, login, and Apache, to authenticate users through Active Directory. When you join a domain, the pam_centrifydc module is automatically placed
first in the PAM stack in systemauth, so that it takes precedence over other authentication modules.
The pam_centrifydc module is configured to work with adclient to provide a number of services, such as checking for password expiration, filtering for users
and groups, and creating the local home directory and default user profile files for new users. The services provided through the pam_centrifydc module can
be customized locally on a computer, modified through Active Directory group policy, or configured through a combination of local and Active Directory
settings.
Working in conjunction with the adclient process, the pam_centrifydc module provides the following services for PAM-enabled programs and applications:
Requests the PAM-enabled application to prompt for a password when appropriate and verifies whether the application-provided user name and
password are valid in Active Directory.
Checks whether the user’s password has expired in Active Directory. If the password has expired, the pam_centrifydc module prompts the user to
change the password, and forwards the new password to the adclient process, which communicates the change to Active Directory.
Queries the adclient process to determine whether any access control policies are applied. For example, the pam_centrifydc module uses the
information in the centrifydc.conf file to determine whether a local user attempting to log on is mapped to an Active Directory account, whether
specific users or groups have been granted or denied permission to log on to the local computer, or whether Active Directory authentication should be
ignored for a specific user or group.
Creates the local home directory and default user profile files for new users. The pam_centrifydc module uses skeleton files to set up the user
environment when new Active Directory users log on to a managed computer for the first time.
Most of these tasks are performed during a user login session as a series of requests and replies from the pam_centrifydc module to Active Directory through
the adclient process for those programs and applications that are configured to use PAM. Because PAM is the most common authentication service used by
UNIX programs and applications, the pam_centrifydc module is the most commonly used for a typical log-on session. For a more detailed description of a
typical log-on process, see What happens during the typical log-on process.
Note: The order in which identity stores are listed in the nsswitch.conf file does not influence authentication. Authentication and authorization
services are provided by Active Directory through the Server Suite Agent for *NIX and its PAM component, and by default, Active Directory is
always tried before any other sources. The order in which sources are checked is controlled through the PAM configuration settings, for example,
the lines defined in the pam.conf file. In general, you should not modify the PAM configuration because making changes to these settings can
compromise security or produce unexpected and undesirable results.
How NSS Configuration Works with Server Suite
The Name Service Switch (NSS) provides a mechanism for identifying sources of network information a computer should use, such as local password and
group files, NIS maps, NIS+ tables, LDAP, and DNS, and the order in which these sources should be consulted when looking up users, groups, host names, and
other information.
When you join a domain, the NSS configuration file, nsswitch.conf, is automatically updated to use the Server Suite Agent’s NSS module first. Using the
adclient process and the service library, the Server Suite NSS module accesses network information that’s stored in Active Directory through LDAP.
When a UNIX program or application needs to look up information, it checks the nsswitch.conf file and is directed to use the nss_centrifydc module. The
nss_centrifydc module directs the request to Active Directory through the adclient process. The adclient process provides the information retrieved from
Active Directory, then caches the information locally to ensure faster performance, reduce network traffic, and allow for disconnected operation.
Note: The order in which identity stores are listed in the nsswitch.conf file does not influence authentication. Authentication and authorization
services are provided by Active Directory through the Server Suite Agent and its PAM service, so Active Directory is always tried before any other
sources, regardless of what you have specified in the nsswitch.conf file. Instead, the nsswitch.conf file determines the sources to use in
responding to NSS queries such as getpwnam. In general, you should not modify this file because modifying the file can compromise security and
complicate auditing activity. In addition, you should not specify ldap as a source in any nsswitch.conf file where you have installed the Server Suite
Agent. Specifying ldap in the nsswitch.conf file can cause the system to crash.
How the Server Suite Agent Manages Kerberos Files
Kerberos is a network authentication protocol for client/server applications that uses encrypted tickets passed through a central Key Distribution Center to
verify the identity of a user or service requesting access. Because Kerberos is an industry standard and a secure network authentication mechanism, you may
already have UNIX programs and services that are configured to use it. To allow those existing Kerberized applications to work with Active Directory without
manual configuration, the adclient process automatically creates and maintains the Kerberos configuration file, krb5.conf, and the krb5.keytab service ticket
file to point Kerberos-enabled services and applications to the Key Distribution Center (KDC) in Active Directory when you join a domain.
The configuration file is initially created using information collected by probing DNS and Active Directory with the default domain set to the domain that the
computer has joined. Whenever a logon or ticket validation is performed with a domain that is not in the configuration file, the configuration file is updated so
that it includes the new domain. Although the adclient process can automatically update the file as needed, it does not destroy existing configuration entries
that you may have added by hand. Because of this, Server Suite Agents work seamlessly with existing Kerberos-enabled applications.
Note: The Authentication Service supports users defined in a Kerberos realm as long as the Kerberos domains or realms are resolvable by DNS.
Kerberos realm names are case sensitive, so be careful to check that the realm spelling and capitalization is correct. (Ref: CS-21846a )
What Happens During the Typical Log-on Process
The core Server Suite Agent for *NIX components work together to identify and authenticate the user any time a user logs on to a computer using any UNIX
command that requires the user to enter credentials. The following steps summarize the interaction to help you understand the process for a typical log on
request. The process is similar, though not identical, for UNIX commands that need to get information about the current user or group.
Note: The following steps focus on the operation of the agent rather than the interaction between the agent and Active Directory. In addition,
these steps are intended to provide a general understanding of the operations performed through the agent and do not provide a detailed analysis
of a typical log on session.
When a user starts the UNIX computer, the following takes place:
1. A login process starts and prompts the user to supply a user name.
2. The user responds by entering a valid local or Active Directory user name.
3. The login process, which is a PAM-enabled program, then reads the PAM configuration file, /etc/pam.conf, and determines that it should use the Server
Suite PAM service, pam_centrifydc, for identification.
4. The login process passes the login request and the user name to the Server Suite PAM service for processing.
5. The pam_centrifydc service checks the pam.allow.override parameter in the agent configuration file to see if the user name entered is an account that
should be authenticated locally.
If the user should be authenticated locally, the pam_centrifydc service passes the login request to the next PAM module specified in the PAM
configuration file, for example, to the local configuration file /etc/passwd.
If the user is not listed as an override account, the pam_centrifydc service continues with the login request and checks to see if the adclient
process is running, then passes the login request and user name to adclient.
6. The adclient process connects to Active Directory and queries the Active Directory domain controller to determine whether the user name included in
the request is a user who has access to computers in the current computer’s zone.
If the adclient process is unable to connect to Active Directory, it queries the local cache to determine whether the user name has been
successfully authenticated before.
If the user account does not have access to computers in the current zone or can’t be found in Active Directory or the local cache, the adclient
process checks the Server Suite Agent configuration file to see if the user name is mapped to a different Active Directory user account with the
adclient.mapuser.username parameter.
If the user name is mapped to another Active Directory account in the configuration file, the adclient process queries the Active Directory domain
controller or local cache to determine whether the mapped user name has access to computers in the current computer’s zone.
7. If the user has a UNIX profile for the current zone, the adclient process receives the zone-specific information for the user, such as the user’s UID, the
user’s local UNIX name, the user’s global Active Directory user name, the groups of which the user is a member, the user’s home directory, and the
user’s default shell.
8. The adclient process checks for NSS override settings (nss.group.override and nss.user.override) to determine whether there are any changes to the
user profile or additional restrictions that should override the profile retrieved or prevent the user from logging on.
9. The adclient process queries through the nss_centrifydc service to determine whether there’s another user currently logged in with same UID.
If there is a potential conflict between local user account and the UNIX profile for an Active Directory account, the adclient process notifies the
pam_centrifydc service of the potential conflict.
The pam_centrifydc service checks the Server Suite Agent configuration file to determine to issue a warning, ignore the conflict, or prevent the
user from logging on.
If the login continues, the pam_centrifydc service asks the login process for a password.
10. The login process prompts the user to provide a password and returns the password entered to the pam_centrifydc service.
11. The pam_centrifydc service checks the pam.allow.users and pam.deny.users parameters in the agent configuration file to see if any user filtering has
been specified to allow or deny access to specific user accounts. If any user filtering has been specified, the current user is either allowed to continue
with the login process or denied access.
12. The pam_centrifydc service checks the pam.allow.groups and pam.deny.groups parameters in the agent configuration file to see if any group filtering
has been specified to allow or deny access to members of specific groups. If any group filtering has been specified, the current user is either allowed to
continue with the login process or denied access based on group membership.
13. If the current user account is not prevented from logging on by user or group filtering, the pam_centrifydc service queries the adclient process to see if
the user is authorized to log on.
14. The adclient process queries the Active Directory domain controller through Kerberos to determine whether the user is authorized to log on to the
current computer at the current time.
15. The adclient process receives the results of its authorization request from Active Directory and passes the reply to the pam_centrifydc service.
16. The pam_centrifydc service does one of the following depending on the content of the authorization reply:
If the user is not authorized to use the current computer or to log in at the current time, the pam_centrifydc service denies the user’s request to
log on through the UNIX login process.
If the user’s password has expired, the pam_centrifydc service sends a request through the UNIX login process asking the user to change the
password. After the user supplies the password, the login process completes successfully.
If the user’s password is about to expire, the pam_centrifydc service notifies the user of impending expiration through the login process.
If the user is authorized to log on and has a current password, the login process completes successfully. If this is the first time the user has logged
on to the computer through the agent, the pam_centrifydc service creates a new home directory on the computer in the location specified in the
agent configuration file by the parameter pam.homeskel.dir.
The following figure provides a simplified view of a typical log-on process when using the Server Suite Agent for *NIX.
How Failover and Disconnected Access Work
The Server Suite Agent caches data from Active Directory so that users can log on and perform tasks even if the network or Active Directory server is
unavailable, whether because of unexpected connectivity problems, scheduled maintenance, or offline operation of a portable computer. There are several
configuration parameters that manage how the agent determines its connectivity to Active Directory, the domain controllers it should attempt to connect to,
and the operation of the agent if it is unable to connect to any domain controller.
In most cases, you can set the values for the configuration parameters that control failover and disconnected operation by enabling Server Suite group
policies for a site, domain, or organizational unit. Alternatively, you can set these parameters by editing the /etc/centrifydc/centrifydc.conf configuration file
on individual computers.
For an overview of how the agent determines the connection status and locates a domain controller to use, see the following topics:
Establishing a connection to DNS

Connecting to the closest domain controller
Restricting the domain controllers contacted
Switching to disconnected mode
Responding to DNS configuration changes
Connecting to trusted forests and domains
Establishing a Connection to DNS
With each request to Active Directory, the Server Suite Agent first determines its connection status based on upon the availability of a Domain Name Service
domain controller. If a DNS request for a host name takes longer than the number of seconds specified by the adclient.dns.response.maxtime parameter, the
agent assumes DNS is down and switches to disconnected mode.
While running in the disconnected mode, the agent does not attempt any more synchronous network communications. Instead, it runs a background thread
every 30 seconds to determine when DNS becomes available. The default value for the adclient.dns.response.maxtime is 10 seconds, but this value can be
changed by group policy or by editing the /etc/centrifydc/centrifydc.conf file.
Note: If the network is disconnected for a short period of time, but during that time no data is needed from Active Directory, the agent does not
switch into disconnected mode. The status only changes if a connection attempt to DNS or to Active Directory through LDAP fails.
Connecting to the Closest Domain Controller
If the initial DNS request for a host name is successful, the Server Suite Agent attempts to connect to the appropriate domain controller and global catalog
for its joined domain using the site information found in DNS.
Site information is configured using Active Directory Sites and Services and is defined by subnet. Using the site information, the agent queries DNS for a list
of the domain controllers in its site and attempts to connect to the nearest domain controller. It will continue trying to connect to each of the domain
controllers in its site based on proximity until it finds a server available. If the agent is unable to connect to any of the domain controllers in its site or if no site
information is available, the agent tries to connect to any remaining domain controllers listed in DNS.
Because connection status is determined by an attempt to bind to the Active Directory domain controller using an LDAP call, the adclient.ldap.socket.timeout
parameter determines the maximum number of seconds the Server Suite Agent will wait for a socket connection timeout while binding to the LDAP server.
The default value is 5 seconds.
Restricting the Domain Controllers Contacted
If you have a large Active Directory infrastructure or some unreliable subnets, you might want to restrict the domain controllers the agent should attempt to
connect to if its primary domain controller becomes unavailable. You can limit the list of domain controllers the agent should attempt to connect to by setting
the following property in the centrifydc.conf file:
dns.dc.domain_name: hostname [hostname] ...
where the domain_name is the Active Directory domain name and the hostname is a fully-qualified host name that can be resolved using DNS or the
/etc/hosts file.
You can also limit the list of global catalog domain controllers the agent should attempt to connect to by setting the following property in the centrifydc.conf
file:
dns.dc.forest_name: hostname [hostname] ...
where the forest_name is the forest root domain and the hostname is a fully-qualified host name that can be resolved using DNS or the /etc/hosts file.
Alternatively, you can use the adclient.server.try.max parameter or Maximum Server Connection Attempts group policy to limit the number of domain
controllers the agent will attempt to connect to before switching to disconnected mode, eliminating the need to explicitly list the domain controllers using the
dns.dc.domain_name and dns.gc.forest_name parameters. For example, to have the agent try a maximum of three domain controllers, you can set the
following property in the centrifydc.conf file:
adclient.server.try.max: 3
Because global catalog and domain controller connections are handled independently, Server Suite Agent for *NIX can still provide authentication services if
the global catalog domain controller is disconnected, as long as another domain controller is available.
Switching to Disconnected Mode
After a connection to a domain controller is established, each subsequent request for information from Active Directory checks the connection status. If a
request is made to Active Directory and a response is not received within the number of seconds specified by the adclient.ldap.timeout parameter, that
request is retried once. For the second request, the agent will wait up to twice as long for a response. If the second request is not answered within that amount
of time, the connection to that specific domain controller is considered disconnected. Once a connection to a specific domain controller is in disconnected
mode, a background thread will attempt to reconnect to that domain approximately every 30 seconds. By default, the agent waits 7 seconds for a response to
the first request. If the request isn’t answered, it retries the request and waits up to another 14 seconds for a response before switching to disconnected
mode.
The adclient.ldap.timeout parameter specifies the maximum number of seconds to wait for Active Directory fetch, update, and delete requests to improve
the response time when an initial connection attempt fails. A separate parameter, adclient.ldap.timeout.search, specifies the maximum time to wait for
search requests. If the search timeout value is not specified, the default is double the adclient.ldap.timeout value. By default, therefore, the agent waits a
maximum of 14 seconds for search requests.
The values for these parameters can be adjusted for high load or latency networks by configuring group policies or by editing the
/etc/centrifydc/centrifydc.conf file.
Responding to DNS Configuration Changes
The DNS information collected when the agent starts and connects to a domain controller is not cached, and idle connections to Active Directory are dropped
after 5 minutes by default. If you make changes in the DNS configuration, those changes are detected the next time the agent needs to reconnect, either
because an idle connection has been dropped, or the currently connected domain controller suddenly becoming unavailable.
Connecting to Trusted Forests and Domains
If the Server Suite Agent establishes a successful connection to the joined domain, it also generates or updates the /etc/krb5.conf file using the domain trust
information from the global catalog, and attempts to connect to the trusted domains or to external forests to find all of the domains that are trusted.
Depending on the trust relationships you have defined, network topology, or firewall requirements, querying external trusted forests can have a significant,
negative impact on network performance. You can control whether trusted domains and external forests are queried to establish transitive trusts and cross-
forest authentication with the adclient.ldap.trust.enabled parameter. Setting the adclient.ldap.trust.enabled parameter to true indicates that you want the
Server Suite Agent to query trusted domains and forests. Setting this parameter to false disables this feature so that the agent does not connect to any
external forests or trusted domains.
If you set the adclient.ldap.trust.enabled parameter to true, you can control the maximum number of seconds to wait when searching for trust information in
external forests and other trusted domains with the adclient.ldap.trust.timeout parameter. By default, the agent waits 10 seconds. The search operation is
not retried if the request times out, but the request is regenerated approximately once an hour.
If your trusted domains and forests are widely distributed, have slow or unreliable network connections, or are protected by firewalls, you might want to
increase the value for this parameter to allow time for the Server Suite Agent to collect information from external domains and forests.
Deployment Process Overview
This chapter summarizes what’s involved in deploying Centrify software. It includes simplified diagrams that highlight the steps involved and describes the
tasks that are done only once, the tasks that are repeated to complete a deployment, and the tasks that may be part of the deployment project or ongoing
administration after deployment.
The individual diagrams provide additional details about what’s involved in each phase or the decisions you will need to make, such as who should be part of
the deployment team, where to install the software, and who has permission to do what.
What’s Involved in a Typical Deployment Project
The following illustration provides a visual summary of the overall deployment process and highlights a few keys to a successful deployment.
The next sections provide additional details about each of these phases.
Plan
During the first phase of the deployment, you should collect and analyze details about your organization’s requirements and goals. You can then make
preliminary decisions about sizing, network communication, and what your zone structure should look like.
Here are the key steps involved:
Assemble a deployment team with Active Directory and UNIX expertise.
The team might also include specialists, such as database administrators, network architects, or application owners. For more information about
assembling a deployment team, see Preparing a deployment team.
Provide basic training so that members of the deployment team are familiar with Centrify concepts and terminology and know where to go for more
information.
Analyze the existing environment to determine your goals and requirements and identify target computers on which you plan to install Centrify
components.
This step is essential for designing the zone structure if you are migrating any local accounts or legacy profiles. It is also critical if you are deploying the
auditing infrastructure. For more information about the questions to answer and factors that affect deployment, see Defining goals for the deployment.
Design a basic zone structure that suits your organization.
The zone structure depends primarily on how you want to use zones. For more information about deciding how to use zones, see Why use zones?.
Identify a target set of computers for deployment and check that required ports are open.
Default Ports for Network Traffic and Communication
To help you plan for network traffic, the following ports are used in the initial set of network transactions when a user logs on and the agent connects to Active
Directory:
Directory Service - Global Catalog lookup request on port 3268.

Authentication Services - LDAP sealed request on port 389.
Kerberos – Ticket Granting Ticket (TGT) request on port 88.
Network Time Protocol (NTP) Server – Time synchronized for Kerberos on port 123.
Domain Name Service (DNS) – Host (A), Pointer (PTR), Service Location (SRV) records on port 53.
Depending on the specific components you deploy and operations performed, you might need to open additional ports. The following table summarizes the
ports used for different editions of Centrify software.
This
Is used for Where it is required
port
Encrypted TCP/UDP Centrify authentication service and privilege elevation service for Active Directory authentication and client
389
communication LDAP service.
Centrify authentication service and privilege elevation service for Active Directory authentication and LDAP
3268 Encrypted TCP communication
global catalog updates.
This
Is used for Where it is required
port
Centrify authentication service and privilege elevation service for Kerberos ticket validation and
88 Encrypted UDP communication
authentication for agents and Centrify PuTTY.
Encrypted TCP/UDP
Centrify authentication service and privilege elevation service for Kerberos ticket validation and
464 communication for Kerberos
authentication for agents, Centrify PuTTY, adpasswd, and passwd.
password changes
Centrify authentication service and privilege elevation service for clients using the Active Directory DNS server
53 TCP/UDP communication
role for DNS lookup requests.
Encrypted TCP/UDP
Centrify authentication service and privilege elevation service for adclient and adgpupdate using Samba
445 communication for delivery of
(SMB) and Windows file sharing to download and update group policies, if applicable.
group policies
UDP communication for simple Centrify authentication service and privilege elevation service to keep time synchronized between clients and
123
network time protocol (NTP) Active Directory for Kerberos ticketing.
Encrypted TCP communication for Centrify authentication service and privilege elevation service to support secure shell connections on remote
22
OpenSSH connections clients.
Centrify authentication service and privilege elevation service to support telnet connections on remote clients
TCP communication for Telnet
23 if you cannot use secure shell (ssh). By default, telnet connections are not allowed because passwords are
connections
transferred over the network as plain text.
Centrify authentication service and privilege elevation service to determine whether if a remote computer is
none ICMP (ping) connections
reachable.
Encrypted TCP communication for

Centrify authentication service, privilege elevation service, and audit and monitoring service to enable the
1433 the collector connection to
collector service to send audited activity to the database.
Microsoft SQL Server
Encrypted TCP/RPC
Centrify authentication service, privilege elevation service, and audit and monitoring service to enable the
5063 communication for the agent
auditing service to record user activity on an audited computer.
connection to collectors
Cloud proxy server to Centrify

443 Centrify for mobile device management.
cloud service
Network Connections and Database Management for Auditing
If you are planning a deployment with audit and monitoring service installed together with identity and privilege management, you must plan for reliable, high-
speed network connections between components that collect and transfer audit data and how network traffic will be affected. You must also plan how you
will create and manage the databases that store and retrieve audit data, your data archiving and retention policies, auditor permissions, and other details. For
more information about planning and sizing for audit and monitoring service, see the Auditing Administrator’s Guide.
Prepare
After you have analyzed the environment, you should prepare the Active Directory organizational units and groups to use. You can then install administrative
consoles and prepare initial zones.
Create organizational units or containers to define a scope of authority.
For example, if you want to organize all of the UNIX-related information together for your organization, you can create one top-level container for the
enterprise, such as Centrify UNIX. If you want to define the scope of authority at a regional or business unit level, you might have separate top-level
containers for the different regions or business units, for example, UNIX NA-SA, UNIX EMEA, UNIX PACIFIC or UNIX-Federal, UNIX-Consumer, UNIX-
Industrial.
The deployment project team should consult with the Active Directory enterprise administrator to determine the appropriate top-level containers or
organizational units and who should be responsible for managing and delegating administrative tasks for the objects in those top-level containers. For
more information about creating organizational units or containers in Active Directory, see Designing organizational units for Centrify.
Create the appropriate Active Directory security groups for your organization.
Groups can simplify permission management and the separation of duties security model. For more information about using groups, see Security
groups to manage Centrify information.
Select at least one administrative Windows computer and install Centrify components Access Manager.
This step is not strictly required if you only use existing processes or scripts to perform administrative tasks, but Centrify recommends you have at least
one computer where you can use the graphical user interface to perform common tasks. If you are deploying the audit and monitoring service
infrastructure, you should also install Audit Manager and Audit Analyzer. For more information about installing Centrify software on Windows, see
Installing Authentication & Privilege Services.
Start the Centrify Access Manager console to run the Setup Wizard for the Active Directory domain.
Create a parent zone and the appropriate child zones as identified in your basic zone design.
The hierarchical zone structure you use depends primarily on how you want to use inheritance and overrides. For more information about creating
parent and child zones, see Creating the first zone.
Determine the target set of computers and make sure that they have the appropriate connectivity.
Deploy
After you have prepared Active Directory, installed administrative consoles on at least one computer, and created at least one zone, you are ready to deploy
on the computers to be managed.
Download agent software from the Centrify Download Center or a network location.
Deploy the agent software on discovered computers that are ready for installation.
Determine whether there are any local accounts to migrate.
Right-click discovered computers, then click Export Users and Groups to generate a text file containing information about local accounts. Review
the text file to determine whether there are any local accounts to migrate to Active Directory.
If there are local accounts that must be able to log on to the discovered computer, import the groups, then users and assign them the default UNIX Login
role. For more information about migrating local accounts, see Migrating existing users to hierarchical zones.
Join the domain using the adjoin command.
Prepare basic group policies.
The most common Windows computer configuration policies to deploy are:
Interactive Logon: Message text for users attempting to log on:—Enable and type a message that instructs the user to log on with an Active
Directory user name and password.
Global Configuration Settings - MaxPollInterval:—Enable and set an interval if you are using Active Directory and the Centrify network time
provider. Disable if you are using a native UNIX NTP daemon.
Enable Windows NTP Client—Enable if you are using Active Directory and the Centrify network time provider. Disable if you are using a native UNIX
NTP daemon.
The most common Centrify computer configuration policies to deploy are:
Set login password prompt—Enable and type a message that instructs the user to log on with an Active Directory user name and password.
Copy files—Enable to copy configuration files such as those required by autofs or sshd from the SYSVOL folder to managed computers.
Generate forwardable tickets—Disable to prevent logon tickets from being sent from one computer to another.
Validate
After you have deployed agents on target computers, you should test and verify operations before deploying on the additional computers.
Log on to a target computer using an Active Directory user account and password to verify Active Directory authentication.
Test password policy enforcement by attempting to change to a password that violates password complexity rules.
Test account lockout and reset.
Manage
After you have verified the successful deployment on target computers, there are many ways you can refine, manage, and enhance on-going operations.
Here are a few of the key ways you can add value after deployment:
Add custom roles and role assignments for users, groups, and computers.
Import custom permissions from sudoers configuration files.
Deploy group policies on the appropriate organizational units.
Add the auditing infrastructure and add auditing to custom roles.
Integrate Centrify software and Active Directory authentication and authorization services with database or web applications.
Deployment Tasks and Administrative Activity
For most deployments, there are tasks that you only perform once for an entire organization, tasks that are repeated until the deployment in complete, and
tasks that are essential to deployment, but are also administrative tasks that you perform infrequently or periodically after deployment.
Steps You Only Take Once
In most organizations, you only perform the following tasks once in preparation for the deployment:
Assemble a deployment team with Active Directory, UNIX, and other expertise.
Provide basic training covering Centrify architecture, concepts, and terminology.
Analyze the existing environment:
Find a target set of computers that share a common attribute, such as the same operating system or a similar user population.
Plan for permissions and the appropriate separation of duties for your organization.
Review network connections, ports, firewall configuration.
Identify computers for administration.
Basic deployment—Access Manager
Auditing—Audit Manager and Audit Analyzer consoles, collectors, audit databases and servers, and the installation management server
Provisioning service—Zone Provisioning Agent and configuration tool
Single or multiple top-level parents.

Initial child zones, for example separate zones for Red Hat Linux and Mac OS X or different functional departments.
Create organizational units or containers to define a scope of authority within Active Directory.
Create Active Directory security groups for the UNIX Login role and the listed role.
Create an Active Directory distribution group for provisioning groups and an Active Directory distribution group for provisioning users if using the
provisioning service.
Install Access Manager on at least one administrative Windows computer.
Open Access Manager for the first time to run the Setup Wizard for the Active Directory domain.
Creating additional zones is an infrequent administrative task that is performed when the need arises. The basic zone design should be sufficient for the
scope of your initial deployment.
Prepare group policies to be applied.
Steps You Take More than Once During Deployment
During deployment, you perform the following tasks multiple times until you have rolled out the agent to all of the target computers that are in scope for the
deployment:
Download agent software from the Centrify Download Center or a network location.
Deploy the agent software on computers that are ready for installation.
If there are local accounts to migrate that must be able to log on to the discovered computer:
Import the groups, then users.
Map groups, then users to the appropriate Active Directory groups and users.
Assign migrated accounts the default UNIX Login role.
Join the domain using the adjoin command.
Verify Active Directory authentication and validate other operations.
After deployment, deploying new or updated agents is an ongoing administrative task that should be performed on a regular basis unless you have change
control issues that either prevent software updates, do not allow Internet connections from the computer where Access Manager is installed, or do not want
to deploy the agent on computers added to your network.
Steps You Take After Deployment to Begin Managing Zones Effectively
After you have migrated existing user populations, deployed the agent, and joined a domain, there are additional tasks you perform to complete the
deployment and transition into effective zone administration.
The following tasks are optional but illustrate common administrative tasks that are often part of the deployment process to prepare for ongoing
administration and improvements to operational security and efficiency:
Create custom roles for accounts that have permission to run privileged commands.
Create computer roles to link groups of computers with specific user role assignments.
Map service accounts to Active Directory accounts.
Deploy the basic set of group policies for computers and users.
What Happens After Deployment?
After deployment, ongoing management of UNIX computers, users, and groups is often handed off to Active Directory or Windows administrators or an
internal service desk provisioning team to align with previously established processes and procedures for Windows servers and workstations. This is entirely
a matter of organizational policy. However, in many cases UNIX administrators must continue to work with their Windows counterparts to ensure the
appropriate rights and roles are assigned and the appropriate group policies are deployed.
Sample Workflow for Deployment Decisions
Centrify software solutions are extremely flexible so that they can be adapted to a wide variety of organizational requirements. All of this flexibility, however,
can make deployment decisions difficult, especially in large scale or complex environments. To help you sort out the questions to ask, use the following work
flow and responsibilities diagram as a guide.
This sample workflow diagram is only intended as a visual guide to the key design decisions you need to make. Many of these topics are covered in more detail
in other chapters in this guide. For many organizations, however, the best guidance comes from an on-site Centrify Professional Services consultant or a
Centrify partner with experience designing deployment solutions tailored to your organization’s business requirements. For customized help and advice,
contact your Centrify sales representative.
Planning Organizational Units and Security Groups
One of the important steps in planning a successful deployment of Server Suite is to consider how the software fits into your Active Directory infrastructure.
This section describes the issues you should consider in the planning phase that affect how Active Directory and Centrify-specific objects are organized and
suggests an organizational model you can use to successfully deploy Centrify within an existing Active Directory infrastructure.
If you are planning a deployment for managing and monitoring access to Windows computers, only Licenses and Zones parent containers is applicable and
you can skip the other topics in this section. If you are planning a deployment that includes a mix of different platforms, however, you should review the
recommendations for using organizational units (OUs) and groups.
If you plan to audit activity on any platform, Centrify recommends creating separate Active Directory security groups for auditors, administrators, and the
computers that make up the audit and monitoring service infrastructure. Planning a deployment that includes the audit and monitoring service infrastructure
requires additional resources and expertise. For more information about deploying auditing components, see the Auditing Administrator’s Guide.
Identifying Stakeholders and Business Processes
Deploying Server Suite requires you to add objects to the Active Directory forest and, in most cases, update business processes for provisioning and
removing users. It is important to identify who will be affected, which processes will be updated, how planned changes affect different parts of the business,
and when you plan to deploy as early as possible in the planning stage.
It is also important to contact one or more Active Directory administrators to establish who will be creating the necessary objects in Active Directory and
communicate the permissions required to create and manage those objects. If internal policies only allow Active Directory administrators to create
organizational units (OUs) or security groups, you may need to negotiate when those activities take place and who will own the objects after they are created.
Identifying the appropriate people and processes early in the project helps eliminate unnecessary delays to the deployment and adoption of Centrify
software. Communicating how the deployment affects the user and administrative communities helps ensure you can deploy rapidly and complete the
project on-time.
Note: The single biggest obstacle to storing UNIX data in Active Directory is overcoming internal process issues, such as change control
restrictions, naming convention requirements, or proper authorization to perform administrative tasks. If you identify and resolve these
challenges at the start of the project, deploying Centrify software across the enterprise becomes a fairly straightforward and painless task.
If you are a UNIX administrator, keep in mind that changes to Active Directory often require a formal change request and approval process, which can take
time and delay the project. The earlier you begin planning the changes to Active Directory and the appropriate separation of duties for managing UNIX objects
before, during, and after migration, the more successful the deployment will be.
Designing Organizational Units for Centrify
You can store Centrify-specific objects anywhere in the Active Directory structure if you choose. However, Centrify recommends that you create a single,
high-level organizational unit (OU) specifically for Centrify objects at or near the top-level of an Active Directory forest root domain. Using one high-level
organizational unit simplifies the management of Centrify containers and UNIX data.
Consolidating all UNIX data under a single organizational unit also enables you to establish an appropriate separation of duties without affecting any other
previously-established OUs or permissions in Active Directory and reduces the need for additional process documentation or training. The disadvantage is
that there may be strict authorization policies against setting up new organizational units.
Selecting a Location for the Top-Level OU
If you plan to follow the Centrify recommendation to create a top-level organizational unit for Centrify-related objects, such as Linux and UNIX computers,
this high-level OU should be named so that it is easy to identify. For example, name the OU Centrify or Centrify UNIX. In deciding where this top-level OU
should be placed, you should review your current Active Directory infrastructure.
There are several common scenarios:
Single forest with a single domain

Single forest with an empty root domain
Single forest with account and resource domains
Multiple forests with trust relationships
Forests separated by a firewall (DMZ)
Single Forest with a Single Domain
If you have a single forest with a single Default-First-Site domain, you can create the top-level OU fat the same level as the default containers for Computers,
Users, and other top-level objects. This is the simplest implementation of an Active Directory infrastructure. In this scenario, the top-level Centrify OU might
look similar to this:
Single Forest with an Empty Root Domain
In this scenario, the forest root domain is used for the DNS namespace with one or more child domains that store information about computers, users, and
groups. This is the most common Active Directory implementation. There are two important considerations if this is your Active Directory infrastructure:
It is likely you will have a disjointed DNS namespace that you will need to resolve when you join computers to the domain.
You might want to use multiple top-level Centrify OUs for the site. For example, assume the empty forest root domain, sidebet.org, contains three child
domains:
us.sidebet.org
europe.sidebet.org
asia.sidebet.org
In this scenario, you might have a top-level Centrify OU in each child domain that includes UNIX computers to allow for more efficient data management
and delegation of administrative tasks. However, if the child domains are centrally managed, you might want to create a single OU for Centrify in the
forest root or one of the child domains. In general, you should base your decision on who will be responsible for managing the Centrify objects. If there
are separate administrative groups for each child domain, create a top-level Centrify OU in each child domain.
Single Forest with Account and Resource Domains
In this scenario, the forest root domain has at least two child domains. One child domain stores computer principals and related information. This domain is
the resource domain. Another child domain stores the user and group principals. This domain is the account domain. This scenario requires a trust
relationship that allows the computers in the resource domain to trust the users and groups in the account domain. If this is your Active Directory
infrastructure, you should store the Centrify data in the resource domain. For example, if the root domain, sidebet.org, contains the child domains
accounts.sidebet.org and resources.sidebet.org, you would define the top-level Centrify OU in the resources.sidebet.org
(OU=Acme,DC=resources,DC=sidebet,DC=org).
Multiple forests with Trust Relationships
In this scenario, you have more than one forest needing access to Centrify data. If you have multiple forests in your organizations, you should create the top-
level OU for Centrify in the forests that have UNIX computers. The forests must also be configured with either a one-way or two-way trust relationship. Cross-
forest authentication requires a forest functional level of Windows Server 2003 or later. Trust relationships that involve Windows NT 4.0 domains or Kerberos
V5 realms are not supported.
Cross-forest Authentication for Two-way Trust Relationships
For forests that have a two-way trust relationship, users from either forest can be authenticated to log on to the other forest. For example, if you have
configured a two-way trust relationship between the forest root domain sidebet.org and youbet.org, and there are both UNIX computers and UNIX users in
both forests, you would create one top-level Centrify OU in each forest and users from either forest can be authenticated to the computers in either forest.
Cross-forest Authentication for One-way Trust Relationships
To allow for cross-forest authentication with a one-way trust, Centrify authenticates users in the trusted “accounts” forest to allow those users to log on to
computers in the “resources” forest. Users in the trusting “resources” forest cannot log on to computers in the “accounts” forest.
For cross-forest authentication with a one-way trust, when you add the user from the “account” forest to the Centrify zone, the user’s samAccountName
attribute is stored in the zone object. Therefore, once the user is added to the zone, their samAccountName cannot change without causing authentication to
fail.
Analyzing Trust Relationship to Prevent Authentication Failures
If your Active Directory environment does not permit one- or two-way trusts between forests, however, or uses a complex combination of one-way and two-
way trust relationships between forests, users who attempt to log on from a remote forest may be denied access if the forest they are logging on to or the
forest they are logging in from do not share a trust relationship.
As part of your deployment planning you should review your entire Active Directory infrastructure and determine whether you will be authenticating users
from multiple forests and how trust relationships are defined for the forests users need access to. You may want to change the trust relationships you have
defined.
For information about configuring trust relationships, see your Active Directory documentation.
Forests separated by a firewall (DMZ)
If you have a firewall between a forest outside of the firewall (the perimeter or DMZ forest) and a protected forest inside the firewall (the internal or
corporate forest), the best security practice is to make the DMZ a separate forest with no trust relationship.
In this scenario, the top-level Centrify OU is created in the corporate forest protected by the firewall. This configuration ensures that the domain controllers
in the perimeter forest cannot compromise the corporate domain controllers or get access to the corporate global catalog (GC), which stores information
about all domains in the forest. Although defining no trust relationship between the perimeter forest and the corporate forest is considered the best practice
for security reasons, this configuration prevents authentication through the firewall.
If you want to enable authentication for users in the corporate forest and allow them to access resources in the perimeter forest, Centrify recommends that
you create a separate Active Directory forest for the computers to be placed in the network segment you are going to use as the demilitarized zone. You
should then establish a one-way outgoing trust from the internal forest to the DMZ forest. For more information about deploying Centrify in a DMZ, see
Planning to deploy in a demilitarized zone (DMZ).
Creating Recommended Organizational Units
In addition to the top-level Centrify OU, Centrify recommends you create several additional organizational units for managing UNIX groups, users, and
computer accounts and rights and roles. These additional organizational units are intended to help you establish an appropriate separation of duties before,
during, and after migration.
Centrify recommends the following organizational units as a starting point:
Centrify Administration
Computer Roles
Computers
Provisioning Groups
Service Accounts
UNIX Groups
User Roles
Creating Organizational Units In Access Manager
If you want to create the recommended organizational unit structure for Centrify objects during your initial deployment, you can do so automatically using the
Access Manager Setup Wizard. The first time you start Access Manager, it opens the Setup Wizard by default. From the Setup Wizard, you can create all of
the containers for the recommended deployment structure automatically without any manual configuration. Alternatively, you can create a completely
custom deployment structure by first creating a PowerShell script that creates the containers you want to use then running the custom script from within the
Setup Wizard.
If you use the default script, the wizard adds the recommended organizational units and groups under the top-level Centrify OU and ensures all of the
permissions are properly set on the objects within it. You can then select an existing organizational unit or create a new organizational unit for the
components of the deployment structure. If you use the default deployment script without modification, it creates a structure like this:
If you want to customize the script, you can use the wizard to export it. After exporting the script, you can modify it in a text editor, then restart the wizard to
use the modified script. The Setup Wizard will also create the parent container for Licenses and the parent container for Zones in the Active Directory
location you select.
As you roll-out the deployment, you might find additional OUs are useful. For example, you might create additional OUs because specific permissions must be
granted to create, modify, delete, and manage the objects within them. By creating this organizational structure, you can control who has permission to
manage the Centrify objects contained in each OU.
By using the recommended deployment structure and associated permissions, you will have a solid foundation for deploying Centrify software across the
enterprise without affecting any of your existing Active Directory structure. The recommended deployment structure will also enable you to easily apply
group policies and manage user, group, and computer accounts.
For more information about the purpose of the additional organizational units, see the appropriate section.
Centrify Administration Organizational Unit
The Centrify Administration OU is intended to store Active Directory security groups that ensure the separation of duties and the segregation of Centrify-
related administrative operations in Active Directory.
In most cases, you will want to allow your existing Active Directory account fulfillment or provisioning team to edit UNIX groups and, potentially, the user role
groups that allow for elevated permissions in UNIX. If users you have identified as Centrify Administrators are stored in the same organizational unit as the
rest of the UNIX groups, then members of the fulfillment or provisioning team could grant themselves permissions to create, modify, and delete zones. With
these permissions, a disgruntled provisioning staff member could delete one or more zones and prevent access to production computers. To prevent this
security risk, Centrify recommends you create a separate Centrify Administration organizational unit and protect access to it.
Computer Roles Organizational Unit
The Computer Roles OU is intended to store the computer group accounts that are associated with a specific computer role. For example, if you plan to have
a computer role for computers that host Oracle databases and the set of users assigned the database administrator role, you might create an Active
Directory security group called Oracle_Production_Computers in this OU for the computers that host Oracle databases. If you were to add a new Oracle
database instance, you would add the computer account for that database server to the Oracle_Production_Computers in this OU.
In most cases, the computer groups in this organizational unit are associated with the user role groups you add to the User Roles OU. For example, if you have
a computer role for computers that host Oracle databases, you might have user role groups for database administrators and another user role group for
database users. If you were to change who should be allowed to use the database or perform database administration activities, you would modify the
membership of these two user role groups.
Computers Organizational Unit
The Servers OU is intended to store new computer principals in Active Directory. This organizational unit enables you to efficiently deliver computer-based
group policies from Active Directory. For example, you can use a group policy to turn off SNTP updates from Active Directory for Centrify-managed
computers to prevent those computers from having two registered time sources. Having a separate OU also enables you control who has the permissions and
authority to create, update, and delete computer objects in the domain.
Provisioning Groups Organizational Unit
The Provisioning Groups OU is intended to store Active Directory distribution groups that are used by the Zone Provisioning Agent. The Zone Provisioning
Agent is a Windows service that processes the business rules for creating or deleting UNIX profiles in zones. For example, if a new Active Directory user
principal is in one of these group principals, and the group is associated with a zone, the user is automatically provisioned with a UID and a GID in that zone.
Note: The profile does not allow the user to log on to computers in the zone. Identity management is separate from access management. The
user’s role assignments control access.
During the migration process, users you have identified as Centrify Administrators should have the appropriate permissions and authority to create, delete,
and manage the membership of these Active Directory distribution groups. After migration, the team that owns the process for the provisioning UNIX
accounts will need the same permissions and authority. For details about the permissions required to perform these tasks, see Setting permissions for zone
groups.
Service Accounts Organizational Unit
The Service Accounts OU is intended to store the Windows service account for the Zone Provisioning Agent and any UNIX-specific service accounts that do
not correlate to existing Active Directory user accounts. For example, you can use this OU for application service accounts, such as Oracle or MySQL, to
enable centralized password management and auditing. By migrating service accounts from UNIX, you can centrally manage the account information,
passwords, and privileges for those service accounts and their associated UNIX groups.
Unix Groups Organizational Unit
In this deployment model, the UNIX Groups OU is intended to store Active Directory security groups that are migrated from /etc/group files or NIS group maps
that you want to preserve.
As part of the initial migration, you should identify one or more users as Centrify Administrators who should be granted the appropriate permissions and
the authority to create new Active Directory group principals, and to add Active Directory user principals to the new groups.
After the migration is complete, another team might be responsible for managing the UNIX groups migrated into Active Directory. The team that owns the
process for adding UNIX users to a UNIX group, removing UNIX users from a UNIX group, or creating new UNIX groups will need the permissions and the
authority in Active Directory to create and delete group principals and manage the membership of those group principals in this OU (for example, ou=unix
groups,ou=Centrify). For details about the permissions required to perform these tasks, see Setting permissions for zone groups.
User Roles Organizational Unit
The User Roles OU is intended to store Active Directory security groups that are associated with user role definitions that grant privileges or restrict access.
For example, a user role definition might grant permission to execute commands as root or using a service account such as oracle. By associating an Active
Directory group with a role definition, you can grant or deny privileges by managing Active Directory group membership.
During the migration process, users you have identified as Centrify Administrators should have the permissions and the authority to add users to the
appropriate user role groups and to create new Active Directory group objects in the OU (for example, ou=user roles,ou=Centrify). After migration, your
organization should decide who should be responsible for creating new user role groups and associating them with zones and who should be able to add and
remove users from the User Roles organizational unit.
Licenses And Zones Parent Containers
Regardless of whether you choose to create the organizational units for the recommended deployment structure or a custom deployment structure, Centrify
requires the following parent containers:
Licenses parent container object for license keys. You must have at least one parent container for license keys in the forest. You can create more than
one of these container objects to give you more granular control over who has access to which licenses.
Zones parent container object for individual zone (ZoneName) objects. You must have at least one parent container for zones. You can create more
than one parent Zones container to give you more granularity for delegating administrative tasks.
You can select the parent containers for Licenses and Zones when you run the Setup Wizard, when creating a new zone, or when managing licenses in Access
Manager.
Some organizations prefer to create and manage Active Directory objects manually to ensure tight control over the objects and their attributes. For example,
you might want to manually create separate parent containers for different business departments or locations if you want to manually set permissions and
refine who has access to them. However, managing permissions manually can be complex and error-prone. In most cases, Centrify recommends that you
establish appropriate permissions on the deployment structure and use the Zone Delegation Wizard to manage administrative permissions on individual
zones and the objects contained in zones.
Security Groups To Manage Centrify Information
If you use the default recommended deployment script, the script automatically creates the following Active Directory security groups for managing
Centrify-related objects:
CentrifyAdministrators
AuthorizationManagers
ComputerManagers
UnixDataManagers
Each security groups is granted the appropriate permissions to perform specific administrative tasks. For example, users who are members of the Centrify
Administrators group should be able to create, modify, and delete zones.
If you are not using the recommended deployment script, you should create similar security groups for managing Centrify-related objects.
Delegating Control For Centrify Administrators
The CentrifyAdministrators security group is intended for members of the administrative or security team who are responsible for managing all Centrify-
related information stored in Active Directory. You should add members to the group to grant specific users the rights required to manage Centrify licenses,
zones, user roles, computer roles, provisioning groups, and the user, group, and computer profiles in each zone.
Members of the Centrify Administrators security group are responsible for identifying an organization’s zone requirements and creating the zone hierarchy.
Centrify Administrators also decide when to create new zones, delete obsolete zones, or consolidate existing zones. In most cases, Centrify Administrators
define the basic access rights for zones and delegate administrative tasks to other users and groups on a zone-by-zone basis.
Permissions for the Centrify Administrators group are applied at the top-level of the deployment structure—for example, ou=Centrify—and grant privileges
on the organizational units, containers, and object within the deployment structure. If you don’t create this group or a similar security group, only members of
the Domain Admins group can create new zones.
If you are managing security and individual permissions manually for Active Directory objects, see Permissions required for administrative tasks for
information about the permissions required for individual tasks.
Delegating Control For Authorization Managers
The AuthorizationManagers security group is intended for members of the security team who are responsible for managing role-based access rights. You
should add members to the group to grant specific users the rights required to manage user roles, computer roles, access privileges, and role assignments.
You can delegate tasks to the AuthorizationManagers group on the User Roles and Computer Roles organizational units using Active Directory Users and
Computers. You can delegate zone administration tasks to the group in Access Manager.
Delegating Tasks For User Role Groups
In Active Directory Users and Computers, select the User Roles organizational unit, right-click, then select Delegate Control to start the Delegation of Control
Wizard. Select the security group you are using for authorization managers and delegate the following tasks:
Create, delete and manage groups

Modify the membership of a group
Delegating Tasks For Computer Role Groups
In Active Directory Users and Computers, select the User Roles organizational unit, right-click, then select Delegate Control to start the Delegation of Control
Wizard. Select the security group you are using for authorization managers and delegate the following tasks:
Create, delete and manage groups

Delegating Zone-specific Tasks
As a member of the CentrifyAdministrators security group, you can grant zone-specific permissions to the members of the AuthorizationManagers group.
After you have created the appropriate zones, you can delegate the following zone administration tasks to authorization managers:
Manage roles and rights

Manage role assignments
Modify computer roles
Add computer roles
Delegating Control For Computer Managers
The ComputerManagers security group is intended for members of the UNIX administration team who are responsible for managing computer accounts. You
should add members to this security group to grant specific users the rights required to manage computer objects in the Servers organizational unit in Active
Directory.
As a member of the CentrifyAdministrators security group, you can also grant zone-specific permissions to the members of the ComputerManagers group.
After you have created the appropriate zones, you can delegate the following zone administration tasks to computer managers:
Join computers to the zone

Remove computers from the zone
If you are managing security and individual permissions manually for Active Directory objects, see Permissions required for administrative tasks for
information about the permissions required for individual tasks.
Delegating Control For Unix Data Managers
The UnixDataManagers security group is intended for members of the UNIX administration team who are responsible for managing computer accounts. You
should add members to this security group to grant specific users the rights required to manage UNIX users and groups objects in the UNIX groups and
Service Accounts organizational units in Active Directory.
You can delegate tasks to the UnixDataManagers group on the UNIX Groups and Service Accounts organizational units using Active Directory Users and
Computers. You can delegate zone administration tasks to the group in Access Manager.
Delegating Tasks For Unix Groups
In Active Directory Users and Computers, select the UNIX Groups organizational unit, right-click, then select Delegate Control to start the Delegation of
Control Wizard. Select the security group you are using for UNIX data managers and delegate the following tasks:
Create, delete, and manage groups

Delegating Tasks For Service Accounts
In Active Directory Users and Computers, select the Service Accounts organizational unit, right-click, then select Delegate Control to start the Delegation of
Control Wizard. Select the security group you are using for UNIX data managers and delegate the following tasks:
Create, delete, and manage user accounts

Reset user passwords and force password change at next logon
Delegating Zone-Specific Tasks
As a member of the CentrifyAdministrators security group, you can also grant zone-specific permissions to the members of the UnixDataManagers group.
After you have created the appropriate zones, you can delegate the following zone administration tasks to UNIX data managers:
Add users
Add groups
Remove users
Remove groups
Modify user profiles
Modify group profiles
Planning for Data Storage in Active Directory
Centrify stores all of the UNIX attributes required for users, groups, and computers in Active Directory, so that this information can be centrally managed. It
stores these attributes without requiring you to make any modifications to the Active Directory schema you choose to use.
Changing The Zone Type
If you create a new zone using the default zone options, the new zone is created as a hierarchical zone that uses the Active Directory RFC2307-compatible
schema attributes for user and group profiles. If you deselect the Use the default zone type option, you can choose to create either a hierarchical zone or a
classic zone and how you want zone information stored in the Active Directory schema.
If you are not using the default zone type and storage model, you have the following options:
A Standard zone stores user and group attributes in the keywords attribute of the serviceConnectionPoint object for the user or group rather than in
the user or group object.
An RFC2307-compatible zone stores user and group attributes in the attributes that are defined in the RFC2307-compatible schema for user and
group objects.
An SFU zone stores user and group attributes in the Services for UNIX (SFU) schema attributes for the user or group object.
It is worth noting that in the default zone storage model—which uses the default Active Directory RFC2307-compatible schema—some schema attributes are
not indexed. For example, in the default Active Directory RFC2307-compatible schema, the uid attribute is not an indexed attribute. Because of this limitation,
queries that use this attribute might take longer than expected.
Modifying Indexed Attributes For Zones
Depending on the requirements of your organization, you might see improved performance either by creating standard Centrify zones rather than RFC2307-
compatible zones or by indexing the uid attribute in default zones. Before selecting a strategy for all or selected zones, however, you should consider that
indexing the uid attribute requires you to modify the Active Directory schema.
Modifying the Active Directory schema is an advanced operation that should only be performed by experienced administrators. In addition, you must be a
member of the Domain Admins group or the Enterprise Admins group in Active Directory or been delegated similar authority to perform this operation. If you
choose to modify the schema to improve performance, you can use “Run as ...” to select an account with appropriate permissions before performing the
following steps.
To index an attribute:
1. Open a Command Prompt window, then type the following command to register the schema management assembly on your computer:
regsvr32 schmmgmt.dll
2. Click Start, click Run, type mmc /a, then click O K.
3. In the console root, select the File menu, then click Add/Remove Snap-in.
4. Under Available Standalone Snap-ins, double-click Active Directory Schema, click A d d, then click O K.
5. On the File menu, click Save, navigate to the %systemroot%/Sytem32 directory, type a file name for the console, then click Save.
6. Click Start > All Programs to select the Administrative Tools folder, right-click, then select Open.
If necessary, select Organize > Layout > Menu bar to display menus.
On the File menu, select New, then click Shortcut.
In the Create Shortcut Wizard, click in Type the location of the item, type the name you used for the file in Step 5, then click Next.
Select the file name in Type a name for this shortcut field, type Active Directory Schema, then click Finish.
7. Click Start > All Programs > Administrative Tools to select Active Directory Schema, right-click, then select Open.
8. Expand Attributes to select a specific attribute, such as uid, right-click, then select Properties.
9. Select Index this attribute, then click O K.
Viewing and Manipulating Data in Active Directory
You can view, access, and manage any information stored in Active Directory—including Centrify profiles, rights, roles, and role assignments—using ADSI Edit
or using any tools that can perform standard LDAP operations such as ldifde and OpenLDAP commands such ldapsearch, ldapadd, ldapdelete and ldapmodify.
For example, depending on the type of operating system and tools you prefer to use, you might view and manage Centrify profiles and zones using any
combination of the following tools:
Access Manager
Access Module for Windows PowerShell
Audit Module for Windows PowerShell
Active Directory Users and Computers
The Server Suite Windows API
The ADEdit Tcl application and procedure library
Centrify command-line programs
By using these tools, you can manipulate Centrify information manually or create scripts to automate key tasks such as the provisioning of new accounts. For
example, you can write scripts that access the Centrify Windows API or ADEdit procedures to automatically create computer, user, or group accounts, create
new zones, or assign users to roles. As part of your planning process, you should determine whether there are tasks you want to automate through the use of
scripts, so that members of the development team can create or modify the appropriate tools and test them thoroughly before deploying across the
organization.
Installing Authentication & Privilege Services
This section provides instructions for installing all identity and privilege management components on Windows computers in your network. There are several
Windows-based components that enable you to manage the deployment and ongoing operations of Server Suite software. You should install all of the identity
and privilege management components on at least one Windows computer. Depending on the division of responsibilities in your organization, you may want
to install different components on more than one Windows computer.
When you install identity and privilege management components, the following features are installed:
The Privileged Access Service, which enables MFA login, MDM, and other platform services.
The Privilege Elevation Service and Authentication Service, which together enable computers where Server Suite software is installed to use the Active
Directory infrastructure located on the domain controller, and enable users and zone-joined computers to have elevated privileges. The services
include ADUC extensions, GPOE extensions, PowerShell extensions, Server Suite utilities, and Access Manager.
Access Manager is the administrative console that enables you to create zones and configure rights and roles for Active Directory users running applications
on Windows computers.
You should always install the Windows components first before you install the Server Suite Agent on the non-Windows computers you intend to manage.
Preparing for Installation on Windows
Before installing Server Suite management components on Windows, you should verify that the computers where you are planning to install meet all of the
system requirements and prerequisites and that you have all of the information you need to install and configure the software packages.
At a minimum, you should install the following Server Suite components on one or more Windows computers during the first stage of deployment:

Zone Provisioning Agent
You can install these components together or independently using the setup program. Alternatively, you can install these components independently without
running the setup program by using individual setup programs for each component.
Installing Server Suite
Access Manager, which is installed when you install Server Suite, is the primary management console for performing access control and privilege
management operations. You typically install Access Manager directly on the computers used by one or more administrators. Alternatively, you can install it
on a physical or virtual server accessed remotely by one or more administrators. The most important requirement is that the computer where you install
Access Manager must be able to connect to the Active Directory domain and forest.
The Access Manager console can be installed from the setup program or from a standalone executable separate from the setup program. Before you install,
you should verify your environment meets the system requirements to ensure a successful deployment.
Preparing Active Directory and DNS
All of the Server Suite software components rely on critical pieces of Active Directory infrastructure. Before you install:
Verify Active Directory is installed and you have access to at least one Windows computer acting as a domain controller for the Active Directory forest
to which you want to add UNIX computers.
Check the configuration of DNS and whether you are using a Windows computer as the primary DNS server.
Verify the DNS server allows secure dynamic updates and your domain controllers are configured to publish updated service locator (SRV) records.
Verify DNS resolution and network communication between the UNIX computers and the Active Directory domain controller. You can use the ping
command to test communication between the domain controller and the UNIX computer.
Identifying the Windows Computer and Log On Credentials
Depending on how you plan to manage Server Suite properties, you should identify an appropriate Windows computer and the user account credentials you
should use. For example:
Check whether the Windows computer has Active Directory Users and Computers installed.
If you want to manage Server Suite properties using Active Directory Users and Computers, the Active Directory Users and Computers MMC snap-in
must be available on the local computer.
Check whether the Windows computer is a domain computer, such as a Windows XP workstation, or a domain controller.
If you install on a domain controller, you must use your own logon credential to connect to Active Directory. In most cases, you can install on any
computer that has access to a domain controller.
Verify that the Windows computer can connect to Active Directory.
Verify that you have a Windows user account and password with sufficient rights to install software on the local computer and permission to update the
Active Directory forest.
After installation, you must be able to create new container objects in the Active Directory forest. Alternatively, an Active Directory administrator can
manually configure the environment or temporarily modify your account permissions to enable you to perform setup tasks. For information about the
specific rights required to perform tasks in the Setup Wizard, see Permissions required to use the Setup Wizard.
Checking Operating System and Software Requirements
Before installing on Windows, check that you have a supported version of one of the Windows operating system product families. For example, you can use
Windows 7 for any console components. Alternatively, you can install components on computers in the Windows Server product family—such as Windows
Server 2008 or Windows Server 2012—so that your administrative computer can be configured with additional server roles.
For more detailed information about supported platforms for specific components, see the release notes.
You should also verify that you have the .NET Framework, version 4.5 or later, installed. If the .NET Framework is not installed, the setup program can install it
for you. Alternatively, you can download the .NET Framework from the Microsoft Download Center, if needed.
Checking Disk and Memory Requirements
You should also check that the computer where you are installing the Access Manager console meets the following requirements:
For this You need this
CPU speed Minimum 550 MHZ
RAM 25MB
Disk space 100MB
Running the Setup Program on a Windows Computer
You can install Server Suite software using the setup program on the CD or included in the download package. The setup program copies the necessary files
to the local Windows computer. There are no special permissions required to run the setup program other than permission to install files on the local
computer. From the setup program, you can choose which components of you want to install.
Note: If you intend to install the Zone Provisioning Agent using the setup program, you should review the requirements and other information in
Installing Zone Provisioning Agent before you proceed, but you can skip the standalone installation instructions in those sections. Use the
individual setup programs for components if you want to install a specific component on a specific computer. For example, use the
Centrify_Zpaversionwin64.exe program to selectively install Zone Provisioning Agent components on a computer where Access Manager is not
installed.
To install Authentication & Privilege on Windows:
1. Log on to the Windows computer and insert the CD or navigate to the directory where you downloaded Server Suite files.
If the Getting Started page is not automatically displayed, double-click the autorun.exe program to start the installation of the Server Suite software.
2. On the Getting Started page, click Authentication & Privilege to start the setup program for identity and privilege management components.
If any programs must be updated before installing, the setup program displays the updates required and allows you to install them. For example, you
might be prompted to install or update the Microsoft .NET Framework or Microsoft SQL Server Compact edition.
3. At the Welcome page, click Next.
4. Review the terms of the license agreement, click I agree to these terms, then click Next.
5. Type your name and organization, then click Next.
6. Expand and select the Delinea Administration and Delinea Utilities components you want to install, then click Next.
If you are managing access to Linux, UNIX, and Mac OS X computers, you should select the following Server Suite Administration components for
deployment:
ADUC property page extensions if you want to include Server Suite profiles when displaying properties in Active Directory Users and
Computers.
Access Manager if you want to use an administrative console to manage Server Suite zones and roles.
Group Policy Management Editor extension if you want to deploy Server Suite group policies.
You should also select the following Server Suite Utilities components for deployment:
Zone Provisioning Agent if you want to automatically provision user and group profiles into zones.
If you want to skip the installation of any component on the local computer, click to deselect the item that you want to skip, then click Next. For
example, if you want to skip installation of the Server Suite Reporting Service and its Microsoft SQL Server database, deselect the Server Suite
Reporting Service option, then click Next.
7. Accept the default location for installing components, or click Browse to select a different location, then click Next.
8. Review the components you have selected, then click Next.
The setup program begins installing the selected components.
9. When setup is complete for the selected packages, click Finish to close the setup program.
Depending on the components you selected, you might see options to configure reporting service, the Zone Provisioning Agent, or both. You can
deselect these options if you want to skip configuration or plan to install the components in a different computer. For details about configuring the
Server Suite reporting service, see the Report Administrator’s Guide. For details about configuring the Zone Provisioning Agent after installing it with the
Server Suite setup program, see Configuring the Zone Provisioning Agent.
Installing Zone Provisioning Agent
The Zone Provisioning Agent enables automated provisioning of user and group accounts into Server Suite zones. You configure the Zone Provisioning Agent
to monitor specific Active Directory groups that are linked to a zone. When you add or remove users or groups from the monitored groups, the Zone
Provisioning Agent adds or removes corresponding users or groups in the zone.
You can install the Zone Provisioning Agent with the Server Suite setup program or as a standalone service separate from the installation of other Server
Suite components. In most cases, it is installed on its own apart from the installation of other Server Suite components. After the Zone Provisioning Agent is
installed, you can configure the business rules for adding and removing groups and how the attributes associated with user or group profiles are
automatically generated.
About Zone Provisioning Agent and its Requirements
The Zone Provisioning Agent is intended to run on an ongoing basis on a computer that is always available. It requires a Windows user account with the right
to Log on as a service. If you have a single forest, you can install the Zone Provisioning Agent on one or two computers. If you install the Zone Provisioning
Agent on two computers, you should only run one instance at a time. The Zone Provisioning Agent on the second computer is intended for standby operation.
You should only start the Zone Provisioning Agent on the second computer if the first instance fails.
Note: The business rules that control provisioning are stored in Active Directory. If only one computer has the Zone Provisioning Agent and that
computer stops running, the automated provisioning of UNIX users and group is interrupted until the computer and the Zone Provisioning Agent
are restarted. Users with existing access to UNIX computers are not affected.
The Zone Provisioning Agent has the following components:
Zone Property Page Extension must be installed on the same computer as the Access Manager console. This extension adds a tab to the Zone
Properties for configuring provisioning rules.
Provisioning Agent can be installed separately from the property page as a standalone service or on the same computer as Access Manager. The
computer where you install the service should be available at all times. In most cases, this Windows service is not installed on the same computer as
Access Manager.
Command Line Utility can be installed separately or on the same computer as Access Manager. The command line utility allows you to write scripts
for provisioning tasks or update zones on demand.
If you have more than one forest, you should install a Zone Provisioning Agent in each forest. If you have geographical domains within a single forest, you may
want to install a Zone Provisioning Agent in each geographical domain. If you install a second instance of the Provisioning Agent for failover, be sure that only
one instance of the Provisioning Agent runs in each forest.
Zone Provisioning Agent account permissions
Account
Type of Required
name Notes
account permissions
(suggested)
The Zone Provisioning Agent requires permission to create UNIX profiles-- that is, the service connection
Active
Log on as a points in each zone where it needs to perform provisioning operations. The service account that runs the Zone
Cfy_SVC_ZPA Directory
service Provisioning Agent requires the Log on as a service right set as a local computer security policy, or in the
account
default domain policy.
Create a service account for the Zone Provisioning Agent
The Zone Provisioning Agent must run using a valid Windows user account with the right to Log on as a service. In most cases, you should create a dedicated
user account, called the service account, for the service to run as rather than use an existing user account.
To create a new service account for the Zone Provisioning Agent:
1.Open Active Directory Users and Computers.

2.Select the UNIX Service Account organizational unit.
3.Right-click, then select New > User.
4.Type a display name and logon name for the service account, then click Next.
5.Type and retype a password for the service account and modify the account options as follows, then click Next:
Uncheck User must change password at next logon
Check User cannot change password
Check Password never expires
6. Click Finish to add the service account.
Configure the local or domain group policy to allow the account to log on as a service
After you have created the service account, you must edit either a local security policy or the default domain group policy to grant the service account the
Log on as a service right.
If you edit the default domain policy, the Zone Provisioning Agent can run on any Windows computer. If you need to move the service from one computer to
another, no additional configuration is required.
Alternatively, you can edit the local security policy specifically on the computers that run the Zone Provisioning Agent. If you use the local policy, however,
you may need to investigate whether other group policies are applied to the computer running the Zone Provisioning Agent to see if inheritance disables your
local policy setting.
To edit the default domain group policy:
1. Open the Group Policy Object Editor and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies >
User Rights Assignment > Log on as a service.
2. Right-click Log on as a service, then select Properties.
3. Select Define these policy settings, then click Add User or Group.
4. Click Browse to search for the service account you created.
5. Select the service account, then click O K to add the account and O K again to apply the policy.
Installing the Zone Provisioning Agent on the Access Manager computer
You can install both the Zone Provisioning Agent service and the Zone Property Page Extension on the computer where Access Manager is installed. At a
minimum, you should install the Zone Property Page Extension on the same computer as the Access Manager console. The Zone Property Page Extension
enables you to configure the Active Directory groups to monitor and the business rules for how to derive each user and group attribute.
Note: If you select the Zone Provisioning Agent when you install components using the Server Suite setup program, all Zone Provisioning Agent
components are installed. If you want to selectively install Zone Provisioning Agent components on a computer, you can install by running the
Centrify_Zpaversionwin64.exe program.
To install the Zone Provisioning Agent on the Access Manager computer:
1. Log on to the Windows computer where Access Manager is installed.
2. Double-click the Centrify_Zpaversionwin64.exe file to start the Zone Provisioning Agent setup program.
3. If a User Account Control message is displayed, click Yes.
If necessary, the setup program prompts you to install the Delinea Common Components.
4. On the Welcome screen, click Next.
5. Accept the licensing agreement, then click Next.
6. Select the features to install, then click Next.
The Zone Property Page Extension is only applicable on the computer where the Access Manager console is installed. Selecting this option adds the
Provisioning tab to the Zone Properties for individual zones. You can install or uncheck the other features on the computer where the Access Manager
console is installed.
7. Click Next to accept the default location for the Zone Provisioning Agent files, or click Browse to select a different location, then click Next.
8. Click Install to begin installation.
9. Click Finish to complete the installation.
Installing the Zone Provisioning Agent on its own
You can install the Provisioning Agent as a standalone service on a computer with a relatively light load. The computer where you install the Provisioning
Agent should be one that is online at all times. If the computer is shut down or suspended, the Provisioning Agent service will be suspended and no
provisioning can occur. You can install a second instance of the Zone Provisioning Agent on another computer, and use your existing method of determining if
a service has failed to monitor the availability of the first instance. For example, configure monitoring of the Windows Event log to notify you if the Zone
Provisioning Agent service stops.
If you install the Provisioning Agent service as a standalone service, you should also install the Command Line Utility on the same computer.
To install the Zone Provisioning Agent as a standalone service:
1. Log on to the Windows computer that has a light load and is rarely shut down or offline.
2. Double-click the Centrify_Zpaversionwin64.exe file to start the Zone Provisioning Agent setup program.
3. If a User Account Control message is displayed, click Yes.
If necessary, the setup program prompts you to install the Delinea Common Components.
4. On the Welcome screen, click Next.
5. Accept the licensing agreement, then click Next.
6. Select the Provisioning Agent and Command Line Utility features, then click Next.
7. Click Next to accept the default location for the Zone Provisioning Agent files, or click Browse to select a different location, then click Next.
8. Click Install to begin installation.
9. (Optional) Uncheck the Configure and start Zone Provisioning Agent option, then click Finish.
If you leave Configure and start Zone Provisioning Agent selected, you are prompted to provide the service account name and password, then
click Start to start the agent service. It is recommended that you configure the monitored containers, polling interval, and logging options, in addition to
the service account name and password before starting the service. Therefore, you should open Access Manager to set up the Server Suite
organization structure in Active Directory. For more information about the initial configuration, see Running Access Manager for the first time.
Configuring the Zone Provisioning Agent
By default, the Zone Provisioning Agent monitors all domains in the entire forest. If you use the recommended Server Suite organizational structure described
in Creating recommended organizational units, it is recommended setting the Zone Provisioning Agent to only monitor the top-level Server Suite
organizational unit or the Zones container. These objects are created in the Setup Wizard the first time you open Access Manager. After the initial
configuration, you can perform the steps in this section to configure the Zone Provisioning Agent. For more information about the initial configuration, see
Running Access Manager for the first time.
The most common reason for monitoring more than one organizational unit is if you have a regional or team-based OU structure in Active Directory, where
each region or team is responsible for managing its own UNIX data. In this scenario, a provisioning staff member in Sidney, Australia, wouldn’t be responsible
for account fulfillment of a UNIX user in Chicago. To ensure the appropriate separation of duties between the different regions or teams, you would have
more than one Server Suite organizational unit, and you would configure the Zone Provisioning Agent to search each of the regional organizational units.
To configure the Zone Provisioning Agent
1. Open the Zone Provisioning Agent Configuration Panel by clicking Start > All Programs > Server Suite 2021.1 > Zone Provisioning Agent
Configuration Panel.
2. In the Monitored containers section, click A d d.
3. Navigate to select the Server Suite organizational unit or the Zones container, then click O K.
4. Select Entire Forest forest_name from the list of Monitored containers, then click Remove.
5. Set the provisioning polling interval in minutes.
The polling interval controls how often the Zone Provisioning Agent checks monitored containers for changes and processes the business rules for
provisioning users and groups into zones. The appropriate interval often depends on the expectations of the user population or on service level
agreements that define the provisioning team’s commitments. In general, you should avoid polling more frequently than necessary to reduce the affect
the Zone Provisioning Agent has on the performance of your domain controllers.
6. If desired, you can specify which domain controller that the Zone Provisioning Agent uses.
1. To specify the domain controllers, click Advanced.
The Advanced Domain Controller Settings dialog box displays.
2. Click A d d to open a separate dialog box in which you can add a domain and pick from a list of domain controllers. Click O K to save your chances.
3. Click Change if you want to change the specified domain controller, or click Remove if you need to remove the specified domain controller.
7. Type the service account name or click Browse to locate the service account name, then type the password for the account.
8. Click Apply.
9. Click Start to start the Zone Provisioning Agent.
Whitelisting Domains for the Zone Provisioning Agent
You can configure the Zone Provisioning Agent so that it can connect to trusted domains (whitelisting) by setting the following registry key with a list of
trusted domains and/or forests:
HKLM\SOFTWARE\Centrify ZPA\AllowedDomains
Configuring a list of domains this way can be particularly useful and faster when you have a large amount of domains.
For example, to specify a single domain:
HKLM\SOFTWARE\Centrify ZPA\AllowedDomains: "acme.com"
For example, to specify multiple domains:
HKLM\SOFTWARE\Centrify ZPA\AllowedDomains: "acme.com", "foo.com"
Running Access Manager for the First Time
The first time you start the Access Manager console, a Setup Wizard guides you through the initial configuration of the Active Directory forest. This initial
setup creates the recommended or a custom deployment structure including the parent containers for Licenses and Zones and sets the permissions for
modifying the objects within the containers. These steps are only performed once and can be done manually, if you choose.
Because the Setup Wizard creates container objects, you might need to use a domain administrator account. This requirement depends on the specific
permissions your organization has configured for different classes of users. For example, if your organization only permits Domain Admins to create parent
and child objects in Active Directory, you need to use an account with those permissions to run the Setup Wizard. For more information about the permissions
required to perform specific configuration steps, see Permissions required to use the Setup Wizard.
Access Manager Account Permissions
Account
Type of Required
name Notes
account permissions
(suggested)
Domain Because the Setup Wizard creates container objects, you might need to use a domain administrator
administrator domain account. This requirement depends on the specific permissions your organization has configured for
n/a (when running admin (in different classes of users. For example, if your organization only permits Domain Admins to create
Access Manager most cases) parent and child objects in Active Directory, you need to use an account with those permissions to run
for the first time) the Setup Wizard.
To start the Setup Wizard and update the Active Directory forest
1. Open Access Manager from the desktop shortcut or Start menu.
2. Verify the name of the domain controller displayed is a member of the Active Directory forest you want to update or type the name of a different domain
controller if you want to connect to a different forest, then click O K.
If you want to connect to a different forest, type the name of a domain controller in that forest.
If you want to connect to the forest with different credentials, select Connect as another user, then type a user name and password to
connect as.
4. Select Use currently connected user credentials to use your current log on account or select Specify alternate user credentials and type a
user name and password, then click Next.
5. Select Generate the recommended deployment structure if you want to create all of the containers for the recommended deployment
structure automatically.
If you select this option, select whether you want to generate the default deployment structure or generate a custom structure, then click Next.
If you are generating the default structure, clicking Next enables you to select or create the location for the deployment structure in Active
Directory. For example, if you want to create the top of the default deployment structure at the domain level, click Next, then click Browse to
select the domain name. After you have selected a location, click O K. then click Next to create the deployment structure.
If you are generating a custom structure, clicking Next enables you to export the script that creates the default structure or run a script you have
previously written.
If you are generating a default or custom deployment structure, verify the successful execution of the script that creates the structure, then click
Next to continue.
6. Verify the parent container for licenses is in the top-level Server Suite container if you are using the default deployment structure or the container of
your choice, then click Next.
You can add other Licenses containers in other locations later using the Manage Licenses dialog box.
If you are not using the recommended deployment structure, the default container for license keys is domain_name/Program Data/Centrify/Licenses.
To create the parent container in a different location, you can click Browse.
7. Review the permission requirements for the container, then click Yes to continue.
If you don’t want to allow the permissions for the selected container, click N o and select a different container to continue.
8. Type or copy and paste the license key you received, then click A d d.
If you received multiple license keys, add each key to the list of installed licenses, then click Next. If you received license keys in a text file, click Import
to import the keys directly from the file instead of adding the keys individually, then click Next.
You can also add and remove license containers and keys after the initial configuration.
For details about licensing, including how to request new license keys after deployment, check license usage and compliance, and how license counts
are determined, see the License Management Administrator’s Guide.
9. Verify that the Create default zone container option is selected and the parent container for zones is in the top-level Server Suite container or the
container of your choice, then click Next.
If you are not using the recommended deployment structure, the default container for zones is domain_name/Program Data/Centrify/Zones. To create
the parent container in a different location, you can click Browse.
You can skip creating the parent container in the forest or have more than one Zones parent container. For example, if you have a regional OU structure
in Active Directory—where each region is responsible for its own set of zones—each region should have its own top-level organizational unit. For
example, if you have separate OU structures for Tucson, AZ, and Newark, NJ, you would have separate deployment structures—SS-AZ and SS-NJ, for
example—with separate parent containers for zones under each deployment structures. Users in each region can select the appropriate parent
container when they create new zones.
Note: Users must have permission to read and create container objects on the parent Zones container and all child objects. You should
verify the appropriate users have the permissions required to create new zones.
10. If you are using the recommended deployment structure, click Next to continue.
This option allows “self-service” join operations for computers in the Computers container. It is only applicable if you are not using the recommended
deployment structure. If you want to support “self-service” join operations and are not using the recommended deployment structure, select Grant
computer accounts in the Computers container permission to update their own account information, then click Next.
11. If you plan to use Access Manager to manage information stored in Active Directory and maintain data integrity, click Next to continue.
You should select Register administrative notification handler for Microsoft Active Directory Users and Computers snap-in if you
want to automatically maintain the integrity of the information in Server Suite profiles.
This option prevents Server Suite profile information from being left “orphaned” when changes are made to Active Directory objects such as users and
groups. This option is not selected by default because it requires you to have Enterprise Admin or Domain Admin rights for the forest root domain.
12. Select Activate Centrify profile property pages if you want to be able to display Server Suite profiles in any Active Directory context, then click
Next.
Setting this option ensures that displaying the properties for a user, group, or computer always displays the Centrify Profile tab regardless of how you
navigate to the Properties dialog box.
13. Review and confirm your configuration settings, click Next, then click Finish.
Installing Agents on Computers to be Managed
This chapter describes the recommended steps for deploying Server Suite software on the nonWindows computers that you want to add to Active Directory.
The chapter also describes the alternatives you can use to install agent packages on non-Windows computers, including using native Linux installers to
install Server Suite packages manually and automatically.
About the Deployment Process
The steps in this section, and in Preparing to migrate existing users and groups and Migrating existing users to hierarchical zones, are iterative in nature. In
most cases, you will select a subset of computers for deployment, and repeat the steps for each target group until you have migrated all of the computers and
users in the enterprise into Active Directory.
There is no technical requirement that you only work with a subset of computers at a time, but in practice the process of checking computers for potential
problems and resolving open issues is more manageable when applied to a subset of computers. It is also more practical to migrate user populations in stages
rather than all at once. After you step through the process a few times, you'll be able to anticipate and resolve potential issues more quickly and move into a
more rapid deployment model.
Select a Target Set of Computers
As a first step in preparing to install Server Suite software, you should select a target set of computers on which to deploy. The target set can be based on any
criteria you choose. In many organizations, new software must always be installed in the development environment first, then in the pre-production
environment, before it can be deployed in the production environment. If your organization has this type of requirement, the first target set of computers
would be the computers in the development environment.
Other possible candidates for the target set might be computers that:
Have been identified for changes by an audit finding

Are in the same physical location, such as a particular data center
Share common attributes, such as all Red Hat Linux computers or all of the servers in a Web farm
Are used by a particular department, project, or line of business
Have a common set of users who need access to the computer resources
After you have identified a target set of computers, you are ready to begin the deployment. You should notify the user community that you are planning to
install software on the target set of computers. For example, you may want to notify users by sending out an email message similar to the sample provided in
Preliminary software delivery notification email template.
After you have identified a target set of computers to work with, you can use adcheck to check whether those computers have any issues that need to be
resolved before you install new software on them. Checking the environment before you install helps to reduce change control issues.
Options for deploying Server Suite Agent Packages
You can:
Run the agent installation script locally on any computer and respond to the prompts displayed.
Create a configuration file and run the installation script remotely on any computer in silent mode.
Use the install or update operations in the native package installer for your operating environment.
Use a commercial or custom software distribution tool.
If you want to use one of these installation options and need more information, see the appropriate section.
Install Interactively on a Computer
The Server Suite Agent installation script, install.sh, automatically checks the operating system, disk space, DNS resolution, network connectivity, and other
requirements on a target computer before installing. You can run this script interactively on any supported UNIX, Linux, or Mac OS X computer and respond to
the prompts displayed.
To install Server Suite software packages on a computer interactively
1. Log on or switch to the root user if you are installing on a Linux or UNIX.
If you are installing on Mac OS X, you can log on with any valid user account.
Note: On Mac OS X computers, you can install interactively using the graphical package installer or the install.sh script. For information
about installing and joining an Active Directory domain using the Mac OS X package installer, see the Mac-specific instructions in the
Administrator's Guide for Mac.
2. Mount the cdrom device using the appropriate command for the local computer's operating environment, if necessary. On most platforms, the CD drive
is automatically mounted.
Note: If you have downloaded the package from an FTP server or website, verify the location and go on to the next step.
The instructions for mounting the CD drive are platform-specific. For example on Linux, you can use a command similar to the following:
`mount /mnt/cdrom`
To manually mount the CD drive on AIX, run a command similar to the following:
`mount -v cdrfs -o ro /dev/cd0 /cdrom`
To mount the CD drive on HP-UX, run a command similar to the following to display the long file names:
mount -F cdfs -o rr /dev/dsk/c0t0d0 /mnt/cdrom
3. Change to the appropriate directory that contains the Server Suite Agent package you want to install.
For example, to install an agent on a Linux computer from a downloaded Server Suite ISO or ZIP file, change to the Agent_Linux directory:
cd Agent_Linux
Similarly, if you are installing on a Solaris, HP-UX, AIX or other UNIX computer, change to the Agent_Unix directory. If installing on a Mac OS X computer,
change to the Agent_Mac directory.
If you downloaded individual agent packages from the Delinea Download Center, unzip and extract the contents. For example:
gunzip -d centrify-infrastructure-services-VERSION-platform-arch.tgz
tar -xf centrify-infrastructure-services-VERSION-platform-arch.tar
4. Run the install.sh script to start the installation of the agent on the local computer's operating environment. For example:
./install.sh
5. Follow the prompts displayed to select the services you want to install and the tasks you want to perform. For example, you can choose whether you
want to:
Perform a default installation.
Perform a custom installation by selecting the specific packages to install.
Join a domain automatically at the conclusion of the installation.
Depending on your selections, you may need to provide additional information, such as the user name and password for joining the domain.
Run the Bundle Installation from a Mounted Network Volume
You can install agents from a mounted network volume using the install-bundle.sh script. This script is available on the agent CD or ISO file that contains all of
the supported agent platforms in compressed format. The bundle installation script automatically determines the platform required and extracts the
contents of the appropriate TGZ file, then starts the normal installation process.
To use the install-bundle.sh script
1. Copy the install-bundle.sh script onto a network file system share and mount the shared directory.
2. Verify that the file is executable and that you have appropriate privileges to run it. For example:
chmod +x install-bundle.sh
chmod 755 install-bundle.sh
3. Run the script without command line options to start the installation or add command line options to install the agent silently.
For example, to start an interactive installation, type a command similar to this:
sudo ./install-bundle.sh
To install the agent silently, type a command similar to this:
./install-bundle.sh --std-suite --adjoin_opt="sidebet.org --password pa\$swd sudo ./install-bundle.sh
zone global --container sidebet.org/UNIX/Servers --server demo.sidebet.org"
To see complete usage information for the install-bundle.sh script, type:
./install-bundle.sh --help
Install Silently Using a Configuration File
Installing without user interaction enables you to automate software delivery and the management of remote computers. If you want to install files without
any user interaction, you can run the install.sh script silently invoking the script with the appropriate command-line arguments. You can also customize the
packages installed and other options by creating a custom configuration file for the installer to use.
To see the install.sh silent mode and other command line options, enter install.sh h
To install Authentication & Privilege default packages and configuration options silently, run:
install.sh --std-suite
To install Authentication & Privilege and Audit & Monitoring default packages and configuration options, run:
install.sh --ent-suite
To install a customized set of packages that all have the same version number, run:
install.sh -n
About the Sample Configuration Files Available
You can customize the install.sh execution script. There are two sample configuration files for installing software packages silently. These sample
configuration files are located in the same directory as the install.sh script:
centrifydc-suite.cfg
centrify-install.cfg
If you want to customize the packages installed or other configuration options, you can modify the sample centrifydc-suite.cfg or centrifydc-install.cfg file.
The centrifydc-suite.cfg file is used when you run install.sh with the --stdsuite or --ent-suite options. If you run install.sh --std-suite or install.sh --ent-suite with a customized
version of the centrifydc-suite.cfg file, you can selectively install compatible add-on packages that do not have the same version number as the core Server Suite
Agent.
Alternatively, you can run install.sh -n with a customized version of the centrifydc-install.cfg file to install the agent and add-on packages if they all have the same
version number.
If you run the install.sh script silently and it cannot locate the centrifydc-suite.cfg or centrifydc-install.cfg file to use, default values defined directly in the script itself
are used.
Setting the Parameters in a Custom Configuration File for the Installation Script
If you want to specify values for the install.sh script to use, you should edit the sample centrifydc-suite.cfg or centrifydc-install.cfg file in its default location before
invoking the install.sh script in silent mode.
Note: The parameters in the centrifydc-install.cfg or centrifydc-suite.cfg file are the same, except that the centrifydc-suite.cfg file is used when installing a set
of services to allow packages with different version numbers to be installed together. Because you should not modify the compatibility defined in
the centrifydc-suite.cfg file, those parameters are not included in the table.
To customize the installation using the centrifydc-install.cfg or centrifydc-suite.cfg file, you can set the following parameters:
| Parameter | Description | | ----- | ----- | | ADCHECK | Indicate whether you want to run the adcheck program to check the configuration of a local computer and
its connectivity to Active Directory. Note that the install.sh script calls adcheck twice. After the first call, adcheck performs several required pre-installation
steps to make sure you can install the Centrify Agent on the host computer. These steps are mandatory and cannot be skipped. However, the second call to
adcheck is used to perform post-installation steps to make sure the agent has been installed successfully. The second set of checks is optional and can
skipped. Set this parameter to Y if you want to run adcheck after installing. For non-interactive installations, the default is N. | | ADLICENSE | Indicate whether
you want to install licensed features. Set this parameter to Y if you have purchased and installed license keys. If you downloaded and want to install
unlicensed Centrify Express agents, set this parameter to N. | | GLOBAL_ZONE_ONLY | Specify whether you want to install the agent in a Solaris 10 global
zone and no other zones. Set this parameter to Y only if you are running the install.sh script on a Solaris 10 computer and want to install the agent in the Solaris
10 global zone and none of your non-global zones. In most cases, you only set this parameter to Y if you use sparse root zones. The default setting for this
parameter is N so that the agent is installed in all Solaris zones. If the script is not running on a Solaris 10 computer, this parameter is ignored. | | ADJOIN |
Indicate whether you want to attempt to join an Active Directory domain in non-interactive mode. Set this parameter to Y to attempt to join the domain
automatically. Set this parameter to N to manually join the domain after installation. | | ADJ_FORCE | Overwrite the information stored in Active Directory for
an existing computer account. Set this parameter to Y to replace the information for a computer previously joined to the domain. If there is already a
computer account with the same name stored in Active Directory, you must use this option if you want to replace the stored information. You should only use
this option when you know it is safe to force information from the local computer to overwrite existing information. | | ADJ_TRUST | Set the Trust for
delegation option in Active Directory for the computer account. Trusting an account for delegation allows the account to perform operations on behalf of
other accounts on the network. | | DOMAIN | Specify the domain to join, if you set the ADJOIN parameter to Y. Set this parameter to the name of a valid Active
Directory domain. | | USERID | Specify the Active Directory user name to use when connecting to Active Directory to join the domain. Set this parameter to a
valid Active Directory user name. | | PASSWD | Specify the password for the Active Directory user name you are using to connect to Active Directory. Set this
parameter to the password for the Active Directory user name specified for the USERID parameter. | | COMPUTER | Specify the computer name to use for the
local host in Active Directory. Set this parameter to the computer name you want to use in Active Directory if you don't want to use the default host name for
the computer. | | CONTAINER | Specify the distinguished name (DN) of the container or Organizational Unit in which you want to place this computer account.
The DN you specify does not need to include the domain suffix. The domain suffix is appended programmatically to provide the complete distinguished name
for the object. If you do not specify a container, the computer account is created in the domain's default Computers container. Note that the container you
specify must already exist in Active Directory, and you must have permission to add entries to the specified container. | | ZONE | Specify the zone to which you
want to add this computer. | | SERVER | Specify the name of the domain controller to which you prefer to connect. You can use this option to override the
automatic selection of a domain controller based on the Active Directory site information. | | DA_ENABLE | Indicate whether you want to automatically enable
the auditing service on the local computer. The valid settings are: Y if you want to enable auditing with the default auditing configuration. N if you don't want
to enable auditing. K if you are upgrading and want to keep your current auditing configuration unchanged. | | DA_X_ENABLE | Indicate whether you want to
automatically enable the Linux desktop auditing service on the local computer. The valid settings are: Y if you want to desktop enable auditing with the default
auditing configuration. N if you don't want to enable desktop auditing. K if you are upgrading and want to keep your current auditing configuration unchanged |
| DA_INST_NAME | Specify the name of an auditing installation if you set the DA_ENABLE parameter to Y. | | REBOOT | Indicate whether you want to
automatically restart the local computer after a successful installation. Set this parameter to Y if you want to automatically restart the local computer or to N
if you don't want the computer restarted automatically. | | INSTALL | Specify the operation to perform. The valid settings are: Y to install the Server Suite Agent
for *NIX and any other Server Suite software packages if they are not already installed on the local computer. U to update older versions of the Server Suite
Agent for *NIX and any other Server Suite packages you have installed. The update option only updates software from one major release version to another. It
does not update the software if the major release version is same between packages. R to reinstall or repair the Server Suite Agent for *NIX and any other
Server Suite packages you have installed. You can reinstall packages that have the same major release version but different build number or repair packages
by installing an older version of the package. E to remove the software currently installed. K to keep current software unchanged. Set this parameter to Y to
install or to U to update the Server Suite Agent for *NIX and other packages. If you want to install or update other packages, select the operation to perform
for each package. For example to update the Server Suite Kerberos package and keep the current Server Suite LDAP proxy service, you might specify the
following: CentrifyDC_krb5=”U” CentrifyDC_ldapproxy="K" Note that these additional packages may have dependencies or require a specific version of the Server
Suite Agent for *NIX to be installed. Before installing or updating additional packages silently, you should review the information in the Upgrade and
Compatibility Guide. | | UNINSTALL | Specify whether you want to forcibly uninstall all installed packages. | For example, you can edit the centrifydc-install.cfg
or centrifydc-suite.cfg file to silently install the Server Suite Agent for *NIX, join the domain, and automatically reboot the computer at the completion of the
installation process with a file similar to this:
ADCHECK="N"
ADLICENSE="Y"
\# Solaris 10 -G option, installation in global zone only
GLOBAL_ZONE_ONLY="N"
ADJOIN="Y"
ADJ_FORCE="N"
ADJ_TRUST="N"
DOMAIN="sample.company.com"
USERID=administrator
PASSWD="securepassword123"
\#COMPUTER=my_host_name
\#CONTAINER="my_computers"
ZONE="global_zone"
\#SERVER=server_name
DA_ENABLE="N"
DA_INST_NAME=""
REBOOT="Y"
\# Install the core agent package
INSTALL="Y"
\# Skip installation for other packages

CentrifyDC_nis=
CentrifyDC_krb5=
CentrifyDC_ldapproxy=
CentrifyDC_openssh=
CentrifyDC_web=
CentrifyDC_apache=
CentrifyDC_idmap=
CentrifyDA=
This sample configuration file does not install any of the Server Suite add-on packages. You can also use the configuration file to silently install or update
selected packages. For example, to update the LDAP proxy service and OpenSSH on a computer, you would modify the configuration file to indicate that you
want to update those packages:
CentrifyDC_ldapproxy=”U”
CentrifyDC_openssh=”U”
Customizing the Return Codes for the Installation Script
Normally, when you run the install.sh script silently, the script returns an exit code of 0 if the operation is successful. If you want the script to return exit codes
that indicate whether the operation performed was a successful new installation, a successful upgrade, a successful uninstall, or there were errors
preventing installation, you can also use the custom_rc option. For example:
install.sh -n --custom_rc
When you specify this option, the following return codes that are defined in the install.sh script are used to provide more detailed information about the
result:
Return code Description
CODE_SIN=0 Successful installation
CODE_SUP=0 Successful upgrade
CODE_SUN=0 Successful uninstallation
CODE_NIN=24 Did nothing during installation
CODE_NUN=25 Did nothing during uninstallation
CODE_EIN=26 Error during installation
CODE_EUP=27 Error during upgrade
CODE_EUN=28 Error during uninstallation
Error encountered during setup, for example, the UID is not the root user UID, the operating environment is not supported or not
CODE_ESU=29
recognized, or the script is executed with invalid arguments
Use Other Automated Software Distribution Utilities
You can also install Server Suite software using virtually any automated software distribution framework. For example, you can use software delivery
offerings from HP OpsWare or IBM Tivoli, or features such as Apple Remote Desktop, or software distribution in the Casper Suite to deliver Server Suite
software to remote computers. You can also use any custom software delivery tools you have developed specifically for your organization. If you use a
commercial or custom software distribution mechanism, review the release notes text file included with agent package for platform-specific installation
details.
Using a Native Package Installer
If you want to manually install a software package using a native installation program instead of the Server Suite installation script, you can follow the
instructions in the Upgrade and Compatibility Guide for the most common native package installers, such as the Red Hat or Debian package manager. You
should note that these native packages are signed with a GNU Privacy Guard (GPG) key. You need to import the key to verify the package authenticity before
installing the package. You can download the RPM-GPG-KEY-centrify file from the Delinea Download Center.
Alternatively, you can use any other installation program you have available for the local operating environment. For example, if you use another program
such as SMIT, YAST, APT, SUSE, or YUM to install and manage software packages, you can use that program to install Server Suite software packages.
Perform the following steps to install the Server Suite Agent using a native installation program that does not require a connection to a package repository.
To use a native installation program that requires a repository connection (such as yum, SUSE or APT), see Enabling package repositories.
To install the agent using a native installation program
1. Log on as or switch to the root user.
2. If you are installing from a CD and the CD drive is not mounted automatically, use the appropriate command for the local computer's operating
environment to mount the cdrom device.
3. Copy the appropriate package for the local computer's operating environment to a local directory.
For example, if installing from the CD and the operating environment is Solaris 10 SPARC:
cp /cdrom/cdrom0/Unix/centrifydc-release-sol10-sparc-local.tgz .
4. If the software package is a compressed file, unzip and extract the contents. For example, on Solaris:
gunzip -d centrifydc-release-sol10-local.tgz tar -xf centrifydc-release-sol10-sparc-local.tar
5. Run the appropriate command for installing the package based on the local computer's operating environment. For example, on Solaris:
pkgadd -d CentrifyDC-a admin
If you are not sure which command to use for the local operating environment, see the documentation associated with the package installer you are
using.
Enabling Package Repositories
You can also download and install agents using Linux package management software for your operating system. To do this, you set up a repository for your
operating system and then use the software's command line tools to manage automatic agent updates.
RedHat, CentOS, or Amazon systems: Use the "Yellowdog Updater, Modified (yum)" tool to update the rpm-redhat repository. For details, see To
set up and configure a RedHat, CentOS, or Amazon repository.
SuSE systems: Use the Zypper tool to update the rpm-suse repository. For details, see To set up and configure a SUSE repository.
Debian or Ubuntu systems: Use the Advanced Package Tool (APT), apt-get, or Aptitude tools to update the deb repository. For details, see To set up
and configure a Debian or Ubuntu repository.
Atomic systems: Use curl or wget to update the wget repository. For details, see To access a raw package (WGET) repository.
Alpine Linux systems: For details, see To set up and configure an Alpine Linux repository.
You must perform one of the above procedures to enable the repository.
Note: The procedures in this section require that you log in to the Delinea Support Portal and go to the Delinea Repo site. On that page, click the
link to generate the repo key. You will then specify the repo key in a yum (RHEL, SUSE, and so forth) or APT (Debian, Ubuntu, and so forth)
configuration file. There are some examples on the Delinea repo site about how to add the key to your configuration file.
Note: For additional details about configuring and using SUSE or yum repositories, see the documentation for the distribution of Linux you are
using. For additional details about configuring and using APT repositories, see the documentation for the distribution of Debian Linux or Ubuntu
you are using.
WARNING: If you specify your repository on the command line, be sure to clean out your command history afterwards. Because the URL for your repository
includes the credentials to access it, leaving this information around in command history is not a secure practice.
Redhat
To Set Up and Configure a Redhat, Centos, or Amazon Repository
1. Create a /etc/yum.repos.d/centrify-rpm-redhat.repo configuration file to use the official Delinea package repository, and download a RPM-GPG-KEY-
centrify key from the Delinea Support Portal.
You can manually create the configuration file or you can use a setup script to generate the file automatically.
Note: For the baseurl parameter, enter your Delinea repo URL token in place of <URLtoken>.
To create the repository configuration file manually
Create a file with the following:
# Source: CENTRIFY
# Repository: CENTRIFY / rpm-redhat
# Description: YUM repository for RedHat packages (RPMs)
[centrify-rpm-redhat]
name=centrify-rpm-redhat
baseurl=https://cloudrepo.centrify.com/URLTOKEN/rpm-redhat/rpm/any-distro/any-version/$basearch
repo_gpgcheck=1
enabled=1
gpgkey=https://downloads.centrify.com/products/RPM-GPG-KEY-centrify
gpgcheck=1
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
pkg_gpgcheck=1
autorefresh=1
type=rpm-md
To create the repository configuration file automatically from a script
curl -1sLf ' https://cloudrepo.centrify.com/URLTOKEN/rpm-redhat/cfg/setup/bash.rpm.sh' | sudo -E bash
You should see output that lists out your repository details, such as the following example:
# Source: CENTRIFY
# Repository: CENTRIFY / rpm-redhat
# Description: YUM repository for RedHat packages (RPMs)
[centrify-rpm-redhat]
name=centrify-rpm-redhat
baseurl=https://cloudrepo.centrify.com/URLTOKEN/rpm-redhat/rpm/el/6/$basearch
repo_gpgcheck=1
enabled=1
gpgkey=https://cloudrepo.centrify.com/URLTOKEN/rpm-redhat/cfg/gpg/gpg.BDD3FD95B65ECA48.key
gpgcheck=1
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
pkg_gpgcheck=1
autorefresh=1
type=rpm-md
Note: The gpgkey listed in the output is a public key.
2. Execute the yum info command to verify the repository connection. You should see output similar to the following.
#yum info CentrifyDC

Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
2020-11-24 10:20:22,669 [INFO] yum:17896:MainThread @connection.py:905 - Connection built: host=subscription.rhsm.redhat.com port=443 handler=/subscription auth=identity_cert
ca_dir=/etc/rhsm/ca/ insecure=False
2020-11-24 10:20:22,671 [INFO] yum:17896:MainThread @repolib.py:464 - repos updated: Repo updates
Total repo updates: 0

Updated
<NONE>
Added (new)
<NONE>
Deleted
<NONE>
This system is not registered with an entitlement server. You can use subscription-manager to register.
Available Packages
Name : CentrifyDC
Arch : x86_64
Version : 5.7.0
Release : 207
Size : 23 M
Repo : centrify-rpm-redhat/x86_64
Summary : Centrify DirectControl Agent
URL : http://www.centrify.com/
License : BSD with portions copyright (c) Centrify Corporation 2006-2020 and licensed under Centrify End User License Agreement
Description : RPM to install Centrify DirectControl on Linux platforms.
```
3. Install the Server Suite Agent for *NIX rpm package.
# yum install CentrifyDC
Note: To uninstall the Server Suite Agent rpm file, you can use the erase command. For example:
# yum erase CentrifyDC
SuSE
To Set Up and Configure a Suse Repository
1. If you have used a Delinea repository before, it's recommended that you first delete the old repositories in the /etc/zypp/repos.d/*centrify* directory.
2. Create a new SUSE repository.
You can manually create the repository or you can use a setup script to create the repository automatically.
Note: For the baseurl parameter, enter your Delinea repository URL token in place of URLTOKEN.
To create the SUSE repository configuration file manually
Create a file with the following:
/etc/zypp/repos.d # cat /etc/zypp/repos.d/centrify-rpm-suse.repo

[centrify-rpm-suse]
name=centrify-rpm-suse
enabled=1
autorefresh=1
baseurl=https://cloudrepo.centrify.com/URLTOKEN/rpm-suse/rpm/any-distro/any-version/$basearch
type=rpm-md
repo_gpcheck=1
gpgcheck=1
gpgkey=https://downloads.centrify.com/products/RPM-GPG-KEY-centrify
To create the SUSE repository configuration file automatically from a script
curl -1sLf 'https://cloudrepo.centrify.com/URLTOKEN/rpm-suse/cfg/setup/bash.rpm.sh' | sudo -E bash
3. Refresh the cache.
/etc/zypp/repos.d # zypper refresh
4. Verify the connection to the repository.
/etc/zypp/repos.d # zypper packages |grep centrify
You should see output similar to the following:
mysusemachine:/etc/zypp/repos.d # zypper refresh

Retrieving repository 'centrify-rpm-suse' metadata ---------------[\]
Retrieving repository 'centrify-rpm-suse' metadata ...............[done]

Building repository 'centrify-rpm-suse' cache ....................[done]
All repositories have been refreshed.
utsles15ppcle:/etc/zypp/repos.d # zypper packages | grep Centrify
| centrify-rpm-suse | CentrifyDA | 3.7.0-172 | ppc64le
| centrify-rpm-suse | CentrifyDA | 3.6.1-324 | ppc64le
| centrify-rpm-suse | CentrifyDC | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC | 5.6.1-330 | ppc64le
| centrify-rpm-suse | CentrifyDC-cifsidmap | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC-cifsidmap | 5.6.1-330 | ppc64le
| centrify-rpm-suse | CentrifyDC-curl | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC-curl | 5.6.1-330 | ppc64le
| centrify-rpm-suse | CentrifyDC-ldapproxy | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC-ldapproxy | 5.6.1-330 | ppc64le
| centrify-rpm-suse | CentrifyDC-nis | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC-nis | 5.6.1-330 | ppc64le
| centrify-rpm-suse | CentrifyDC-openldap | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC-openldap | 5.6.1-330 | ppc64le
| centrify-rpm-suse | CentrifyDC-openssh | 8.2p1-5.7.0.207 | ppc64le
| centrify-rpm-suse | CentrifyDC-openssh | 7.9p1-5.6.1.329 | ppc64le
| centrify-rpm-suse | CentrifyDC-openssl | 5.7.0-207 | ppc64le
| centrify-rpm-suse | CentrifyDC-openssl | 5.6.1-330 | ppc64le
5. Install the Server Suite Agent rpm package.
# zypper install CentrifyDC
Note: To uninstall the Server Suite Agent rpm file, you can use the remove command. For example:
# zypper remove CentrifyDC
Debian Ubuntu
To set up and configure a Debian or Ubuntu repository
1. Create the repository:
You can manually create the repository or you can use a setup script to create the repository automatically.
_To create the Debian or Ubuntu repository configuration file manually
1. Update the /etc/apt/sources.list file to include the official Delinea package repository.
deb https://cloudrepo.centrify.com/URLTOKEN/deb/deb/debian any-version main /etc/apt/sources.list.d/centrify-deb.list
2. Import your GPG key and update the repository.
# bash -c 'wget -O - https://support.delinea.com/s/product-downloads/products/RPM-GPG-KEY-centrify | apt-key add -'
3. Comment out the no-debsig line in /etc/dpkg/dpkg.cfg to enable GPG signature validation.
# grep no-debsig /etc/dpkg/dpkg.cfg

# no-debsig
4. Clean and update the local archives.
# apt-get clean
# apt-get update
To create the Debian or Ubuntu repository configuration file automatically from a script
curl -1sLf 'https://cloudrepo.centrify.com/URLTOKEN/deb/cfg/setup/bash.deb.sh' | sudo -E bash
Note: Enter your Delinea repository URL token in place of URLTOKEN.
If you manually created your APT repository, the configuration details are in the /etc/apt/sources.list file. If you used the setup script to create the APT repository,
the configuration details are in a separate file such as centrify-deb.list in the /etc/apt/sources.list.d directory.
2. Execute the apt list command to verify the repository connection. You should see output similar to the following.
# apt list --all-versions | grep centrify

centrifyda/buster 3.7.0-172 amd64
centrifyda/buster 3.6.1-324 amd64
centrifydc-adbindproxy/buster 5.7.0-217 amd64
centrifydc-adbindproxy/buster 5.6.1-334 amd64
centrifydc-cifsidmap/buster 5.7.0-207 amd64
centrifydc-cifsidmap/buster 5.6.1-330 amd64
centrifydc-curl/buster 5.7.0-207 amd64
centrifydc-curl/buster 5.6.1-330 amd64
centrifydc-ldapproxy/buster 5.7.0-207 amd64
centrifydc-ldapproxy/buster 5.6.1-330 amd64
centrifydc-nis/buster 5.7.0-207 amd64
centrifydc-nis/buster 5.6.1-330 amd64
centrifydc-openldap/buster 5.7.0-207 amd64
centrifydc-openldap/buster 5.6.1-330 amd64
centrifydc-openssh/buster 8.2p1-5.7.0.207 amd64
centrifydc-openssh/buster 7.9p1-5.6.1.329 amd64
centrifydc-openssl/buster 5.7.0-207 amd64
centrifydc-openssl/buster 5.6.1-330 amd64
centrifydc/buster 5.7.0-207 amd64
centrifydc/buster 5.6.1-330 amd64
3. Execute the apt install or apt-get install commands to install Delinea packages. For example:
# apt install centrifydc centrifydc-nis

# apt-get install centrifydc-5.7.0-207
Note: To uninstall the Server Suite Agent for *NIX rpm, you can use the remove command to delete the Server Suite Agent for *NIX package or the
purge command to also delete any configuration files. For example:
# apt remove centrifydc=5.7.0-207
To Access a Raw Package (wget) Repository for Atomic
Use the WGET repository for Atomic packages or any raw or plain files such as *.zip, *.tar, *.tgz, and so forth .
1. Browse the package index to determine which file you want to download. You can view the package index in HTML or JSON:
HTML version is at https://cloudrepo.centrify.com/URLTOKEN/wget/raw/
JSON version is at https://cloudrepo.centrify.com/URLTOKEN/wget/raw/index.json
Note: Enter your Centrify repository URL token in place of URLTOKEN.
2. Download the desired file using either curl or wget. For example:
curl -1 -O 'https://cloudrepo.centrify.com/URLTOKEN/wget/raw/versions/Latest/CentrifyDC-atomic.x86_64.tgz'
or
wget 'https://cloudrepo.centrify.com/URLTOKEN/wget/raw/versions/Latest/CentrifyDC-atomic.x86_64.tgz'
To Set Up and Configure an Alpine Linux Repository
1. To configure the repository automatically, run the following commands:
sudo apk add --no-cache bash

curl -1sLf \ 'https://cloudrepo.centrify.com/URLTOKEN/apk/setup.alpine.sh' \ | sudo -E bash
Note: Enter your Delinea repository URL token in place of URLTOKEN.
2. Or, if you want to manually configure the repository, run the following commands:
curl -1sLf 'https://cloudrepo.centrify.com/URLTOKEN/apk/rsa.5DD8742729E6E4B2.key' > /etc/apk/keys/apk@centrify-5DD8742729E6E4B2.rsa.pub

curl -1sLf 'https://cloudrepo.centrify.com/URLTOKEN/apk/config.alpine.txt?distro=alpine&codename=v3.13' >> /etc/apk/repositories
apk update
When configuring the repository manually, you reference the Delinea public RSA key: apk@centrify-5DD8742729E6E4B2.rsa.pub.
1. Execute the apk add command to install the Server Suite packages. For example:
# apk add centrifydc centrifydc-nis
To uninstall the Server Suite Agent for *NIX rpm, you can use the del command to delete the Server Suite Agent for *NIX package. For example:
# apk del centrifydc=5.8.0-xxx
About the Files And Directories Installed on the Agent
When you complete the installation, the local computer will be updated with the following directories and files for the core Server Suite Agent for *NIX:
This directory Contains
/etc/centrifydc The agent configuration file and the Kerberos configuration file.
Kerberos-related files and service library files used by the Centrify Agent to enable group policy and authentication and authorization
/usr/share/centrifydc
services.
/usr/sbin /usr/bin Command line programs to perform Active Directory tasks, such as join the domain and change a user password.
/var/centrify Directories for temporary and common files that can be used by the agent.
Before joining the domain, the directory contains basic information about the environment, such as the IP address of the DNS server and
whether you installed licensed or express agent features. After you join the domain, several files are added to this directory to record
/var/centrifydc
information about the Active Directory domain the computer is joined to, the Active Directory site the computer is part of, and other
details.
Depending on the components you select during installation, additional files and directories might be installed or updated. For example, if you install
Enterprise Edition, the computer is updated with additional files and directories for auditing.
Joining an Active Directory Domain at a Later Time
At this point, you have delivered the software to target computers, but not changed their configuration. Users still have exactly the same access as they did
before installing Server Suite software. The computer's configuration changes only happen when the computer joins an Active Directory domain, that is,
joining the domain is what "activates" Server Suite software.
You have the option to automatically join an Active Directory domain when you install Server Suite Agents the install.sh script. In most cases, however, you
should not do so unless you have already planned your user migration and created your initial zones. Typically, it is best to analyze the user population and
prepare for migration before joining the domain to ensure minimal disruption of user activity and ease the transition to new software. Over time, as you
become more familiar with the migration process and refine your zone design, you can adapt the steps to suit your organization.
If you want to join the domain at the same time you deploy the Server Suite software, you should do the following before you install files on the UNIX
computers:
1. Download the Server Suite software for all platforms or the subset of platforms you intend to support.
2. Analyze existing user and group accounts.
3. Identify your zone requirements and create the initial zone design.
4. Migrate users and groups into the appropriate zones and role assignments.
5. Use the install.sh script or a custom script to install Server Suite Agents and join the domain.
The additional steps are described in the next sections. You can also manually join a domain at any time after installation by using the adjoin command.
Installing the Agent on Solaris Systems
This section covers information about installing the Server Suite Agent for *NIX on Solaris systems. The procedures differ depending on whether you're
installing svr4 or IPS packages. If you're installing IPS packages onto a system with Solaris 11 child zones, there's a separate procedure for that deployment.
For which packaged file to use for installation, refer to the table below.
Solaris version Package type x86 or Sparc Agent package filename
Solaris 10 svr4 x86 centrify-server-suite-2021.1-sol10-x86.tgz
Solaris 10 svr4 Sparc centrify-server-suite-2021.1-sol10-sparc.tgz
Solaris 11 IPS x86 centrify-server-suite-2021.1-sol11-i386.tgz
Solaris 11 IPS Sparc centrify-server-suite-2021.1-sol11-sparc.tgz
Installing the Solaris Svr4 Agent Packages
Download the solaris package appropriate for your Solaris system and run the install.sh script as mentioned in the "Install interactively on a computer"
section. You can follow the same procedure if you're installing on a system with or without child zones.
You can run the following command to verify the Solaris agent package svr4 installation status:
pkginfo | grep -i centrify
Note that there is no space between "pkg" and "info"; if you search for "pkg info" you'll be searching for IPS packages.
Installing the Solaris IPS Agent Packages
This procedure is for systems where you are doing a fresh install of Server Suite software onto a Solaris 11 system with IPS support.
This procedure is the same as for the regular install script, except that you run the install-ips.sh script, not the install.sh script -- see the "Install interactively on
a computer" section.
You'll need the centrify-infrastructure-services-VERSION-sol11-i386.tgz file or the centrify-infrastructure-services-VERSION-sol11-sparc.tgz file for this procedure,
depending on the type of system you have.
To install the Solaris IPS packages
1. Download the Server Suite package for your version of Solaris.
2. Extract the Server Suite packages onto the system.
3. Run the install-ips.sh script. For example:
./install-ips.sh
want to:
Perform a default installation.
Perform a custom installation by selecting the specific packages to install.
Join a domain automatically at the conclusion of the installation.
Depending on your selections, you may need to provide additional information, such as the user name and password for joining the domain.
5. You can run the following command to verify the Solaris agent package IPS installation status:
pkg info | grep -i centrify
Note the space between "pkg" and "info"; if you search for "pkginfo" you'll be searching for svr4 packages.
Installing the Solaris IPS Agent Packages With Child Zones
When you install the agent onto a Solaris 11 computer enabled with IPS that also has one or more child zones configured, you need to import the agent
packages into a new repository and then install directly from the repository.
You do this install in the global zone and the repository will automatically install the files into the child zones.
You'll need the centrify-infrastructure-services-VERSION-sol11-i386.tgz file or the centrify-infrastructure-services-VERSION-sol11-sparc.tgz file for this procedure, depending on the
type of system you have.
To install the Solaris IPS agent packages onto a system with one or more child zones
1. Create a directory and extract the IPS tgz file into that directory.
For example, create directory called "install-ips" and extract the contents of the tgz file into that directory.
1. Create a repository:
For example, run the following command to create a repository called "my-repo":
T i p: You can run the zfs list command to list all of the zone file systems.
zfs create rpool/export/my-repo
zfs set atime=off rpool/export/my-repo
pkgrepo create /export/my-repo
pkgrepo set -s /export/my-repo publisher/prefix=centrify
pkgrepo -s /export/my-repo refresh
pkgrepo -s /export/my-repo info
pkg set-publisher -G '*' -M '*' -g /export/my-repo centrify
pkg publisher
You should see the repository listed.
PUBLISHER TYPE STATUS P LOCATION

centrify origin online F file:///export/my-repo
2. Import the packages into the repository. You need to import the packages that end with .p5p and you need to import them one at a time.
1. In the directory where you extracted the Server Suite Agent packages, list out the files in that directory (use the ls command).
The full package list of files that you need to import into the repository looks something like this:
centrifyda-3.7.0-sol11-i386.p5p
centrifydc-5.7.0-sol11-i386.p55
centrifydc-curl-5.7.0-sol11-i386.p5p
centrifydc-ldapproxy-5.7.0-sol11-i386.p5p
centrifydc-nis-5.7.0-sol11-i386.p5p
centrifydc-openldap-5.7.0-sol11-i386.p5p
centrifydc-openssh-5.7.0-sol11-i386.p5p
centrifydc-openssl-5.7.0-sol11-i386.p5p
2. Import each package into the repository.
For example, if you're installing all 8 packages, you'll run the following 8 commands:
pkgrecv -s centrifyda-3.7.0-sol11-i386.p5p -d /export/my-repo '*'
pkgrecv -s centrifydc-5.7.0-sol11-i386.p55 -d /export/my-repo '*'
pkgrecv -s centrifydc-curl-5.7.0-sol11-i386.p5p -d /export/my-repo '*'
pkgrecv -s centrifydc-ldapproxy-5.7.0-sol11-i386.p5p -d /export/my-repo '*'
pkgrecv -s centrifydc-nis-5.7.0-sol11-i386.p5p -d /export/my-repo '*'
pkgrecv -s centrifydc-openldap-5.7.0-sol11-i386.p5p -d /export/my-repo '*'
pkgrecv -s centrifydc-openssh-5.7.0-sol11-i386.p5p -d /export/my-repo '*'
pkgrecv -s centrifydc-openssl-5.7.0-sol11-i386.p5p -d /export/my-repo '*'
3. You can verify that the packages imported correctly by listing out the repository packages.
For example, run the following command:
pkgrepo list -s /export/my-repo
You'll see a list of packages where each package has a long version. For example:
centrify security/centrifydc 5.7.0.207:20200726T052946Z
3. Install the packages from the repository into the parent and child zones.
Be sure to reference the package's entire version. When you install the centrifydc package, the other packages for cURL, OpenLDAP, and OpenSSL are
also installed.
For example, to install centrifydc, you'd run the following command, :
pkg install -r security/centrifydc@5.7.0.207:20200726T052946Z
For example, to install all the packages with one command, you'd run something like this:
pkg install -r security/centrifydc@5.7.0.207:20200726T052946Z security/centrifydc-ldapproxy@5.7.0.207:20200726T053320Z security/centrifydc-nis@5.7.0.207:20200726T053352Z

security/centrifydc-openssh@5.7.0.207:20200727T065442Z security/centrifyda@3.7.0.171:20200725T014652Z
Uninstalling the Agent on Solaris Systems
To uninstall the Solaris svr4 packages
1. In the directory where you have downloaded and extracted the Centrify Agent packages, run the following command:
./install.sh -e -n
2. You can run the following command to verify the Solaris agent package svr4 installation status:
pkginfo | grep -i centrify
To uninstall the Solaris IPS packages
1. In the directory where you have downloaded and extracted the Server Suite Agent packages, run the following command:
./install-ips.sh -e -n
To uninstall the Solaris IPS packages on systems with one or more child zones
1. To uninstall a single package from both parent and child zones, run the following command:
pkg uninstall -r packagename
For example, to uninstall only the CentrifyDA package, run the following command:
pkg uninstall -r security/centrifyda
To uninstall more than one package or all installed packages, enter the package names separated by a space. For example:
pkg uninstall -r security/centrifyda security/centrifydc-curl security/centrifydc-ldapproxy
Sun Solaris Installation Notes
This section describes the unique characteristics or known limitations that are specific to using authentication service on a computer with the Solaris
operating environment.
Changing the Local User Password on Solaris
On Solaris, the passwd command is designed to update the databases listed in the nsswitch.conf file or the specific repositories you indicate with the -r option.
Therefore, by default, you can use passwd command without any command line options to update your password wherever necessary.
Once you install authentication service and join the domain, however, Active Directory becomes the primary repository for user account information and
changing the password for any local user account you need to maintain outside of Active Directory requires you to explicitly specify the repository to update
with the -r option.
For example, if you want to change the password for a local user account in /etc/passwd, you must specify the files repository when you run the passwd
command:
passwd -r files user
If you want to update the password for an Active Directory user account, you can use the passwd command without the repository option on Solaris 10. For
example:
passwd adusername
If you are using an earlier version of the Solaris operating environment, however, you must use the adpasswd command that is installed with authentication
service to update the password for Active Directory user accounts. For information about using adpasswd, see the adpasswd man page or the Administrator's
Guide for Linux and UNIX.
Installing Authentication Service Packages into Solaris 10 Zones
All zones should be up and running during an upgrade from a previous release of Server Suite Authentication Service and its add-on packages (for example
sudo or Server Suite for Web Applications) should not be installed directly into a sparse zone, they should be installed from the global zone only.
Installing Authentication Service Packages into Solaris 11 Child Zones
You need to install SVR4 packaging tools in the child zone before authentication service can be installed.
To check if the SVR4 package has been installed, run
$ pkg info svr4
If it is not installed yet, run the following to install it:
$ pkg install pkg:/package/svr4
Note that the command above may need internet connection (depends on how the IPS repository is configured in the zone).
Creating a Home Directory for New Users on Solaris
In most operating environments, when new users log on successfully, the authentication service will automatically create the user's home directory. On
Solaris, however, the home directory is typically auto-mounted over NFS, so the option to automatically create a new home directory for new users is off by
default. You can turn on this feature, if suitable to your environment, by adding the following to /etc/centrifydc/centrifydc.conf:
pam.create.homedir: true
With this flag, the first time a user logs in the home directory will be created. The user will see the message "Failed to create home directory", but this can be
ignored.
In Express mode use auto.schema.homedir to specify the home directory for users. Use % as a placeholder for a user's name.
For example:
auto.schema.homedir: /export/home/${user}
Planning to Use Server Suite Zones
One of the most important aspects of managing computers with Server Suite software is the ability to organize computers, users, and groups into zones.
This section discusses the primary reasons for using zones and provides an overview of how to analyze and migrate an existing user population into zones,
including an introduction to assigning roles that enable users to access computer resources. These topics will then be described in greater detail in the next
sections to help you create an initial zone structure and migrate users and groups for a target set of computers.
Why Use Zones?
A zone is similar to an Active Directory organizational unit (OU) or NIS domain. Zones allow you to organize the computers in your organization in meaningful
ways to simplify the transition to Active Directory and the migration of user and group information from existing identity stores. The primary benefits to using
zones are:
Identity management through user and group profile definitions

Access and authorization control through rights and role definitions
Delegated computer management for zone-based administrative tasks
Zones also enable you to centrally manage configuration policies for computers and users through group policies, but for most organizations the key
considerations for designing a zone structure involve:
Identity management because zones enable you to migrate from a complex UID space, where a user can have multiple UIDs or different profile
attributes on different computers or a single UID might identify different people depending on the computer being used. With zones, you can associate
multiple UNIX profiles with a user and identify the correct profile attributes for any user on any given computer.
Access and authorization management because zones enable you to grant specific rights to users in specific roles on specific computers. By assigning
roles, you can control who has access to which computers.
Delegated computer management because zones enable you to assign specific administrative tasks to specific users or groups on a zone-by-zone
basis, allowing you to establish an appropriate separation of duties. With zones, administrators can be given the authority to manage a given set of
computers and users without granting them permission to perform actions on computers in other zones or access to other Active Directory objects.
In most organizations, the first goal in designing the zone structure is to migrate users and computers from an existing identity store, such as NIS, NIS+, local
files, or LDAP, to Active Directory and to do so with the least possible disruption to user activity, business services, and the existing infrastructure. Over time,
you can also use zones to organize computers along departmental, geographical, or functional lines using whatever strategy works best for your
organization.
Although Server Suite supports a workstation mode that does not require you to create and manage zones—a single Auto Zone is defined instead—most
organizations find using zones to be an essential part of their migration to Active Directory. The next sections provide more information about why zones are
an important part of the planning process. For more information about using Auto Zone, see Deploying to a single Auto Zone.
Identity Management Using Zones
For most organizations, it is impractical to attempt to rationalize user accounts across the enterprise to achieve a single global UID for each user. For
example, most organizations have multiple identity stores already in use on their current UNIX platforms. These identity stores may include LDAP directories,
NIS or NIS+ domains, and local /etc/passwd and /etc/group configuration files. With these multiple identity stores, it is common for a single user to have a
different user name, UID, group memberships, or other attributes defined for different computers.
Zones allow you to import the information from these legacy identity stores without consolidating the multiple profiles that each user may have. For example,
a single user might have an account in a UNIX LDAP directory, another defined in a NIS domain, and one or more local /etc/passwd files. Zones enable the
profiles from these different identity stores to map to a single Active Directory user account without changing the user profile defined in each of the legacy
directories. By keeping the profiles intact, the user’s file ownership and log in permissions are not affected by the migration to Active Directory, making the
transition from a legacy system to Active Directory more transparent to end users and less of a management burden for the deployment team.
Role-based Access Control and Zones
As a practical matter, you may choose to use Server Suite zones to ease migration to Active Directory by creating a separate zone for each legacy identity
store. However, you can also use zones to group computers by department, by function, or by any other criteria you choose. Using zones in this way gives you
a great deal of flexibility in controlling who has access to the UNIX, Linux, and Mac OS X computers in your environment and makes it easier to set up account
information for new users based on job function or other criteria.
Through role assignments, zones provide a scope of resources particular users can access, allowing you to define who can do what on which computers. For
example, all of the computers in the finance department could be grouped into a single zone called “finance” and the members of that zone could be
restricted to finance employees and senior managers, each with specific rights, such as log on to a database, update certain files, or generate reports. This
gives you better control over access to systems based on well-defined roles. You can also limit access to certain types of applications, such as database
management utilities or web services. For example, you can define specific actions specific users are allowed to perform by assigning them different roles in
different zones.
Using Zones to Delegate Administrative Duties
Zones can also be useful for grouping computers that form a natural administrative set or that should be managed by different administrative teams. For
example, you may want to group computers that are managed by a local support organization in one zone and computers that are managed by a corporate IT
group in another zone.
Using zones, you can then control what different groups of users can do within the zones they have permission to access. For example, you can set up
regional zones to provide a separation of duties, authorizing users in San Francisco to manage computers and user profiles in their local office while a team in
Barcelona has authority to join computers and manage group profiles for offices located in Spain.
Zones provide a convenient way for you to assign individual administrative responsibilities to specific users or groups based on a set criteria, such as
department, geographic location, or functional role.
Deploying to a Single Auto Zone
In most cases, if you are deploying on Linux or UNIX computers and have an existing user population to migrate to Active Directory, you would create a
hierarchical zone structure of multiple zones. However, multiple zones are not required for all situations. You can greatly reduce the time required and
complexity of your deployment if a single zone suits your organization’s needs. For example, if you are deploying on Mac OS X or Windows computers or if you
have a mix of computer platforms but do not have an existing user population to migrate, you might benefit from deploying agents using the Auto Zone option.
With Auto Zone, you have a single zone for an entire forest. All of the users and groups you have defined in Active Directory for the forest automatically
become valid users and groups on the computers that join the Auto Zone. If the forest has a two-way trust relationship with another forest, all Active
Directory users defined in that trusted forest are also automatically valid on computers that join the Auto Zone.
If you simply want to use the Active Directory users and groups you have already defined on the nonWindows computers you manage, you can skip the
planning and creation of zones and simply add computers to the Auto Zone when you join the domain. The UNIX profile attributes that are required to access
computers in the Auto Zone are then automatically derived from user attributes in Active Directory or from settings defined in group policies or configuration
parameters.
Note: You cannot use Auto Zone to give automatic access to users and groups in a forest or domain with a one-way trust relationship with another
forest or domain.
You can use Auto Zone without enabling any group policies or changing any of the default configuration settings. You can also join a domain through the Auto
Zone without installing Access Manager. However, you can use group policies or configuration parameters to specify a subset of Active Directory users or
groups as valid Auto Zone users. The settings are then enforced on computers in the Auto Zone.
Using Auto Zone can make sense in small or larger organizations if you are not migrating existing users and groups or maintaining legacy UNIX profile
attributes. However, if you use Auto Zone, you cannot use zone-specific features. For computers in the Auto Zone, you cannot configure rights and roles,
assign roles to users and groups, or provide different profile attributes on different computers.
For information about joining a domain using Auto Zone, see the man page for adjoin or the Administrator’s Guide for Linux and UNIX. For information about
using group policies or configuration parameters, see the Group Policy Guide or Configuration and Tuning Reference Guide.
Classic and Hierarchical Zones
If you plan to deploy using zones—which is the most common deployment model—you have to option to create classic or hierarchical zones. Classic zones
provide a simple model for organizing computers and backwards compatibility for organizations with older versions of the Server Suite Agent. Hierarchical
zones enable you to establish parent-child zone relationships, allowing profile attributes, rights, and roles to be inherited down the zone hierarchy. Classic
zones are peers to each other and do not inherit profile attributes, rights, or roles from each other.
One of the first decisions you need to make in planning your zone structure is whether you will use classic zones, hierarchical zones, or some combination of
both.
Should You Use Classic Zones?
Classic zones provide a simple structure for delineating users and groups based on a criteria you choose, such as by region or department. They are most
appropriate if you have a well-defined and well-managed UNIX namespace with very few users who require special handling because of multiple profiles or
conflicting profile attributes.
Classic zones are simple to manage as long as you only need a few. For example, imagine you have three regional zones with no users in common that are
managed independently by their own zone administrators with only one enterprise system administrator who must have a profile in each zone. In that
scenario, classic zones provide a simple solution because only one user account, the enterprise system administrator, must have a profile in each zone.
However, classic zones are very limited in complex environments where users need profiles in multiple zones or where there are multiple independently-
managed UNIX namespaces to migrate to Active Directory. That is because classic zones do not share data across zone boundaries. The data must be
created and managed in each zone independently. By contrast, hierarchical zones support inheritance, enabling you to create parent and child zones that
share information as needed. Because classic zones do not support inheritance, you cannot use variables to define profile attributes or any other hierarchical
zone features.
For most organizations, classic zones are primarily used to enable a new zone that works with pre-5.0 versions of the Server Suite Agent. If you have an older
version of Server Suite software installed and already have some zones deployed in your environment, you can continue to use those zones as-is. After
upgrading, you then have the option to create any new zones as classic zones to operate within the legacy zone environment or as hierarchical zones.
Note: If you already have zones deployed, you can convert them to hierarchical zones after you deploy the new version of Server Suite software, if
you choose to do so. However, there’s no requirement for you to convert existing zones to hierarchical zones.
When Should You Use Hierarchical Zones?
For most organizations, Server Suite recommends that you use hierarchical zones for all new zones that you create. Hierarchical zones provide greater
flexibility to inherit profile information, rights and role definitions, and user and group role assignments.
Because hierarchical zones allow you to share or override information at any point in the hierarchy, they also allow you to design a simpler zone structure than
classic zones and support an easier deployment model. Typically, a simpler zone structure is easier to manage, but hierarchical zones also allow you to
implement a very sophisticated zone structure to address complex access control rules, if you so choose.
How Many Zones Do You Need?
The goal in planning to use zones is to have a fairly small number of zones that organize the computers and users in your organization most effectively. As an
example, consider an organization where some UNIX computers are used to host financial applications. Those computers are centrally managed by the IT
organization, which follows well-established conventions for issuing user login names, user IDs, and home directories. The same organization has a software
development group that includes numerous UNIX workstations that are not centrally managed by the IT organization and computers and accounts are added
when needed and managed independently.
Because enterprise-wide conventions are not enforced for the UNIX computers in the software development group, it’s possible that the local login names
and user IDs may conflict with the names and IDs used on the computers running the financial applications. In addition, users in the software development
group may use a different convention for their home directories or prefer different login shells.
Without zones, the IT organization would need to eliminate any duplicate user IDs and verify each login name was unique across all of the computers. By
placing the computers running the financial applications in one zone and the computers in the development lab in another zone, the IT organization can avoid
the overhead of checking and changing existing account information and can set default zone settings, such as different default home directories or login
shells, that are most appropriate to the users in each zone.
There are many different approaches you can take to defining the scope of a zone, including organizing by platform, department, manager, application,
geographical location, or how a computer is used. The factors that are most likely to affect your initial zone design, however, will involve migrating user and
group profiles, identifying the appropriate access control policies and role assignments, and delegating administrative tasks to the appropriate users and
groups. For many organizations, the most important issue during the initial deployment is a successful migration of existing users. Using hierarchical zones
with the ability to override attributes simplifies this task, helping to reduce the total number of zones you need to deploy.
A Closer Look at Using Zones in a Hierarchical Model
In older versions of Server Suite software, zones were always parallel with each other and did not share or inherit data except through manual processes.
Starting with Infrastructure Services 2012, however, you have the option to use hierarchical zones that support the inheritance of user and group data and
provide a great deal of flexibility for defining the rights and roles for who can access which computers and what those users can do on the computers to which
they have access.
How Inheritance Provides Additional Benefits
As discussed in Why use zones?, the primary benefits to using zones are:
Identity management through user and group profile definitions

Access and authorization control through rights and role definitions
Delegated computer management for zone-based administrative tasks
Hierarchical zones provide additional flexibility for each of these benefits. For example, because hierarchical zones allow inheritance, hierarchical zones
enable you define partial profiles and use variables that can be substituted at run-time when a user accesses a specific computer in a particular zone.
Hierarchical zones also enable you to define access control rules and delegate administrative tasks at any point in the zone hierarchy.
This flexibility makes planning for hierarchical zones a key component of a successful deployment.
How Many Levels Should You Use in the Zone Hierarchy?
There are no predefined limits to the number of zones that can be used in a zone hierarchy or the number of levels deep zones can be nested in the hierarchy
you define. For practical purposes, however, it is recommended using a hierarchy similar to the following:
One or more top-level parent zones that include basic profile information for all users and groups that access the UNIX, Linux, and Mac OS X
computers.
One to three levels of intermediate child zones based on natural access control or administrative boundaries.
At each level in the hierarchy, profile information and access controls are inherited from the zone above and either applied or overridden by the child zone
settings. At the lowest level of the hierarchy, you can override profile attributes or role assignments on any individual computers using machine override
settings, if needed.
In addition, hierarchical zones support computer-based access rules, called computer roles, that enable you to selectively map a set of users with a
particular role assignment access to a particular set of computers.
Identity Management and Inherited Profile Information
User and group profiles specify attributes such as the UID, primary group, home directory, and shell that are required for logging on to UNIX computers. You
can specify all or part of the profile anywhere in the zone hierarchy, but users must have a complete profile to access computers they have permission to
access. If the user or group profile is incomplete, it is invalid and ignored.
Working with Partial Profiles in the Zone Hierarchy
The profile information in the zone hierarchy is resolved from top to bottom for each user. For example, assume the user Pat Jackson has the login name patj
and UID 12000 defined in the parent zone arcade_global and those profile settings are inherited without change, along with a default shell, home directory
and other properties that are defined in the child zone arcade_web_dev. In a second child zone, arcade_aix, the UID for patj is set to 7088 to override the
inherited UID. Changes to the profile properties can be made in any zone and inherited down the tree down to overrides set for specific individual computers,
if needed.
Working with Variables in the Zone Hierarchy
Partial profiles enable you define a subset of profile attributes for users and groups that can be completed by lower level zones in the zone hierarchy. You can
also define variables for resolving profile attributes. The variables are then substituted at run-time by adclient. For example, adclient can resolve the variable
%/% to a platform-specific home directory for each user without having the attribute manually defined. You can set the variables at any level in the zone
hierarchy, and they are inherited and resolved, or can be overridden, at a lower level in the tree.
You should note that variables can only be used to define profile attributes in hierarchical zones. You cannot import them or use them in classic zones.
Complete Profiles Do Not Grant Access
Creating user profiles in a zone does not give users access to any computers in the zone. The zone hierarchy simply creates a set of profiles with the potential
to be granted access to computers. In previous versions of Server Suite software, enabling a UNIX profile for a user in a zone granted that user access to the
computers in that zone by default. With hierarchical zones, the profile information only establishes the required properties for the user’s identity, but does not
grant access to any computers in any zones.
Access to computers is controlled through the definition of rights and roles.
Access Controls and the Assignment of Rights and Roles
A user must have a complete UNIX profile to log on to any computer in a zone. However, a complete profile alone does not allow a user to access any
computers. The user must also have at least one role assignment that grants access somewhere in the zone hierarchy before any type of access is granted.
Role assignments can be made anywhere in the zone hierarchy and inherited at a lower level in the tree.
Understanding Roles and Rights
Rights represent specific operations users are allowed to perform. A role is a collection of rights that can be defined in a parent or child zone and inherited.
For example, a role defined in a parent zone can be used in a child zone, in a computer role, or at the computer level.
There are only a few predefined rights, called system rights. The system rights for Linux, UNIX, and Mac OS X are:
Password login and non password (SSO) login are allowed: Specifies that a user is allowed to log on interactively using a password or without
a password using a single sign-on token.
Non password (SSO) login is allowed: Specifies that a user is allowed to log on using a single sign-on token.
Account disabled in AD can be used by sudo, cron, etc.: Specifies that an account that is disabled is allowed to access the computer. This
right enables service accounts that run without a password to perform operations.
Login with non-Restricted Shell: Controls whether a user gets a full shell or is forced into a restricted shell. Users must be assigned at least one
role with this right to have access to a standard shell environment. A restricted shell only allows a user to execute explicitly defined commands.
The system rights for Windows computers are:
Console login is allowed: Specifies that users are allowed to log on locally using their Active Directory account credentials.
Remote login is allowed: Specifies that users are allowed to log on remotely using their Active Directory account credentials.
In addition to the platform-specific system rights, there is a common system right that allows users to bypass auditing or role restrictions to log on when
there are problems on a computer. The Rescue rights option allows you to specify the users who can log on if problems with the authorization cache or the
auditing service on a computer are preventing all other users from logging on.
You grant users permission to access computers by assigning them to a role that includes one or more access rights. By default, zones only contain the
following predefined roles to grant basic access rights:
UNIX Login role allows users assigned this role to log on and access UNIX computers in the zone.
Windows Login role allows users assigned this role to log on and access Windows computers in the zone.
There are additional predefined roles that grant specific rights, such as the right to log on if auditing is required but not available. The predefined roles exist in
each zone, but their role names are qualified by the zone name so that the same role name in a parent zone and a child zone are considered different roles. For
deployment, the predefined roles enable you to migrate existing users without developing custom role definitions. After deployment, you can define
additional rights, roles, and role assignments to refine how users and groups access computers in different zones.
Working with a Candidate Set of Profiles
Ultimately, the purpose of the zone structure is to determine who has access, and what kind of access, to a computer. The candidate set of profiles that have
the potential to access a computer is resolved by traversing the zone hierarchy from top to bottom. Because profile data is defined separately from the role
assignments that control access, you can define an inclusive set of user profiles in a parent zone to create a candidate set that can then be applied to
multiple child zones. In each child zone or at the individual computer level, you can use role assignment to control access for specific users from the inclusive
candidate set.
Delegation in Hierarchical Zones
Hierarchical zones enable you to create a separation of duties for zone administration without recreating user and group profiles in multiple child zones. You
can create full or partial profiles in the parent zone and inherit them into the child zone. Within each child zone, zone administrators can modify the profiles,
as needed, and assign roles to control access to the computers they manage.
Designing a Zone Structure for Your Environment
Because the flexibility of hierarchical zones is a key element in designing the zone structure for your deployment, the next sections describe how to set up
and use parent and child zones through sample deployment scenarios. The scenarios illustrate a basic deployment model, which will then be used to discuss
how to migrate existing users and groups to Active Directory.
Your own zone structure and deployment model can be more complex than the one described in this guide. However, the deployment model described in the
next sections is intended to ensure that you have a successful initial deployment. Over time, it is likely that you will change and adapt the zone structure to
requirements that are specific to your organization. There are also multiple ways to accomplish the tasks described in the next sections of this guide. You can
use other strategies and techniques for deployment if appropriate for your organization.
Preparing To Migrate Existing Users And Groups
This section describes how to prepare your environment for migration and computer access, including how to create and configure the initial zones. This
chapter also describes how to import existing account information into Active Directory, set up provisioning for new users and groups, and configure role-
based access controls.
Collecting And Analyzing Users and Groups
Before you create any zones, you should collect and analyze information about existing users and groups in the target set of computers. After you have
investigated user and group attributes and identified invalid accounts and conflicting attributes, you can draft a basic zone design that addresses the needs
of that user population. The goal of the initial zone design is to provide access to those users who currently have access, so they can transition to Active
Directory with no disruption to their work. Later, you can refine access to computers through role assignments, filtering, and other options, if needed.
Collecting Information from Other Departments in Your Organization
Before you look at the content of identity stores you want to migrate, you should consider other sources of information that will help you identify a definitive
set of legitimate users. For example, it can be useful to contact people in other departments who have reliable knowledge about the current organization or
historical knowledge about how the organization has evolved. Individuals with information about a segment of the user population can help you identify
accounts that are obsolete or were created for testing, or belong to users who have left the company or moved to another department.
As a starting point for collecting information about existing users and groups, consider doing the following:
Contact HR to get an up-to-date list of current active-duty employees, contractors, and consultants. You can use this information to compare
personnel records to the UNIX accounts to be migrated. After you identify which accounts correspond to people in the organization, you can create a
spreadsheet to record the UNIX user names, UIDs, and other useful fields for those accounts.
Contact enterprise security administrators or department-level UNIX administrators to determine whether all of the accounts defined for a computer
still need access to that computer. For example, you should determine if any users validated as current employees have changed departments or job
functions. If a user no longer needs access to some computers, you may not need to add a profile for that user.
Identify any conventions used in defining the namespace. For example, is there a standard format for the contents of the GECOS field? How do the
conventions used for UNIX, Linux, or Mac OS X accounts compare to the conventions used in Active Directory? For example, is the convention used for
the UNIX login name the same as the convention used for the user’s sAMAcountName in Active Directory? Does the GECOS field follow the same
conventions as the user’s displayName in Active Directory?
Identify which user attribute fields that can be used as primary keys for identifying a unique user. Depending on the conventions you use for creating
new accounts, the user name, user identifier (UID), or the GECOS field may be a reliable field for identifying real users and mapping them to Active
Directory accounts. If you use a standard provisioning convention across platforms for an attribute such as the GECOS field or user name, the
convention makes it much easier to identify unique users and map user profiles to Active Directory accounts.
Using a Script to Retrieve User and Group Profiles for Each Computer
Alternatively, you can write a script to retrieve all of the /etc/passwd and /etc/group files in the target set of computers. For example, to create a
hostname.passwd and hostname.group file for each computer in a target set of computers, you might use code similar to the following:
for name in `cat hostname.txt`; \

do scp $name:/etc/passwd $name.passwd; \
scp $name:/etc/group $name.group; \
done
This sample script includes the computer host name in the file name, so that you can determine which user and group definitions came from which computer.
If you use a script to collect user and group information, copy all of the files generated by the script to a common location for analysis.
Collecting Data from NIS Domains
If you’re migrating users and groups from a NIS domain, you can use ypcat or niscat to generate a copy of the NIS passwd and group maps once for each NIS
domain. For example, run commands similar to the following:
ypcat passwd > `domainname`.passwd

ypcat group > `domainname`.group
If you are collecting user and group information from NIS maps, copy all of the files generated by these commands to a common location for analysis.
Identifying Accounts that Should Not Be Migrated
After you have collected information about the existing users and groups in the target set of computers, examine each of the passwd and group files and NIS
domain maps to create a list of users and groups that you do not plan to migrate into Active Directory. For example, in most cases, there’s no compelling
business reason to migrate default system accounts, such as nfsnobdy or games, that will not map to Active Directory users. You should also eliminate
accounts for people who have left your organization, and accounts that are locked or obviously invalid.
Eliminate Default System Accounts
In most cases, you can ignore all UNIX users with a UID less than 99 because those are the default operating system accounts. You may also want to skip
migration for some or all UNIX service accounts unless you explicitly want to manage those service accounts, and any privileged commands they run, through
Active Directory and zones.
You can manage the passwords for UNIX service accounts using Access Manager without having those accounts defined in zones or in Active Directory.
Therefore, you may want to leave most or all of the service accounts as locally defined accounts.
In general, the only reasons to migrate default system or service accounts to Active Directory are:
If you want to use Active Directory password policies for the account.
If the service account itself owns one or more privileged commands that you want to manage through Centrify role definitions rather than locally in the
sudoers file.
Typically, only service accounts that own special permissions, such the oracle user account, are migrated to Active Directory.
Remove Other Invalid Accounts
You should also skip migration for users who have left the organization and profiles that contain invalid data. Scan the data set for user accounts and groups
that are locked or indicate they were created for testing. You should also check for profiles that contain obvious errors or legacy information no longer used.
In some cases, you may need to contact workstation or application owners directly to determine whether a profile should be skipped for migration. For
example, assume the /etc/group file contains an entry for clowns with krusty, bozo, and tadams as members and there are valid user profiles for those three
users. You may suspect the clowns group was created for some local testing, and therefore, not a candidate for migration. However, there’s no definitive
indication that the clowns group should be skipped without more information.
Create a List of the Users and Groups to Ignore
Add all of the accounts that should not be migrated to a text file. For example, create a text file named user.ignore and include all of the user accounts you
don’t want to migrate into Active Directory. For default system and service accounts that have known UIDs, you can create the text file programmatically
using code similar to the following:
cat *.passwd | \egrep "x?:[0-9]:[0-9].|x?:[0-9][0-9]:[0-9].|x?:60[0-9][0-9][0-9]:[0-9]|x?:65[0-9][0-9][0-9]:[0-9]" | \

cut -d ":" -f 1 | \
sort | \
uniq | \
sed 's/^/\^/' > user.ignore
Other accounts you have identified as invalid can be added manually or using code if they share some common attribute, such as LOCKED in the password
field.
Analyze User Profiles for Conflicting Attributes
After the initial analysis to remove profiles that should not be migrated, you have a candidate data set of users and groups to import. The next step is to
analyze the attributes in user profiles to identify any potential problems that you will need to address when you move the profiles into zones. Delinea
Professional Services offers scripts that assist in this process. If you are analyzing the files manually or writing your own scripts, here are the common issues
you need to check for:
Determine whether any user name has more than one UID in the target set of computers. The UID is the primary way of determining file ownership and
file permissions. On a single UNIX system, a user can only have one UID. However, across all of the computers in the target set, the same user name
might have more than one UID.
Determine whether any UIDs are associated with more than one user name.
Determine whether any users have other profile conflicts, such as more than one primary GID, home directory, or shell on the computers in the target
set.
In doing your preliminary analysis, keep in mind that you need to know which user profiles are associated with which people in your organization. For example,
do the user names ldavis and davle refer to the same person (Len Davis) or to different people (Len Davis and Leslie Davidson).
This analysis of existing user profiles will help you identify the requirements of your initial zone design. The zone design allows you to use conflicting
attributes as-is, without modifying any of the legacy data. You need to be aware of where there are conflicts so you can address them, but you do not need to
change values for any attributes.
Analyze Group Profiles for Conflicting Attributes
You need to perform a similar analysis across the groups in the target set of computers. Delinea Professional Services offers scripts that assist in this
process. If you are analyzing the files manually or writing your own scripts, here are the common issues you need to check for:
Determine whether any group name has more than one GID in the target set of computers. Like the UID, the GID affects file ownership and file
permissions. On a single UNIX computer, a group name can only have one GID. However, across all of the computers in the target set, the same group
name might have more than one GID.
Determine whether any GIDs are associated with more than one group name.
Determine whether any group has a different set of members on any computers in the target set. Group membership is particularly important for zone
design. The members of a group must be consistent across all of the computers in a zone.
As with the user analysis, this analysis of existing group profiles will help you identify the requirements of your initial zone design. The zone design allows you
to use conflicting attributes as-is, without modifying any of the legacy data. You need to be aware of where there are conflicts so you can address them, but
you do not need to change values for any attributes.
Create a Working Set of User and Group Profiles
After you have identified profiles that should not be migrated and noted any conflicting attributes you need to address, you have a known set of user and
group profiles that you plan to migrate into Active Directory. The next step is to remove the users who should be ignored from list of users to import, and to
remove the groups that should be ignored from the list of groups to import. You can do this manually or write a script that removes the profiles defined in the
user.ignore and group.ignore files and outputs the results to a new file. For example, you might use code similar to the following to remove ignored users and
generate a working set of user profiles:
mkdir output; \
for name in `cat hostname.txt`; \
do egrep -v -f user.ignore $name.passwd > \output/$name.passwd; \
done
How Migration Affects the Zone Design
As discussed in Why use zones?, identity management is one of the primary benefits of using zones. Identity management is important because most
organizations have an existing user population where users can have multiple UIDs or other attributes, such as different default shells, on different
computers and groups with the same name can have different members. Each user has one Active Directory user object but may have multiple UNIX profiles,
some with attributes in common and some with different settings. Zones allow you to migrate the profile information as it is defined, setting overrides where
necessary, so that you can manage and report on the accounts without rationalizing the user namespace.
For all of the computers in a zone, a user or group has one profile definition, but the user or group could have different profile attributes on the computers in a
different zone. Hierarchical zones make the zone design even more flexible. Hierarchical zones allow you to define one or more profile attributes in a parent
zone and use those profile attributes in all child zones. In practice, this enables you to define a dominant set of attributes in a parent zone, and inherit the
common attributes in one or more child zones. You can also override any attribute at any point in the zone hierarchy down to an individual computer.
For example, if a UNIX administrator has a consistent profile across all of the UNIX computers, but a customized home directory on two Mac OS X computers,
you could define the default profile for the user in a parent zone, then create a child zone for the Mac OS X computers and inherit all of the profile attributes
except the home directory setting.
In planning the migration, you identify the attributes that are the same across the target set of computers and where there are differences. If you use
hierarchical zones, the primary task is identify one or more potential parent zones. For example, if you are migrating two NIS domains, you might create two
parent zones because the UID space is unique in each domain but there would be conflicting attributes if the domains were combined into a single parent
zone. The computers in each of the parent zones would inherit the UID and other profile attributes from each distinct NIS domain.
After you have identified one or more parent zones, you can plan how you will use child zones and overrides to manage profile attributes, implement access
controls, and delegate administrative duties.
Creating the First Zone
It is recommended that you plan to use hierarchical zones and create at least one top-level parent zone. A single top-level zone for your organization is also
useful for long-term management of UNIX profiles. You can have more than one top-level parent zone. For example, if your organization has subsidiaries that
are run independently or distinct geographical locations managed by different teams, you may want to create separate parent zones for those lines of
business or locations.
Having a single top-level parent zone enables you to create an administrative group of super-users who can log on to every UNIX computer in your
organization. It also allows to define some common rights and roles that can be inherited by child zones and the computers in those zones. Having a global or
master zone for the entire organization also simplifies setting up provisioning for new accounts. However, there’s no restriction on the number of parent or
child zones you create. If you have a distributed environment and delegate administrative authority to separate teams, you can create as many parent zones
as you find useful.
This guide describes how to set up the migration environment using one top-level parent zone. If you create more than one parent zone, you may need to
repeat steps or extrapolate additional steps from the information presented here.
Create a Top-level Parent Zone
Before you migrate users and groups or add computers to the domain, you must have at least one zone. It is recommended that you create one top-level
parent for your organization, which is similar to having a single forest root domain.
To create the top-level parent zone
1. Log on to the Windows computer where Authentication & Privilege is installed and open Access Manager.
If you are not currently connected to the appropriate forest, specify the domain controller to which you want to connect.
2. In the console tree, select Zones and right-click, then click Create New Zone.
3. Type the zone name and, optionally, a longer description of the zone.
In most cases, you should use the default parent container and container type that you created when you configured the Active Directory forest, and the
default zone type, which creates the new zone as a hierarchical zone, then click Next.
The only reasons for changing the default settings would be if you want to:
Create a zone in a new location to separate administrative activity for different groups of administrators.
Create zones as organizational units because you want to assign group policy objects to zones.
Create a classic zone for backwards compatibility or are using the Microsoft Services for UNIX (SFU) schema.
For additional details about any of the zone fields, press F1 to view context-sensitive help.
4. Review the information about the zone you are creating, then click Finish.
Add Provisioning Groups to the Parent Zone
The next step in configuring the top-level parent zone is to create two Active Directory groups that will enable automated provisioning and de-provisioning of
users and groups in the toplevel parent zone. By creating these provisioning groups in the parent zone, you can integrate the provisioning of UNIX users and
groups with your existing processes for provisioning Active Directory users.
The provisioning groups are not required for migration, but a recommended configuration for the top-level parent zone you are creating as the first zone in
the environment.
It is recommended you follow the naming conventions suggested for these groups. If you use a different naming convention, you should be sure it is well
documented in your internal process documentation.
To add the provisioning groups for user and group profiles to the parent zone
1. Start Active Directory Users and Computers.
2. Expand the forest domain and the top-level UNIX organizational unit you created in Selecting a location for the top-level OU.
3. Select Provisioning Groups, right-click, then select New > Group.
4. Type the group name using the format ZoneName_Zone_Groups. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Zone_Groups,
then click O K.
The Zone Provisioning Agent will use this group when processing the business rules for adding or removing group profiles in the parent zone.
5. Select Provisioning Groups, right-click, then select New > Group.
6. Type the group name using the format ZoneName_Zone_Users. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Zone_Users, then
click O K.
The Zone Provisioning Agent will use this group when processing the business rules for adding or removing user profiles in the parent zone.
To prevent problems in UIDs and GIDs for existing users and groups, you should import existing user and group profiles before defining the business rules for
automated provisioning of new accounts. After you complete the migration of the existing user population, you will define the business rules for the
ZoneName_Zone_Groups and ZoneName_Zone_Users groups you just created.
Create Groups for the Default Roles in fhe Parent Zone
The next step in configuring the top-level parent zone is to create two Active Directory groups for the default listed and UNIX Login roles that are predefined
in hierarchical zones.
If you have a single top-level parent zone, users with a listed role can be recognized as having a valid profile on every UNIX computer in the organization.
However, users in the listed role are not allowed to log on to any of those computers.
If you have a single top-level parent zone, users with a UNIX Login role can log on to every UNIX computer in the organization.
For the toplevel parent zone, the UNIX Login role is intended for enterprise-level systems administrators who need to be able to log on to any UNIX computer in
the organization. Because these are powerful roles in the parent zone, only a limited number of users would ever be assigned to these roles. However, the
listed and UNIX Login roles are key components of migration when you create one or more child zones. If no users in the organization will be assigned these
roles in the parent zone, you can skip the creation of the Active Directory groups for roles in the parent zone.
To create the groups for listed and UNIX Login roles in the parent zone
1.Start Active Directory Users and Computers.

2.Expand the forest domain and the top-level UNIX organizational unit you created in Selecting a location for the top-level OU.
3.Select the User Roles organizational unit, right-click, then select New > Group.
4.Type the group name using the format ZoneName_Role_RoleName. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Role_Listed,
then click O K.
5. Select the User Roles organizational unit, right-click, then select New > Group.
6. Type the group name using the format ZoneName_Role_RoleName. For example, if the zone name is arcadeGlobal, type arcadeGlobal_Role_Login,
then click O K.
Delegate Administrative Tasks on the Parent Zone
The next step in configuring the top-level parent zone is to delegate administrative authority to the Zone Administrators group and to delegate specific
permissions to the service account for the Zone Provisioning Agent to enable automated provisioning of user and group profiles in the parent zone.
To delegate administrative tasks on the top-level parent zone
1. Start Access Manager.
2. In the console tree, expand the Zones node.
3. Select the top-level parent zone, right-click, then click Delegate Zone Control.
4. Click A d d.
5. Change the Find list from User to Group, type z, then click Find Now.
6. Select Zone Administrators in the results, then click O K.
7. Click Next.
8. Select All to enable members of the Zone Administrators group to perform all administrative tasks on the top-level parent zone, then click Next.
9. If you are delegating the task of joining computers to a zone, you can specify the scope of computers you can join to the zone; you pick a container in
Active Directory to grant access to.
If you leave the scope blank, the scope is the domain root. Be aware that the postalAddress field is used for information about joining computers to a
zone; if you lookup the permissions for people you've delegated the task of joining computers to a zone, they'll have permissions to the postalAddress
field for the affected computers.
10. Review your selections, then click Finish.
11. Right-click, then click Delegate Zone Control.
12. Click A d d.
13. Type all or part of the service account name for the Zone Provisioning Agent that you created in About Zone Provisioning Agent and its requirements,
click Find Now, then select the service account in the results and click O K.
14. Click Next.
15. Select the following delegation rights for the Zone Provisioning Agent service account, then click Next:
Change zone properties

Add users
Add groups
Remove users
Remove groups
16. Review your selections, then click Finish to save the changes and close the dialog.
Link a Role Group to a Role Assignment in the Parent Zone
The next step in configuring the top-level parent zone is to link the Active Directory role groups created in Create groups for the default roles in the parent
zone with the listed and UNIX Login role definitions that are predefined in the parent zone. You create this link between an Active Directory group name and
the combination of rights associated with a role name by assigning the Active Directory group to the role.

2. In the console tree, expand Zones, the top-level parent zone, and Authorization nodes.
3. Select Role Assignments, right-click, then click Assign Role.
4. Find the ZoneName_Role_Listed Active Directory group, then click O K.
5. Click Browse.
6. Select the listed role from the list of available roles, then click O K.
7. Check that the Start immediately and Never expire options are selected and appropriate or deselect those options and set start and end times, then
click O K.
8. Repeat Step 3 through Step 7for the ZoneName_Role_Login Active Directory group and the UNIX Login role.
Create One or More Child Zones
After you have created a parent zone and prepared it with provisioning and role groups, you can create one or more child zones. You can create the child
zones based on any logical model you choose. This is where the analysis of common and conflicting attributes and some creativity come into play.
Logical Models for Defining Zones
Because the zone design uses hierarchical zones, you can override attributes at any zone or computer level to deal with conflicts in legacy profile data. With
this flexibility, you can experiment with different possible designs, for example, based on delegated administrative authority or physical location. Some
common models for grouping a set of computers, users, groups, roles, and rights in the same zone include:
By shared identity store For example, existing identity stores, such as NIS domains or a centralized user and group database, often provide a natural
boundary for zones. This strategy is especially effective if each identity store has a consistent namespace, without profile conflicts. It is less effective if
the computers that share a common administrative group use local /etc/passwd and /etc/group file to store account information.
By application or function For example, you might want to groups all of your database servers or web farm servers into their own zones. As part of
this design, you might need to evaluate whether you are combining development computers with production servers and what role assignments you’ll
need to control what users can do on each type of computer.
By geographical region or line of business For example, all of the UNIX computers that support a business unit could be logically grouped
together. As part of this design, you might evaluate whether different business units should be responsible for provisioning users or assigning roles
within their own business unit.
By host name If you already have a meaningful host name convention that identifies machine owners or primary function, you may want to create
zones based on that naming convention.
By platform and operating system You can use this strategy, for example, to create separate zones for Red Hat Linux workstations and Sun Solaris
UNIX workstations.
By department or user community You can use this strategy, for example, to create separate zones for the computers that host financial
applications and computers used by software developers.
You are not required to create child zones. You could control access to the parent zone through role assignments. For most organizations, however, one or
more child zones makes it easier to assign roles and manage group membership.
Depending on your target set of computers, you may decide to start with one or two child zones or skip the creation of a child zone.
Create a Child Zone under the Parent Zone
Creating a child zone is similar to creating a parent zone. You select the parent in the left pane, then create and configure the child zone to prepare an
environment into which you will migrate existing users and groups.
To create a child zone under the parent zone
3. Select the top-level parent zone, right-click, then click Create Child Zone.
4. Type a name and description for the child zone, then click Next.
For example, if you are organizing by functional group, this zone might be finance or engineering. If you are organizing by data center location, the child
zone might be sanfrancisco or seattle.
5. Click Finish to complete the zone creation.
The new zone is listed under the Child Zones node in the left pane.
Create Role Groups for Child Zones
The next step in configuring the child zone is to create two Active Directory groups for the default listed and UNIX Login roles that apply to this zone.
In the child zone, users with a listed role can be recognized as having a valid profile but only on computers that are joined to the child zone. Users in the
listed role for the child zone cannot log on to any of the computers joined to the child zone.
In the child zone, users with a UNIX Login role are allowed to log on to every UNIX computer joined to the child zone if they have a UNIX profile for the
zone.
For the child zone, the UNIX Login role is intended zone-level administrators and users who were previously able to log on to the UNIX computers joined to the
child zone. The listed and UNIX Login roles are key components of migration when you create one or more child zones.
To create the role groups for listed and UNIX Login roles in the parent zone

3. Select User Roles, right-click, then select New > Group.
4. Type the group name using the format ChildZoneName_Role_RoleName. For example, if the child zone name is sanfrancisco, type
sanfrancisco_Role_Listed, then click O K.
5. Select User Roles, right-click, then select New > Group.
6. Type the group name using the format ChildZoneName_Role_RoleName. For example, if the zone name is sanfrancisco, type
sanfrancisco_Role_Login, then click O K.
Delegate Administrative Tasks on the Child Zone
The next step in configuring the child zone is to delegate administrative authority to the Zone Administrators group. The steps are the same for the child zone
as the parent zone, except that you expand the Child Zones node and select the name of the child zone before selecting the Delegate Zone Control command.
You should still assign the Zone Administrators group All permissions.
You also have the option of assigning the permissions to join or leave to the Join Operators Active Directory group. If you pre-create computer accounts and
allow the computer to join itself to the Active Directory domain, you can skip this step.
If you don’t want to pre-create the computer account and allow the self-service join, you must give members of the Join Operators group the following
administrative tasks:
Join Computers to the Zone

Remove Computers from the Zone
Modify Computer Profiles
Link Role Groups to Role Assignments in the Child Zone
The next step in configuring the child zone is to link the Active Directory role groups created in Create role groups for child zones with the listed and UNIX
Login role definitions that are predefined in the child zone. You create this link between an Active Directory group name and the combination of rights
associated with a role name by assigning the Active Directory group to the role. The steps are the same for the child zone as the parent zone, except that you
expand the Child Zones node and select the name of the child zone before selecting the Authorization node.
When you search for the Active Directory group to assign, you will select the ChildZoneName_Role_Listed, for example sanfrancisco_Role_Listed, for the
listed role, and ChildZoneName_Role_Login, for example sanfrancisco_Role_Login, for the UNIX Login role.
Users who are added to the ChildZoneName_Role_Login group will be able to log on to computers that are joined to the child zone or any of its own children,
but will not be able to log on to computers in other child zones.
Create Computer Objects For The Target Set Of Computers
When you manage UNIX computers with Centrify software, you add computer objects to Active Directory for those computers. These computer objects can
be created automatically when a computer joins the domain, or created in Active Directory before the computer joins the domain. In most cases, Centrify
recommends that you create the computer account objects before joining, if possible.
For deployment and migration, creating the computer objects before joining provides the following key advantages:
You can define computer-level overrides before computers are added to the zone. This allows you to resolve issues with divergent UNIX profiles without
having to change file permissions at the file system level.
You can check who will have access to which UNIX computers before those computers join the Active Directory domain.
Pre-creating the computer objects enables you to check that you have user profiles and role assignments correctly defined before you join the UNIX
computers to zones. Verifying this information before the join operation helps to ensure a smooth migration without disrupting users’ access to files or
applications.
Prepare A Computer Object Before Joining
In most cases, you should pre-create the computer object for every UNIX computer in every zone. For individual computers, you can use the Prepare
Computer wizard to guide you through the process. However, you will probably want to create a Windows or UNIX script for performing the operation
repeatedly. For example, you can use adedit or the Windows API to create a script.
To prepare a computer account in Active Directory using Prepare Computer
2. In the console tree, expand the Child Zones node, then expand the child zone for this computer to join.
3. Select the Computers node, right-click, then click Prepare Computer.
4. Accept the default preparation options, then click Next.
5. Accept the default to Create a new computer object, then click Next.
6. Type the name of the computer object to create and modify the DNS host name of the computer object, if necessary.
The computer name is the name of the computer principal in Active Directory. The DNS name is how the UNIX computer is currently registered in DNS. If
you have a disjointed DNS namespace, you should be sure the DNS name is the name used in the computer’s DNS entry.
7. Click Change and navigate to the organizational unit for storing computer principals. For example, if you created the organizational unit structure
described in Creating recommended organizational units, select UNIX Servers and Workstations and click O K, then click Next.
8. Select an option for joining the computer to the domain, then click Next.
If you want to require users to interactively join the computer to Active Directory, click Browse to select the Join Operators group.
If you want to allow the computer to join itself to the zone, select Allow the computer to join itself to the zone. This option automatically
associates the computer with the correct zone, so there’s less chance of a human error.
9. Click Browse to select the Zone Administrators group, then click Next.
With this setting, users in the Zone Administrators can override any inherited attributes of a UNIX user or a UNIX group profile on the computer.
10. Review your selections, then click Next to create the computer account.
11. Click Finish to complete the process.
You have now finished preparing the environment for migration and are ready to begin importing groups and users and assigning them appropriate roles.
Migrating Existing Users To Hierarchical Zones
Now that you understand how zones are used and have prepared an environment for an initial migration, you are ready to import the existing users and groups
that you have identified as candidates for being migrated to Active Directory.
This section uses a sample data set to illustrate how to migrate an existing user population into hierarchical zones and how to assign the appropriate roles to
convert from a legacy authentication model to Active Directory and Server Suite.
Importing Group Profiles
After you have created one or more zones and separated the users and groups to ignore from the users and groups that you think should be migrated to Active
Directory, you must decide which groups apply to which zones. For example, if you have some groups with the same group profile and group membership in all
zones, you would import those groups into the top-level parent zone so that they also exist, with the same definition, in all child zones. If a group is only
applicable for computers in a child zone, you can import the group profiles directly into that zone. You can also override group profile attributes on specific
computers, if needed.
After you have made these decisions, importing the groups is a simple process using either the Import from UNIX wizard or ADedit scripts with two
important considerations:
Group names must be unique in Active Directory. If you create a group with a common name, such as admins, you cannot create another group with the
same name.
Having the same UNIX group name on computers in different zones can create group collisions and inadvertent privilege escalation or file ownership
conflicts.
To prevent group name collisions, Centrify recommends that you include the zone name in the Active Directory group name. You may also want to add a suffix
that identifies the group as an UNIX security group. In most cases, you create the Active Directory group object for the UNIX group in the UNIX Groups
organizational unit if you created the organizational unit structure described in Creating recommended organizational units.
You should import group profiles and create the corresponding Active Directory groups for those groups before you import users. If you import group profiles
first, you can resolve secondary group membership for users immediately after you import user profiles.
Import Unix Groups that Apply to All Computers into the Parent Zone
If your organization has a default UNIX administrators group or security group that you want to be available on all UNIX computers, that group is a good
candidate for importing into the parent zone. Other groups that might be candidates for the parent zone are special purpose UNIX groups that own sudoers
permissions that apply to all UNIX computers or an auditing group that requires access to all computers.
If you have identified any common groups, use the Import from UNIX wizard or a script to import the UNIX groups that should be available for all computers
into the top-level parent zone.
To Import Unix Groups Using the Import from Unix Wizard
2. In the console tree, expand Zones and the top-level parent zone.
3. Select UNIX Data, right-click, then click Import from UNIX.
4. Click UNIX configuration files, then click Browse to locate and select the group file to import, then click Next.
5. Select the option to automatically shorten the UNIX name, if desired, then click Next.
6. Leave Store in Active Directory selected and click Next.
7. Select Check data conflicts while importing, then click Finish.
This step places the profiles under Groups as Pending Import.
8. Select one or more group names that are Pending Import, right-click, then select Create new AD groups.
9. Click Browse, navigate to the UNIX Groups organizational unit and click O K, then click Next.
10. Click Add a prefix to group name, type the parent zone name and an underscore (), select the group scope as Global, then click Next. For example,
if the parent zone name is arcadeGlobal, use the prefix arcadeGlobal.
Optionally, click Add a suffix to group name and type a suffix that identifies the group as a UNIX security group, for example, _unix.
11. Review the information displayed, then click Finish.
For more information about importing groups, see the Administrator’s Guide for Linux and UNIX.
Import Unix Groups that Apply Only to a Specific Zone into a Child Zone
From your initial analysis and zone design, you should also have a reasonable plan for groups that apply to specific child zones. Groups imported into a child
zone are visible to all the UNIX computers in that zone, but not in other zones. For example, assume you have identified an application-specific group,
ora_app01, that allows users to use a database, and the database application exists three computers. In your zone design, you decide those three computers
should be a single child zone. In that case, you import the ora_app01 group profile into the child zone group because the database application group is only
relevant to the UNIX computers in the child zone.
The steps for importing into a child zone are the same as for the parent zone, except that you select the UNIX Data under the child zone name in the console
tree and specify the child zone name as the prefix for the Active Directory group name.
Import a Group Profile or Override Attributes on Specific Computers
In some cases, you may have a UNIX group that only exists on one computer in a zone or exists on more than one computer but has different attributes on
different computers. You can use computer-level overrides to handle these cases. Computer-level overrides enable Zone Administrators to create and
manage group profile attributes manually for individual computers.
To create a group profile for a specific computer
1. Use Active Directory Users and Computers to create an Active Directory group in the UNIX Groups organizational unit. If the group only applies to a
specific computer, you may want to use the computer name as the prefix.
3. Expand the console tree to display the individual computer object under the zone the computer will join.
4. Expand UNIX Data, select Groups and right-click, then click Create UNIX Group.
5. Click the attributes to define, type the appropriate values, then click O K.
Click GID to manually specify a GID for the group profile on the selected computer.
Click UNIX group name to manually specify a group name for the profile on the selected computer.
Avoiding Group Collisions When Using Computer-level Overrides
If you create group profile overrides on individual computers, you should make sure that the UNIX group name and GID are not being used by any other groups
in the parent or child zone. If the group profile defined for the computer is the same as a group profile defined for a group in the parent or child zone, users who
should only be able to access files on the local computer may be able to access files owned by the group defined for the parent or child zone. This can be a
difficult problem to identify. For example, assume you have an Active Directory group named contract_admins, but you have used the UNIX group name
admins and the same GID as a group in the parent zone. Any user who is a member of the contract_admins group in Active Directory is going to have the same
GID as the parent zone’s admins group. If that happens, members of the contract_admins group will have access to the same files as the admins group in the
parent zone.
The only way to identify when this problem occurs is by running the following command for a user in the contract_admins group:
id -a
Importing User Profiles
You can import user profiles into the parent zone or into child zones. If you import user profiles into the parent zone, all existing users will be included in the
candidate set of users who have the potential to log on to all of the UNIX computers in the organization. However, they are not granted any access by default.
Instead, the management of identity information, such as the user name, UID, and primary group, is separate from privilege management. Users cannot
access any UNIX computers until they are assigned a valid role with the specific permissions they need to be recognized, allowed to log on, or run specific
commands.
Although you can import users into the parent zone without granting them access rights, you may prefer to import them into one or more child zones. By
importing users into specific child zones, you can limit the scope of their potential access. In general, this option is applicable for the majority of your end-
users and can apply to other users, such as database administrators, project managers, and contractors who won’t ever need access to all the UNIX
computers in the organization.
At this stage you should decide whether to give users the potential to access all computers in the organization, or only the computers in one or more specific
child zones. After you import the user profiles, you will use the default listed and UNIX Login roles or custom roles to control access to the UNIX computers.
The steps for importing user profiles into a parent or child zone are essentially the same as importing groups. You can use the Import from UNIX wizard or
ADedit scripts to import the profiles into one or more zones. The profile information for any user can be different in each zone. If the profile information is
divergent on any computer within a zone, you can set computer-specific overrides for any or all attributes.
T i p: If you are importing users from a file, you can write a script that modifies the GECOS field to use the same format used in the Active Directory
displayName attribute before importing so that users are automatically mapped to their corresponding Active Directory accounts. For example, if your
convention for the GECOS field is first_name last_name (Jae Wilson) but the convention used in Active Directory is last_name, first_name (Wilson, Jae),
you must manually map the UNIX user account to the Active Directory account. If you modify the format of the GECOS field before importing, the Import from
UNIX wizard can automatically suggest a candidate for mapping the UNIX user to an Active Directory user, if an account exists.
After you import users, their profiles are placed under Users as Pending Import. If the user has an existing Active Directory account, you can select the user
name, right-click, then select Extend existing AD user. If an Active Directory account does not exist, you can select the user name, right-click, then select
Create new AD users. You can then use Check Status to resolve group membership for Pending Groups. This command adds the imported users to the
appropriate Active Directory groups that have UNIX profiles in the zone to complete the first phase of the migration to Active Directory.
For more information about importing users and resolving group membership, see the Administrator’s Guide for Linux and UNIX.
How Group Membership Works Within Zones
When a UNIX group profile is imported into a zone, its group name and GID are recognized by all computers joined to that zone. However, the group
membership might vary by computer. For a user to be a member of the UNIX group, the user must:
Be a member of the Active Directory group.

Have a complete UNIX user profile defined somewhere in the zone hierarchy (in the parent zone, a child zone, or with computer-level overrides).
Be assigned the listed role or the UNIX Login role somewhere in the zone hierarchy (in the parent zone, a child zone, or with computer-level overrides).
For example, assume the users Alison and Clyde are assigned the UNIX Login role for the Engineering zone. As discussed in Create role groups for child zones,
that means they are also listed as members of the Engineering_Role_Login role group in Active Directory. Clyde is also a member of the denali project group
in the Engineering zone and has a profile defined in the parent zone. Alison’s profile is defined in the Engineering zone. If the denali project group
(Engineering_Denali in Active Directory) is added to the Engineering zone, both Alison and Clyde can log on to computers in the Engineering zone, but only
Clyde will be a member of the denali UNIX group in the Engineering zone.
Assigning Roles to Existing Users and Groups
You have now imported the existing user and group profiles for a target set of computers into Active Directory. This is one critical component of migration
because users must have a valid UNIX profile, that is, a unique user name, UID, primary GID, home directory and shell, in a zone for them to be recognized as
valid users. However, Server Suite separates UNIX profile management from UNIX privilege management. Users cannot log on to UNIX computers until they
are assigned a role that allows them to log on to those computers.
As discussed in Access controls and the assignment of rights and roles, a role is a collection of rights and there are two default roles: the listed role and the
UNIX Login role. As part of deploying Server Suite software with the least disruption to your environment, your existing users must be able to log on to the UNIX
computers they currently use. That is the primary purpose of the UNIX Login role: to allow you to quickly give log on access to a set of users in one or more
zones. The UNIX Login role in the parent zone is intended for enterprise administrators who need log on access to all computers. The UNIX Login role in the
finance zone would be for those users who currently have interactive access to the limited number of computers in that zone and would expect to have that
access after migration.
The listed role is intended for users who need a valid profile defined but do not need interactive log on access to the computers in a zone. For example, you
assign the listed role to remote NFS users so that they have access to their files without the ability to log on and open a shell. You can also use the listed role to
give users access to applications, such as ClearCase or Samba, that require a UNIX profile without the ability to log on locally or remotely. The listed role in
the software-dev zone would be for those ClearCase users who need to be recognized on all computers in the zone so they can check files in and out.
The next step in the migration is to identify which users should be assigned to each role in each zone you have created.
Using Active Directory Groups for Roles
For most organizations, the most efficient way to manage role assignment is by adding users to Active Directory groups, then managing those groups.
Therefore, for management purposes, a Centrify access role should always be linked to an Active Directory security group. The Active Directory groups that
identify the users in specific Centrify user roles are stored in the User Roles organizational unit. All of the users in a specific role group will share a common
set of rights under UNIX. You can then use machine-level overrides for handling edge cases for individual computers.
Adding Users to Role Groups
There are many different ways you can add UNIX user profiles to an Active Directory group. For example, you can manually select a UNIX profile in a zone,
right-click, then select Add to a group or select groups under the Role Assignments node for the zone, and modify the group membership. In most
organizations, however, you can leverage your existing provisioning process. If your current provisioning process involves managing a group in Active
Directory, whether it is through automated scripts or human processes, you can use the same process for provisioning UNIX users.
Migrating Existing Users Into The Unix Login Role In The Parent Zone
In Create groups for the default roles in the parent zone, you created Active Directory security groups for UNIX Login and listed roles in the parent zone. If you
want to give all users the potential to log in to all UNIX systems, you can make them members of the parentZone_Role_Login group.
Users who are members of this group and have a complete UNIX profile in the parent zone can log on to all UNIX computers that are joined to the parent zone
and all UNIX computers joined to the child zones of the parent zone. However, if you add users to the parentZone_Role_Login group in Active Directory, but do
not define a UNIX user profile in the parent zone, those users will only be able to log on to the UNIX computers in the child zones where they have a UNIX user
profile defined or the individual computers where you define machine-level overrides to give them a UNIX profile.
The default UNIX Login role associated with the parentZone_Role_Login group does not grant any additional privileges. It simply allows users to log on to
UNIX computers. Therefore, one strategy for migrating users is to add them all to parent zone’s Login role group. You can then control access based on where
the user’s UNIX profile is defined and control what the user can do using additional role assignments. For example, you may create custom roles to grant
expanded UNIX privileges.
Migrating Existing Users into the Unix Login Role in Child Zones
If you define user profiles for most of your users in the parent zone, you should not make them members the parentZone_Role_Login group. Instead, you can
add users to the appropriate childZone_Role_Login groups. All of your existing UNIX users who can currently log on interactively to existing UNIX systems
should be added to one or more childZone_Role_Login groups. For example, users who currently have access to all of the computers in the Engineering zone
should be added to the Engineering_Role_Login Active Directory group. If those users also have a UNIX profile in the parent zone or the Engineering zone,
they will be able to log on to all of the computers in the Engineering zone. If a user only needs access to a specific computer in the zone, you can use a
machine-level override to give the user access to that specific computer.
You can use the Access Manager console, Active Directory Users and Computers, ADEdit or custom scripts to add UNIX user profiles to the appropriate
childZone_Role_Login groups. If possible, you should integrate this part of the migration with your existing provisioning process to ensure that future
requests for UNIX role assignments use the processes that line of business personnel already understand.
Migrating Existing Users into the Listed Role in Child Zones
After you have assigned users who must be able to log on to the UNIX Login role, you should identify users who should be assigned the listed role to limit the
number of users allowed to log on. The listed role is intended for existing UNIX users who have a UNIX user profile in one or more zones that you want to allow
to be listed in getent output without the ability to log on to UNIX computers in those zones.
The listed role is most commonly used for users who access UNIX applications, such as ClearCase, or Samba, or an NFS-mounted file system, that require a
UNIX profile. In practical terms, however, this role also allows you to migrate users you aren’t sure have been authorized for access. With this role, the user
profile is recognized but the user cannot log on locally or remotely.
You can use the Access Manager console, Active Directory Users and Computers, ADEdit or custom scripts to add the UNIX user profiles to the appropriate
childZone_Role_Listed groups. If possible, you should integrate this part of the migration with your existing provisioning process to ensure that future
requests for UNIX role assignments use the processes that line of business personnel already understand.
Keep in mind that the childZone_Role_Listed group affects all the UNIX computers joined to the specified child zone. Before you move a user to the
childZone_Role_Listed group, you should check whether there are any computers in the zone that the user must be able to access to prevent accidentally
locking the user out. You can use a machine-level override to grant the UNIX Login role on a specific computer, if needed.
Using a Computer-level Override for the Unix Login Role
You can also create computer-level overrides for the UNIX Login or listed role, if needed. This is not typically part of the migration process. However, if your
initial analysis identified a zone where overrides would be useful, you can include overrides in your migration plan. For example, assume you have a zone
where most of the user profiles are common across a set of computers. If you import the UNIX profiles for that user population, you see that two users would
have access to a UNIX computer where they previously did not have access. To preserve the existing access while migrating from the legacy environment,
you can define the UNIX profile in the zone but control access for those two users with a computer-level override.
Managing Role Assignment Without Role Groups
You are not required to use Active Directory security groups to manage role assignments. You can manually add users and groups to roles within any zone.
Manually adding a user or group to a role without using Active Directory groups makes integration with provisioning systems more difficult, however. Most
identity management and provisioning systems are designed to work with Active Directory groups inherently. Therefore, associating Active Directory groups
with Server Suite roles typically provides easier integration with existing provisioning processes.
If you decide to manually manage role assignments, you can use the Server Suite Access Module for Windows PowerShell, Server Suite Access SDK, or ADedit
to create scripts that manipulate the objects in Active Directory. Role assignments are stored in Active Directory using Microsoft Authorization Manager
containers. If you want to add and remove user and group assignments, you will need to develop custom code to accomplish those tasks.
Verifying Effective Users On Each Zone
Now that you have imported profiles and assigned existing users to the appropriate roles, you can verify who has access to the computers in each zone before
you proceed with joining a domain. Checking the Effective Users in each zone enables you to verify the users who have been assigned the UNIX Login and
listed roles before any users are affected by the changes.
You should have a checklist of the users who require interactive access on the computers in the target set and which user profiles you suspect only need to be
recognized without the ability to log on. You can then using the Effective Users option to see the role assignments for the pre-created computer objects in the
target set of computers. By comparing the list of users to the role assignments, you should be confident that you are ready to complete the migration by
joining UNIX computers to the Active Directory domain.
Performing this step before joining the domain helps to ensure the transition to Active Directory does not interfere with end-users daily work or the delivery of
business services. Therefore, verifying UNIX Login and listed access before joining computers to the domain is a key part of a successful migration.
To access the Effective Users for a zone
1.Start Access Manager.

2.In the console tree, expand Zones and the top-level parent zone.
3.Select a zone, right-click, then click Show Effective UNIX User Rights.
4.Review the list of UNIX user profiles for the zone in the UNIX users section.
5.Select a user name to display additional information about each user:
Zone Profile displays details about inherited profile attributes. For existing users being migrated, the profile attributes are typically explicitly
defined. If a profile is defined higher up in the zone hierarchy, the Inheritance tab indicates where the profile attributes are defined.
Role Assignments lists the role assignments for the selected user in the zone. For the initial migration, users must be assigned the UNIX Login or
listed role.
PAM Access lists the specific PAM application access rights associated with the roles a user is assigned. For example, the default UNIX Login role
has the login-all PAM access right, which enables PAM authentication for all computers in the zone.
Commands lists the specific UNIX command rights associated with the roles a user is assigned. For example, you can define a role that allows
users to run specific privileged commands as root. You can click the Commands tab to see the specific privileged commands defined for the role.
SSH Rights lists the specific secure shell (ssh) command rights associated with the roles a user is assigned.
6. Click Close when you have finished checking role assignments for the users in target computer of computers.
You can also select Show Effective UNIX User Rights for individual UNIX computers and generate Hierarchical Zone reports that describe the effective
rights for computers and users.
Adding Existing Users and Groups to Provisioning Groups
After you have added the existing users and groups to the appropriate Login and Listed role groups, the next step for completing the migration to Active
Directory is to add the existing user and group profiles to the Provisioning Groups you created for the parent zone. This step is not directly related to data
migration, but enables you to prepare the environment for automated user and group fulfillment using on the Zone Provisioning Agent.
Add Existing Users To The Provisioning Group For The Parent Zone
At this point, you have imported legacy data into one or more child zones and accepted divergent profile attributes using computer-level overrides. You
should now add all of your imported UNIX users to the provisioning group in the top-level parent zone. Adding users as members of the provisioning group will
enable the Zone Provisioning Agent to define a new “universal” UNIX profile for legacy users based on business rules you establish for the parent zone. The
new profile will not affect the existing file ownership, but will make it easier to provision and deprovision users moving forward.
As discussed in Installing Zone Provisioning Agent, the Zone Provisioning Agent enables you to define business rules for creating new UNIX profiles for new
UNIX users. After you complete the migration and enable the Zone Provisioning Agent, it runs at a regularly scheduled interval to determine whether there are
new users or users who should be removed. At each interval, the Zone Provisioning Agent compares the members of the parent zone’s Users provisioning
group with the user profiles currently defined for the zone.
If there are UNIX profiles for users who aren’t members of the provisioning group, the Zone Provisioning Agent removes those user profiles. To prevent the
Zone Provisioning Agent from removing the imported data, you must add the Active Directory users associated with the imported user profiles to the parent
zone’s Users provisioning group.
To add existing UNIX users to the provisioning group for the parent zone

3. Expand the Provisioning Groups organizational unit, then select the parentZoneName_Zone_Users group. For example, if the parent zone is
arcadeGlobal, select arcadeGlobal_Zone_Users, right-click, then select Properties.
4. Click the Members tab, then click A d d.
5. Search for and select the imported user accounts that you have mapped to Active Directory users, then click O K.
6. Click O K to save the provisioning group and close the Properties.
Add Existing Groups to the Provisioning Group for the Parent Zone
As with imported users, you should also add all of your imported UNIX groups to the provisioning group in the top-level parent zone. Adding the group profiles
as members of the top-level provisioning group will enable the Zone Provisioning Agent to define a new “universal” UNIX profile for each group based on
business rules you establish for the parent zone. The new profile will not affect the existing file ownership, but will make it easier to provision and deprovision
users moving forward. Adding the UNIX group profiles to the top-level parent zone ensures that the Zone Provisioning Agent does not remove the imported
groups from the zone.
To add existing UNIX groups to the provisioning group for the parent zone

3. Expand the Provisioning Groups organizational unit, then select the parentZoneName_Zone_Groups group. For example, if the parent zone is
arcadeGlobal, select arcadeGlobal_Zone_Groups, right-click, then select Properties.
5. Search for and select the imported user accounts that you have mapped to Active Directory users, then click O K.
6. Click O K to save the provisioning group and close the Properties.
Joining Computers to a Domain and Zone
You have completed the preparation of the environment and added existing users and groups to Active Directory. The steps up to this point have not affected
the day-to-day activities of any UNIX users or groups, and have not changed the configuration of any UNIX computers. The final step in the migration requires
you to join UNIX computers to the Active Directory domain. This step does have the potential to affect end-users.
This section describes how to complete the migration by joining the target set of computers to an Active Directory domain and a Server Suite zone.
Using Adjoin on New Computers
You can run the adjoin command interactively or in a script to join UNIX computers to Active Directory. One advantage to using the adjoin command is that it
enables you to add the join operation to the steps for building a new UNIX computer. For example, if you have a process for provisioning a new UNIX computer,
you can add an adjoin step that allows the new UNIX computer to join itself to Active Directory. Provisioning new computers to join the domain when they are
built ensures that there are no new local users being defined on those UNIX computers.
Running Adjoin Requires Unix and Active Directory Privileges
On UNIX, running adjoin requires you to log on as root, be a member of the wheel group, or have root equivalent privileges in the sudoers file. On Mac OS X
computers, adjoin requires the administrator account and password.
Specifying the Required Options
The basic syntax for the adjoin command is:
adjoin [options] domain_name [--zone zone_name | --workstation]
The domain_name should be a fully-qualified domain name; for example, sales.acme.com. If you are using adjoin to provision new computers, there are
several options you should specify on the command line or in the script.
Use the --container or -c option to specify the location for the computer account. Typically, you should use the organizational unit that you created for
UNIX Servers and Workstation under the top-level UNIX organizational unit. It must be the location you used when you pre-created the computer object.
For example:
-c “ou=UNIX Server and Workstations,ou=UNIX”
Use the --selfserve or -S option to specify that you want the computer to join itself to the Active Directory domain.
Use the --zone or -z option to specify the name of the zone to join. You must specify a zone name unless you are joining Auto Zone using the --
workstation option.
If you have a disjointed DNS environment where the Active Directory domain for the computer account does not match the name of the DNS domain,
you must also specify the -name and
--alias options. The --name option specifies the name of the Active Directory computer object and the --alias will be the fully-qualified DNS name of the
computer.
For example, update your provisioning process for a new computer to include a command similar to the following:
adjoin -c “ou=UNIX Server and Workstations,ou=UNIX” -S -z production arcade.net
For complete information about adjoin options, see the adjoin man page.
Pre-staging Before Using Adjoin on a New Machine
When joining a large AD environment, the join procedure can take a very long time - up to dozens of minutes. This becomes a concern in some use cases, such
as starting an Amazon EC2 instance that needs to join the domain to provide service.
To speed up the adjoin process, the adjoin --prestage option uses existing cache files instead of populating cache from scratch.
Some preparation is required to take advantage of the --prestage option:
Prepare a pre-staged cache directory on a joined machine

Copy the cache directory to the new machine
Security Requirements
To use the --prestage option, ensure the following:
Joined and new machine requirements:

The --prestage option can only be used between machines that have the same platform, architecture, and Authentication Service (Centrify
DirectControl) release version installed.
Adclient cache data encryption feature cannot be enabled on the joined machine. See the adclient.cache.encrypt parameter.
Pre-staged cache directory on joined machine requirements:
On a joined machine, create or designate a directory for the pre-staging cache files.
The directory must be in a safe path. That means all levels of parent directories are owned by system accounts.
The directory cannot be either group or world writable.
Content for the pre-staged cache directory on the joined machine:
Place the cache files (dz.cache, dc.cache, gc.cache,.idx and kset. files) in the specified directory.
Ensure the cache files are owned by system accounts.
Files cannot be either group or world writable.
Symlink is not allowed for the cache files.
Zone hierarchy changes are not allowed between the staging directory and the new machine. This includes:
zone name change
zone GUID change
zone schema change
Preparing to Use the --prestage Option
1. Create a directory on a joined machine. For example, /pre.
2. Stop adclient on that machine.
3. Copy the /var/centrifydc/ directory to the pre-staged directory on the joined machine.
For example:
Copying the /var/centrifydc/ directory to the pre-staged directory, /pre, places a copy of the required files in /pre/centrifydc/.
4. Verify the pre-staged directory on the joined machine contains all the .idx, .cache, and kset. files.
5. Copy the pre-staged directory to the new machine.
Use a method of your choice, such as scp or sftp.
This is done so the pre-staged files are available locally on the new machine.
6. Add the option to the adjoin command when adding the new machine. The syntax is:
-E | --prestage <directory>
where directory is the path to the pre-staged directory on the new machine.
For example, if the pre-staged files are in directory, /pre/centrifydc/, use the following adjoin command.
adjoin -z <zone> -E /pre/centrifydc<domain>
Verify Authentication After Joining the Domain By Logging On
As the final step in the initial migration, you should verify that authentication for an Active Directory user is successful. You can do this by logging on to the
UNIX console using either the UNIX user name or the Active Directory User Principal Name for a user assigned to the UNIX Login role. When prompted, type
the Active Directory password for the account. If you are able to log on using the Active Directory password, you know that authentication is being handled by
Active Directory and the user account has been successfully migrated.
You should also verify that you can log on remotely using a secure shell (ssh) connection and that you can use other services such as ftp.
If users have trouble logging on after a UNIX computer has joined the domain, it is typically because they’re not assigned the UNIX Login role or don’t have a
valid UNIX profile in the zone. You can use the Show Effective UNIX User Rights command to check which users have profiles and what roles have been
assigned to users who have access to the selected computer.
Provisioning New User and Group Profiles After Migration
After you have completed the basic migration for a set of existing users and groups, you can continue with the Centrify deployment by configuring the
environment for automated provisioning of new users and groups. At this stage, you have already built the foundation for the automated addition and removal
of users and groups. The next steps involve defining the business rules for creating new user and group profiles. The goal of this section is to help you identify
and integrate a provisioning process for new UNIX users and groups.
Integrating with Existing Provisioning Processes
The Zone Provisioning Agent and the provisioning groups you created in Add provisioning groups to the parent zone are intended to integrate the provisioning
of UNIX users and groups with your existing account fulfillment process. Those groups enable you to leverage existing processes because most organizations
have well-defined and standardized procedures for provisioning new Active Directory users based on Active Directory group membership.
If possible, you would like to use the same or a similar process for provisioning UNIX users and groups. If you can integrate the provisioning of UNIX users and
groups with your existing process, the people in your organization can use tools they are familiar with and won't have to learn an entirely new process.
However, defining the business rules for adding new user and group profiles to zones requires some planning. In particular, you need to make decisions about
Active Directory group membership, primary group definitions for users in zones, and how profile attributes are defined.
Defining the Business Rules for New Groups in the Parent Zone
You have already started the process of integrating the provisioning for UNIX users and groups when you added imported accounts to the Active Directory
provisioning groups in Adding existing users and groups to Provisioning Groups. The next step is to define the business rules for creating new UNIX group
profiles in the top-level parent zone.
Note: The business rules you define only affect new UNIX user and group profiles. The imported legacy data remains unchanged, and the Zone
Provisioning Agent will not modify any attributes on the existing user and group profiles.
Configure the Business Rules for Automated Provisioning of Group Profiles
You configure the business rules for automated provisioning of group profiles on a zone-by-zone basis. When you use hierarchical zones, you typically want to
configure the business rules for the parent zone so that the profile can be inherited in all child zones. Remember that the profile, by itself, does not provide
any access to the computers in the child zones, and that you can override any inherited attributes in any zone or on individual computers.
To Configure the Business Rules For Groups in the Parent Zone
3. Select the top-level parent zone, right-click, then click Properties.
4. Click the Provisioning tab.
If you are defining business rules for a parent hierarchical zone and want to establish a “source zone” for profile attributes, click Advanced. You can
then select the Source zone for any or all user and group profile attributes. If you select Source zone for any attribute on the Advanced Provisioning
page, you can click Browse to search for and select the zone to use as the source zone. In most cases, selecting a source zone is not necessary if you
using hierarchical zones, but this option can be useful if you are migrating from classic to hierarchical zones.
5. Click Enable auto-provisioning for group profiles.
6. Click the Find icon to search for and select the “groups” zone provisioning group as the Source Group.
If you followed the recommended naming convention, search for and select parentZoneName_Zone_Groups. For example, if the zone name is
arcadeGlobal, select arcadeGlobal_Zone_Groups.
7. Select a method for assigning a new GID to new UNIX group profiles:
Generate from group SID generates new GIDs that are guaranteed to be unique in the forest based on the Active Directory security identifier
(SID) of the group. Selecting this option ensures groups defined in the parent zone have a unique GID across all zones in the Active Directory
forest.
RFC 2307 attribute uses the gidNumber attribute from the RFC 2307 schema to define GID values for the Active Directory groups that you add
to the parent zone. This option requires you to add the RFC 2307 attribute to Active Directory group principals.
Use auto-incremented GID selects the next available GID in the parent zone. In most cases, you should avoid using this option because it does
not guarantee unique GIDs.
Generate using Apple scheme generates group GIDs based on the Apple algorithm for generating numeric identifiers from the Active
Directory group’s objectGuid. This option is only supported for hierarchical zones.
8. Select a method for assigning a new group name to new UNIX group profiles:
SamAccountName attribute generates the group name for UNIX group profile based on the sAMAccountName value.
CN attribute uses the common name attribute to define group names for the Active Directory groups you add to the zone. You should only select
this option if you verify the common name does not contain spaces or special characters. Otherwise, you should not use this option.
RFC 2307 attribute uses the cn attribute from the RFC 2307 schema to define group names for the Active Directory groups you add to the zone.
Zone default value uses the Group name setting from the Group Defaults tab to define group names for the Active Directory groups you add to
the zone. In most cases, the default is a variable that uses the sAMAccountName attribute.
By default, all UNIX group names are lowercase and invalid characters are replaced with underscores.
9. Click O K to save your changes.
Add Security Groups to the Parent Zone
The most common way to provision UNIX users is to use a private group identifier as the primary group. With this approach, every user has a unique primary
GID that is the same as the UID.
Although not required, another common approach to provisioning UNIX users involves adding a small number of key security groups to the parent zone. For
example, if you have a commonly-used group such as All US Employees to which you normally add valid Active Directory users as members, you could add
that security group to the parent zone to assign all UNIX users the same primary GID in the parent zone. This approach makes provisioning UNIX users easier
because you have already defined Active Directory users as members of that group. If you want to use an Active Directory group to set the primary GID for
provisioned users, keep in mind that the size of the group membership can affect the performance of the Zone Provisioning Agent and how long it take to
complete provisioning.
If you choose to have the user’s primary group defined by Active Directory group membership, the Active Directory group must be in the same Active
Directory forest as the users being provisioned. If the Active Directory group is located in another forest, provisioning fails.
If you want to use this approach:
1. Add the security group to the provisioning group for the parent zone (for example, parentZoneName_Zone_Groups).
2. Open the Properties for the parent zone, click the Provisioning tab, and define the business rules for the UNIX group profile provisioning associated
with the security group.
At the next update interval, the Zone Provisioning Agent adds a profile for the group to the zone. You can also run the zoneupdate command to add the
profile without waiting until the next update interval. For example:
zoneupdate zoneName
3. Click the User Defaults tab for the parent zone, select the ellipsis <...> option for the Primary Group and select the GID for the group profile that the
Zone Provisioning Agent added to the zone.
Defining The Business Rules For New Users In The Parent Zone
In addition to the business rules for group profiles, you configure similar rules for new UNIX user profiles. When you use hierarchical zones, you typically want
to configure these business rules for the parent zone so that the profile can be inherited in all child zones. Remember that the profile, by itself, does not
provide any access to the computers in the child zones, and that you can override any inherited attributes in any zone or on individual computers.
Note: The business rules you define only affect new UNIX user and group profiles. The imported legacy data remains unchanged, and the Zone
Provisioning Agent will not modify any attributes on the existing user and group profiles.
To Configure The Business Rules For User Profiles In The Parent Zone
If you are defining business rules for a parent hierarchical zone and want to establish a “source zone” for profile attributes, click Advanced. You can
then select the Source zone for any or all user and group profile attributes. If you select Source zone for any attribute on the Advanced Provisioning
page, you can click Browse to search for and select the zone to use as the source zone. In most cases, selecting a source zone is not necessary if you
using hierarchical zones, but this option can be useful if you are migrating from classic to hierarchical zones.
5. Click Enable auto-provisioning for user profiles.
6. Click the Find icon to search for and select the “users” zone provisioning group as the Source Group.
If you followed the recommended naming convention, search for and select parentZoneName_Zone_Users. For example, if the parent zone name is
arcadeGlobal, select arcadeGlobal_Zone_Users.
This is the same group to which you added the Active Directory users associated with imported user profiles as described in Add existing users to the
provisioning group for the parent zone.
7. Select a method for assigning a new UID to new UNIX user profiles:
Generate from user SID generates new UIDs that are guaranteed to be unique in the forest based on the Active Directory security identifier
(SID) of the user. Selecting this option ensures users defined in the parent zone have a unique UID across all zones in the Active Directory forest.
RFC 2307 attribute uses the uidNumber attribute from the RFC 2307 schema to define UID values for the Active Directory users that you add to
the zone. This option requires you to add the RFC 2307 attribute to Active Directory user principals. Otherwise, you should not use this option.
Use auto-incremented UID uses the next available UID in the parent zone. In most cases, you should avoid using this option because it can
create UID conflicts with users in other zones.
Use custom ID enables you to use the employeeId, employeeNumber, or uidNumber attribute as the UID for new users. You should only select the
employeeId or employeeNumber attribute if your organization already populates the employeeId or employeeNumber attribute with a unique value
for each user account.
Generate using Apple scheme generates user UIDs based on the Apple algorithm for generating numeric identifiers from the Active Directory
user’s objectGuid. This option is only supported for hierarchical zones.
8. Select a method for assigning a new UNIX user login name to new UNIX user profiles:
SamAccountName attribute generates the user login name for new UNIX users based on the sAMAccountName attribute.
CN attribute uses common name attribute for user names. You should only select this option if you verify the common name does not contain
spaces or special characters. Otherwise, you should not use this option.
RFC 2307 attribute uses the uid attribute from the RFC 2307 schema to define user names for the Active Directory users that you add to the
zone. This option requires you to add the RFC 2307 attribute to Active Directory user principals. Otherwise, you should not use this option.
Zone default value uses the setting from the User Defaults tab for the zone. In most cases, the default is a variable that uses the
sAMAccountName attribute.
9. Select a method for assigning a new shell and home directory to new UNIX user profiles.
RFC 2307 attribute uses the loginShell attribute for the shell and the unixHomeDirectory attribute for home directory from RFC 2307 schema
for the default shell and home directory
Zone default value uses the values you define on the User Defaults tab, which can include runtime variables for the shell and home directory.
Runtime variables are populated with platform-specific values when a user tries to log on to a UNIX computer. For example, if a user logs on to a
Linux computer with a profile that uses the runtime variable for the home directory, the home directory is
/home/username. If the user logs on to a Solaris computer, the runtime variable becomes /export/home/username.
10. Select a method for assigning a primary group to new UNIX user profiles.
RFC 2307 attribute uses the gidNumber attribute from the RFC 2307 schema for primary group values. This option requires you to add the RFC
2307 attribute to Active Directory user principals. Otherwise, you should not use this option.
Zone default value uses the values you define on the User Defaults tab. This setting enables you to use a specific group profile as the primary
group for all UNIX users. If you don’t change the default value for the primary group on the User Defaults tab, the default primary group is a private
group.
Private group uses the user’s UID as the primary GID.
Active Directory group membership uses the Active Directory group with the highest priority as the primary UNIX group. With this option, the
Zone Provisioning Agent checks which groups a user belongs to and a prioritized list of groups you have defined. If you select this option, click the
Configure icon to search for and select the Active Directory groups to include in the prioritized list. This option allows different users to have
different primary GIDs in the same zone.
Generate using Apple scheme generates the user’s primary group identifier (GID) based on the Apple algorithm for generating numeric
identifiers from the Active Directory objectGuid for the user’s primary group. Note that the user's primary group must configured for the zone. If
the primary group is not configured for the zone, an error will be logged in the Windows Event Log when the user is provisioned. This option is only
supported for hierarchical zones.
Generate from group SID generates new primary GIDs based on the user’s Active Directory primary group using the Centrify algorithm for
generating GIDs.
If you select the Active Directory group membership option and a user isn’t a member of any of the groups in the list of prioritized groups, the Zone
Provisioning Agent will not create a UNIX user profile for the user, because it won’t be able to determine the primary group. As noted in Add
security groups to the parent zone, the most common approach is to have all users assigned the same primary GID in a zone.
By default, the GECOS field in new UNIX user profiles is populated using the displayName attribute for the user.
How Hierarchical Zones Affect Provisioning
Because hierarchical zones enable profile attributes to be inherited, defining the business rules for new users and groups in the parent zone enables the Zone
Provisioning Agent to generate consistent profiles for all child zones.
When you define a UNIX profile for a group or a user in a parent zone, the attributes are automatically inherited by all child zones. For groups, inheritance
makes the group GID and group name available in all child zones. For users, inheritance gives every user defined in the parent zone the potential to log on to
every UNIX computer. You then use role assignments to control which computers users can actually access, and, once you begin defining custom roles, what
they can do on those computers.
By default, all of the attributes in each new profile are inherited from the parent zone. You can then override any of the attributes as needed in each of the
child zones or on individual computers on a case-by-case basis. This flexibility enables you to establish a consistent UID and GID namespace across all zones
based on unique SID and sAMAccountName values, while granting exceptions to the specific cases where you need them.
For individual computers, UNIX user and group profiles are inherited from the zone the computer has joined. Typically, this is a child zone or the child of a child
zone. You can manually override any attribute or set of attributes for individual computers. Any attributes you do not override are inherited from the zone and
the business rules you defined for the Zone Provisioning Agent.
Adding New Users to a Provisioning Group and a Role Group
For new Active Directory users to be effective users of a zone, they must be added to the parent zone’s “users” provisioning group and to a role group. You can
add users to these groups manually using Active Directory Users and Computers or you can update your existing provisioning process for modifying the
membership of Active Directory groups to add users to the appropriate groups. The key points to understand are:
Users are added to a provisioning group so that the Zone Provisioning Agent creates a UNIX profile for them. A user must have a complete UNIX
profile to be a valid user on UNIX computers. Centrify recommends creating the profile in the parent zone, but you can create the profile in any zone or
on individual computers.
Users are added to a role group so that they have a valid role assignment that allows them to log on or perform specific tasks. Initially, you only have
two possible role assignments, listed or UNIX Login, but you are likely to create more.
Add The User to a Provisioning Group
Using Active Directory Users and Computers, scripts, or internal procedures, the basic workflow for a new user would be similar to this:
1. A new Active Directory user requests access to UNIX computers.
2. You add the user principal name to an Active Directory group principal. If you are adding the user to the parent zone, you add the user to the “users”
provisioning group parentZoneName_Zone_Users.
If you wanted to create the profile in a child zone instead of the parent zone, you would add the Active Directory user to the
childZoneName_Zone_Users. If you use some other naming convention for the provisioning group, you would search for and select that group.
3. The Zone Provisioning Agent monitors this group and at the next interval (or ondemand) creates a UNIX profile for the user in the zone, based on the
business rules you defined.
Note: If you remove a user from the Active Directory provisioning group, the Zone Provisioning Agent removes the UNIX user profile from the
zone.
4. You notify the user that a new UNIX profile has been created with information about the login name and initial Active Directory password to use.
Add the User to a Role Group
Users must also have a role assignment for the zone where you want to grant access. A role assignment is required before the UNIX user profile is usable.
Using Active Directory Users and Computers, scripts, or internal procedures, the basic work flow for a new user would be similar to this:
1. A new Active Directory user requests access to UNIX computers.
2. You add the user principal name to the appropriate Active Directory group principal. If you want to allow the user to log on to computers in a child zone,
you add the user to the Login role group childZoneName_Role_Login.
If the user should be recognized but not allowed to log on, you would add the Active Directory user to the childZoneName_Role_Listed. After you have
created custom roles, you would search for and select groups based on the specific rights a user needs.
3. Run the Zone Provisioning Agent update command in preview mode to verify your changes. For example:
zoneupdate /p zoneName
4. Check the results of the zoneupdate preview, then run the command without the preview option to execute the business rules for provisioning. For
example:
zoneupdate zoneName
Adding a New Unix Group Profile to All Zones
If you want to make a new UNIX group available to all zones, you should first create a new Active Directory group. In most cases, groups are not shared across
multiple zones because of the potential for privilege escalation based on group membership. However, the steps for creating a UNIX profile that spans all
zones or only the computers in a specific zone are similar.
Using Active Directory Users and Computers, scripts, or your existing provisioning process, the basic workflow for a new group would be similar to this:
1. Create a new Active Directory group for access to UNIX computers in the UNIX Groups organizational unit (ou=UNIX Groups, ou=UNIX).
For example, if you are creating a new Active Directory group for the denali project team in the parent zone arcadeGlobal, use Active Directory Users
and Computers to create a new group named arcadeGlobal_denali.
2. (Optional) Add users to the group if you know who to add.
For example, if you are creating the group for a new project and you have a list of authorized users for that project, you can click the Members tab to add
those Active Directory users to the new group. If those Active Directory users have a valid UNIX profile and role assignment in the zone, their secondary
group membership is updated with the new group.
3. Add the new Active Directory group to the appropriate zone provisioning group. If you are adding the group to the parent zone, you add the user to the
“groups” provisioning group parentZoneName_Zone_Groups.
If you wanted to create the profile in a child zone instead of the parent zone, you would add the Active Directory group to the
childZoneName_Zone_Groups. If you use some other naming convention for the provisioning group, you would search for and select that group.
4. Run the Zone Provisioning Agent update command in preview mode to verify your changes. For example:
example:
zoneupdate zoneName
6. The Zone Provisioning Agent creates a UNIX profile for the group in the zone based on the business rules you defined.
Note: If you remove an Active Directory group from the Active Directory provisioning group, the Zone Provisioning Agent removes the UNIX
group profile from the zone.
Using the Zoneupdate Program for Controlled Automation
You can use the zoneupdate.exe program with command line options to provision profiles in controlled way, allowing you to verify that profiles and access
rights are defined correctly for subsets of users or groups without affecting the production environment.
At a minimum, you must specify the zone name or canonical name for the zone to use the zoneupdate.exe program. The command line options are similar to
the options available on the Provisioning tab when you display a zone’s properties.
For example, to use the provisioning properties defined for a zone, you only need to specify the zone name at the command line:
zoneupdate default
If you use the canonical name for the zone, you specify the full path to the zone:
zoneupdate "centrify.com/program data/Centrify/zones/default"
You can override the default provisioning properties for a zone by specifying one or more of the following command line options.
Options are not case-sensitive. If you specify an option more than once, only the last value is used.
Use this option To specify
The name of a source zone. If you do not specify a zone name and there’s not a source zone defined in the zone’s
/z:ZoneName or provisioning properties, you cannot use the zoneupdate command to copy user or group attributes from one zone to
/SourceZone:ZoneName another. A source zone is required for classic zones. It is optional for parent hierarchical zones, but can be useful if you are
migrating from classic to hierarchical zones.
/d:DomainName or The name of the domain to process. If you do not specify a domain name, the zoneupdate program processes the Active
/Domain:DomainName Directory domain to which the computer is joined.
/dc:DCName or The name of the target domain controller to connect. No option - This will use the default domain controller of target
/DomainController:DCName domain.
The method to use to set the user’s numeric identifier (UID) value. You can specify any one of the following values: Auto to
generate UIDs based on the Active Directory domain name and the RID of a user object. This setting is equivalent to
selecting Generate from user SID in the Provisioning tab. AppleScheme to generate UIDs based on the Apple algorithm for
generating numeric identifiers from the Active Directory user object's objectGuid. This setting is equivalent to selecting
Generate using Apple scheme in the Provisioning tab. RFC2307 to use the uidNumber attribute in the Active Directory
/uu:Option or
RFC2307 schema for the user’s UID value. ZoneDefault to use the UID defined on the User Defaults tab for the zone. If
/UserUid:Option
there’s no default value, the Next UID value for the zone is used. SourceZone to copy the UID from the same user in a
specified source zone. EmployeeId to copy the UID from the employeeId attribute of the user object. EmployeeNumber to
copy the UID from the employeeNumber attribute of the user object. uidNumber to copy the UID from the uidNumber
attribute of the user object. If you don’t use one of these values, you can set the UID to not have any value. For example:
/uu:empty If you use this setting, users will have an incomplete profile in the zone.
The method to use to set the user’s name. You can specify any one of the following values: sAMAccountName to use the
Active Directory user’s sAMAccountName attribute as the UNIX user name. CN to use the user's common name (CN)
/un:Option or attribute as the UNIX user name. RFC2307 to use the uid attribute in the Active Directory RFC2307 schema as the UNIX user
/UserName:Option name. ZoneDefault to use the user name defined on the User Defaults tab for the zone. If there’s no default value zone, the
sAMAccountName is used. SourceZone to copy the user name from the same user in a specified source zone. If you don’t
use one of these values, you can set the user name to an explicit value. For example: /un:hunter
The method to use to specify the user’s default login shell. You can specify any one of the following values: RFC2307 to use
/us:Option or the loginShell attribute in the Active Directory RFC2307 schema as the default shell. ZoneDefault to use the shell specified
/UserShell:Option on the User Defaults tab for the zone. SourceZone to copy the shell defined for the user in a specified source zone. If you
don’t use one of these values, you can set the login shell using an explicit value. For example: /us:/bin/bash
The method to use to specify the user’s default home directory. You can specify any one of the following values: RFC2307 to
use the unixHomeDirectory attribute in the Active Directory RFC2307 schema for a user as the default home directory.
/uh:Option or
ZoneDefault to use the home directory specified on the User Defaults tab for the zone. SourceZone to copy the home
/UserHomeDirectory:Option
directory defined for the user in a specified source zone. If you don’t use one of these values, you can set the home
directory to an explicit value. For example: /uh:/home/hunter
The method to use to specify the user’s primary group identifier. You can specify any one of the following values:
AppleScheme to generate the user’s primary group identifier (GID) based on the Apple algorithm for generating numeric
identifiers from the Active Directory objectGuid for the user’s primary group. Note that the user's primary group must
configured for the zone. If the primary group is not configured for the zone, an error will be logged in the Windows Event Log
when the user is provisioned. This setting is equivalent to selecting Generate using Apple scheme in the Provisioning
tab. PrimaryGroupSID to generate the user’s primary group identifier (GID) based on the Centrify algorithm for generating
numeric identifiers from the Active Directory security identifier of the user’s primary group. PrivateGroup to set the user's
primary GID value to be the same as the user‘s UID value. RFC2307 to use the gidNumber attribute f in the Active Directory
/ug:Option or
RFC2307 schema as the primary group identifier or a user. ZoneDefault to use the primary group specified on the User
/UserPrimaryGroup:Option
Defaults tab in the zone. If there’s no default value, zoneupdate.exe will stop provisioning the user. SourceZone to copy the
primary group defined for the user in a specified source zone. example: /ug:empty If you use this setting, users will have an
incomplete profile in the zone. GroupMembership to set the user's primary GID based on the user’s Active Directory group
membership. If a user is a member of the Active Directory groups ops-mgrs and ops-labs and one of those groups has a
UNIX profile in the zone but not the other, the group with the UNIX profile in the zone will be used as the primary GID for the
user. If both group have a UNIX profile in the zone, the one with higher priority will be used. You can set the priority for
selecting the primary group to use in the Access Manager console. If the priority is the same, zoneupdate.exe will stop
provisioning the user. If you don’t use one of these values, you can set the primary GID to not have any value.
The method to use to specify the user’s GECOS field. You can specify any one of the following values: RFC2307 to use the
/uc:Option or gecos attribute in the Active Directory RFC2307 schema for a user. ZoneDefault to use the value defined for the GECOS
/UserGecos:Option field on the User Defaults tab for the zone. If you don’t use one of these values, you can set the primary GID value to an
explicit value. For example: /uc:Thompson, Hunter S.
The method to use to set the group numeric identifier (GID) value. You can specify any one of the following values: Auto to
generate the GID based on the Active Directory domain name and the RID of a group object. This setting is equivalent to
selecting Generate from group SID in the Provisioning tab. AppleScheme to generate GIDs based on the Apple algorithm for
generating numeric identifiers from the Active Directory group object's objectGuid. This setting is equivalent to selecting
/gg:Option or
Generate using Apple scheme in the Provisioning tab. RFC2307 to use the gidNumber attribute in the Active Directory
/GroupGid:Option
RFC2307 schema for the group GID value. ZoneDefault to use the GID defined on the Group Defaults tab for the zone. If
there’s no default value, the Next GID value for the zone is used. SourceZone to use the GID defined for the group in a
specified source zone. If you don’t use one of these values, you can set the GID to not have any value. For example:
/gg:empty If you use this setting, groups will have an incomplete profile in the zone.
The method to use to set the group name. You can specify any one of the following values: samAccountName to use the
Active Directory group samAccountName attribute as the UNIX group name. CN to use the group's common name (CN)
/gn:Option or attribute as the UNIX group name. RFC2307 to use the cn attribute in the Active Directory RFC2307 schema as the UNIX
/GroupName:Option group name. ZoneDefault to use the group name defined on the Group Defaults tab for the zone. If there’s no default value,
the sAMAccountName is used. SourceZone to copy the group name from the group in a specified source zone. If you don’t
use one of these values, you can set the group name to an explicit value. For example: /gn:apps-lab
An Active Directory group to use to populate a Centrify zone with users. Use the sAMAccountName and, optionally, the
domain name to identify the group. For example, to use the Active Directory engineers group in the currently connected
/u:ADGroupName or domain to populate users in the default zone: zoneupdate /u:engineers default To use the Active Directory engineers group
/UserSource:ADGroupName in a specific domain, you can use the /d:DomainName option or group_name@domain_name. For example to use the
Active Directory engineers group in the testdomain.org domain to populate users in the default zone: zoneupdate
/u:engineers@testdomain.org default
An Active Directory group to use to populate a Centrify zone with groups. Use the sAMAccountName and, optionally, the
/g:ADGroupName or
domain name to identify the group. For example, to use the Active Directory employees group in the currently connected
/GroupSource:ADGroupName
domain to populate groups in the default zone: zoneupdate /g:employees default
Display detailed information about the provisioning of users and groups. When you use this option, the output format is:
/v or /Verbose
Group: groupname:gid User: uid:username:shell:home:primarygid
Preview the users or groups to be provisioned or removed. In preview mode, the zoneupdate.exe program does not create or
/p or /Preview
remove any UNIX profiles.
Enable logging to the Event log. You can use the Event Viewer to check the log results. For the log level, you can specify any
one of the following values: None - don't write any provisioning activities to the Event log. This is the default setting. Normal
/el or /EventLog: Level
- Write only the name of the provisioned users and groups to the Event log. Verbose - Write the UNIX profiles for the
provisioned users and groups to the Vent log.
Enable logging and set the level of detail recorded in the log file. For the log level, you can specify any one of the following
values: Error to log only error messages. Warning to log warnings and error messages. Information to log informational
messages, warnings, and errors. Verbose to log all messages, including details about the user and group profiles created or
/l or /Log:Level
removed. Logging is off by default. If you enable logging, the default file location for the log file is:
C:\Users\user_name\AppData\Roaming\Centrify\Zone Provisioning Agent\Log You can change the default log file path by
modifying the following registry key: HKEY_LOCAL_MACHINE\Software\Centrify ZPA\LogLevel
Using Any Active Directory Attribute in a Profile
In addition to the provisioning properties you can set for a zone using Access Manager, you can manually configure the Zone Provisioning Agent to use any
attribute in Active Directory to define a value for any field in automatically-provisioned UNIX user or group profiles. For example, if your organization uses a
custom attribute, such as org_global_id, for all users, you can manually configure the Zone Provisioning Agent to use that attribute for the numeric user
identifier (UID) in automatically-generated user profiles.
To manually specify an Active Directory attribute to use in a UNIX profile:
1. Open Microsoft ADSI Edit.
2. Select a target zone, right-click, then click Properties.
3. Select the description attribute, then click Edit.
4. Type a profile provisioning attribute and specify the Active Directory attribute to use for the profile.
The valid provisioning attributes are:
provisioning_custom_uid_attribute
provisioning_custom_gid_attribute
provisioning_custom_primary_group_attribute
provisioning_custom_user_unixname_attribute
provisioning_custom_group_unixname_attribute
provisioning_custom_home_directory_attribute
provisioning_custom_shell_attribute
The format for the entry is:
provisioning_custom_uid_attribute:attribute_name
Replace attribute_name with the Active Directory attribute you want to use. For example:
5. Click A d d, then click O K.
6. Run the Zone Provisioning Agent update command in preview mode to verify your settings. For example:
example:
zoneupdate zoneName
If the Active Directory attribute type is different from the target profile value, the Zone Provisioning Agent attempts to convert the data type. If the data
conversion fails, the Zone Provisioning Agent reports an error and stops the provisioning process.
Provisioning Users When Across Trusted Domains
The Zone Provisioning Agent includes two utilities in its Tools folder to assist you in provisioning users when there are trust relationships between domains.
These two utilities are CopyGroup and CopyGroupNested. These utilities enable you to mirror group membership or a group hierarchy from a trusted domain
and forest in a target domain and forest.
To use these command line utilities, you must have an account that can log on to the trusted source domain and the target domain. The account should also
have read permission on the source domain and permission to update the target domain.
For example, assume you have configured the AJAX domain to have a one-way trust with the ACME domain and you have your Active Directory users and
groups defined in the ACME domain. If you want to allow the users and groups in the ACME domain to log on to computers that are joined to the AJAX domain,
you can log on to the AJAX domain controller with an account that has administrative privileges in both the AJAX and ACME domains, then run the CopyGroup
utility to mirror the group membership from a group in the ACME source domain as zone users in the AJAX target domain.
For more information about the command line arguments and options for these utilities, see the usage message displayed for each utility.
Monitoring Provisioning Events
The Zone Provisioning Agent writes events to the Windows event log. You can use tools that monitor the event log to notify you of specific provisioning
events. The following table lists the event identifiers and messages the Zone Provisioning Agent records.
Event Severity Event description and sample message
Summarizes the result after a provisioning run. Centrify zones updated. Domain controller: domain_controller_name Container:
1 Information
container_name Start time: start_time End time: end_time Successful: successful_message Failure: failure_message
2 Error Indicates that provisioning failed for a specific domain because the domain was not found. Domain domain_name not found.
Indicates that provisioning failed because the domain controller was not accessible. Domain server domain_controller_name is
3 Error
down.
4 Error Indicates that provisioning failed because the domain was not operational. Domain domain_name is not operational.
Indicates that provisioning failed without a specific cause. Failed to update zones in domain domain_name on domain controller
5 Error
domain_controller_name.
Indicates that provisioning failed because there was a problem with the agent connecting to the Active Directory. Failed to update
6 Error
zones in domain domain_name on domain controller domain_controller_name. Error on Active Directory service.
Indicates that provisioning failed because there was an unexpected error when updating the zones in a specific domain. Unexpected
7 Error
error when updating the zones in domain domain_name on domain controller domain_controller. Details: detail_message.
Provides verbose user provisioning information, including details about the provisioned user profile. User provisioned to a Centrify
8 Information zone. User: user Zone: zone UID: uid Name: name Shell: shell Home directory: home_directory Primary group: primary_group Gecos:
gecos
9 Information Provides basic user provisioning information. User provisioned to a Centrify zone. User: user Zone: zone
Provides verbose user de-provisioning information, including details about the user profile removed. User removed from a Centrify
10 Information zone. User: user Zone: zone UID: uid Name: name Shell: shell Home directory: home_directory Primary group: primary_group Gecos:
gecos
11 Information Provides basic user de-provisioning information. User removed from a Centrify zone. User: user Zone: zone
Provides verbose group provisioning information, including details about the provisioned group profile. Group provisioned to a
12 Information
Centrify zone. Group: group Zone: zone GID: gid Name: name
13 Information Provides basic group provisioning information. Group provisioned to a Centrify zone. Group: group Zone: zone
Provides verbose group de-provisioning information, including details about the group profile removed. Group removed from a
14 Information
Centrify zone. Group: group Zone: zone GID: gid Name: name
15 Information Provides basic group de-provisioning information. Group removed from a Centrify zone. Group: group Zone: zone
Indicates that the Zone Provisioning Agent received a warning message during the provisioning process. Warning occurred when
16 Warning
provisioning a Centrify zone. Zone: zone Details: detail_message
Indicates that provisioning failed because there was a problem with the permissions on the account used to run the Zone Provisioning
17 Error
Agent. Insufficient permission to setup the log file. Please contact your local administrator. Details: detail_message
Indicates that provisioning failed because there was a problem with creating the log file in the log file location. Failed to create the log
18 Error
file. Please contact your local administrator. Details: detail_message
Indicates that provisioning is paused to allow another provisioning cycle to complete. Zone Provisioning Agent failed to start another
19 Information provisioning cycle at current_time because the previous provisioning cycle is not yet complete. The provisioning request is pending
until Zone Provisioning Agent finishes the previous provisioning cycle.
Indicates that provisioning failed because the computer was not found in the domain being provisioned. This computer is not joined to
20 Error
a domain or the domain is not available.
Indicates that provisioning failed because there was a problem loading domain information. Failed to load domain information. No
21 Error
zone will be provisioned. Error: error_message
Indicates that provisioning failed because there was a problem with the functional operation of the domain. Functional error occurred
22 Error
with domain domain_name.
Indicates that provisioning failed because authentication failed for the account used to run the Zone Provisioning Agent. Domain
23 Error
domain_name authentication failed.
24 Error Indicates that provisioning failed because the authentication system failed. Domain domain_name authentication (system) failed.
Indicates that provisioning failed because there was an unexpected error when loading a specific domain. Unexpected error occurred
25 Error
when loading domain domain_name.
26 Error Indicates that provisioning failed because the Active Directory forest was not found. Forest forest_name not found.
27 Error Indicates that provisioning failed because the root domain controller was not accessible. Forest server server_name is down.
28 Error Indicates that provisioning failed because the forest was not operational. Forest forest_name is not operational.
Indicates that provisioning failed because there was a problem with the functional operation of the forest. Functional error occurred
29 Error
with forest forest_name.
Indicates that provisioning failed because authentication failed at the forest level for the account used to run the Zone Provisioning
30 Error
Agent. Forest forest_name authentication failed.
Indicates that provisioning failed because the authentication system failed at the forest level. Forest forest_name authentication
31 Error
(system) failed.
Indicates that provisioning failed because there was an unexpected error at the forest level. Unexpected error occurred when loading
32 Error
forest forest_name.
Indicates that provisioning failed because there was an error during the provisioning process. Error occurred when provisioning a
33 Error
Centrify zone. Zone: zone Details: detail_message
Indicates that provisioning might be incomplete because the account used to run the Zone Provisioning Agent does not have
34 Warning
permission update zone in a specified domain. Insufficient permission to update the zones in domain domain.
Adding New Profiles Manually
Provisioning groups enable automated provisioning of UNIX profiles for users and groups with the Zone Provisioning Agent. Server Suite does not require you
to use provisioning groups and business rules to create new users and groups. You can also manually create UNIX users and groups in any zone using the
Access Manager console, ADedit, or custom scripts. Adding profiles manually to a zone provides you with control over the definition of individual UNIX profiles
on a zone-by-zone basis.
Validating Operations After Deploying
This section provides sample activities for creating test cases and performing a formal validation of the Server Suite deployment. Although not required,
executing a set of test cases that exercise Server Suite functionality will help you validate operations before extending the deployment to additional
computers in the enterprise.
The specific use case scenarios and test cases you execute will depend on your organization’s goals and requirements.
Understanding Testing as Part of Deployment
Most organizations initially deploy in a lab environment that simulates the production environment. The lab environment allows you to test the planned
changes to system and user management processes. For example, if you plan to automate migration using scripts, you should build and test the operation of
your tools to verify they work as you intend. After testing in a lab, most organizations move to a pilot deployment with a limited number of computers and
users to continue verifying that authentication, authorization, and directory services are all handled properly in a real-world environment before moving to a
full-scale migration across the enterprise.
In many cases, the pilot deployment also requires more formal testing of specific use cases to validate the deployment before rolling out software to
additional computers. This phase of the deployment may also include activities designed to help users transition to Active Directory.
To validate the deployment:
Execute test cases that verify authentication.

Execute test cases the verify authorization rules for login access and restricted access.
Execute test cases that verify the provisioning process.
Execute test cases that address issues unique to your organization or your user community.
Other activities you may want to perform as part of the validation process include:
Test configuration changes and customize configuration parameters.
Document test results.
Troubleshoot any authentication or authorization issues, if any are found.
Train staff on new procedures.
Communicate process changes to the users who are migrating to Active Directory.
For example, if you plan to eliminate local account access, implement stricter password policies, or apply new access controls, you should prepare the
user community for these changes.
Validating Basic Authentication and Password Policy Operations
Before you begin testing organization-specific scenarios, such as the integration of migration scripts or customized access control policies, you should verify
basic operations are handled as expected. At a minimum, you should perform some of the following tests to verify basic operations:
Verify a UNIX profile exists for the Active Directory users and groups to be used in testing.
Verify the UNIX computer has successfully joined an Active Directory domain and the computer account has been created correctly.
Verify an Active Directory user assigned the UNIX Login role is authenticated and can access computers in the zone used for testing.
Verify migrated users assigned the UNIX Login role can log on using their UNIX or Active Directory user name and Active Directory password.
Verify an Active Directory user assigned the Listed role has a valid UNIX profile, but cannot log on to computers in the zone used for testing.
Verify that workstation authorization or account lockout policies defined in Active Directory are enforced.
Verify that password management policies defined in Active Directory are properly enforced.
Verify that a previously authenticated user is authenticated successfully when the UNIX lab computer is offline.
Verify that common lookup commands and commands that require user and group information work as expected.
You can verify authentication, authorization, and password policy operations by setting options in Active Directory and attempting to log on and log off the
computers in the pilot deployment.
Running Commands on the Unix Computer to Verify Operations
To confirm that a UNIX computer is a member of the Active Directory domain, you can run commands that retrieve information from Active Directory on the
UNIX lab computer itself or by viewing the UNIX computer’s account information in Active Directory Users and Computers or the Access Manager console.
Verify the Computer is Joined to Active Directory
To verify a computer is joined to the Active Directory domain and is retrieving information from Active Directory by running commands on the UNIX computer:
1. Log on to the UNIX computer.
2. Type the following command to retrieve information about the computer’s connection to Active Directory:
adinfo
This command returns basic information such as the host name for the computer, whether the computer is joined to the domain, and whether the
computer is currently connected to Active Directory. For example:
Local host name: magnolia

Joined to domain: ajax.org
Joined as: magnolia.ajax.org
Current DC: ginger.ajax.org
Preferred site: Default-First-Site-Name
Zone: ajax.org/Centrify/Zones/default 
.
.
.
</page\>
<explainpage textid="CentrifyDCPamUidConflict_Explain" />
</policy>
<policy title="Create k5login" valuename="pam.create.k5login">
<valueon value="true" />
<valueoff value="false" />
<explainpage textid="CentrifyDCPamCreateK5Login_Explain" />
</policy>
</category>
</category>
</class>
Use the following keywords to define the policy:
For this
You can specify
type
Specifies the node in which to place the policy. Use one of the following with the type keyword: Machine: Computer Configuration node User:
class
User Configuration node Both: Computer and User Configuration nodes
Specifies the folder for the policy. You can place a set of related policies in a single category. You can also nest categories by placing
category
subfolders within a folder. Use title or titleid to name a category folder.
For this
You can specify
type
Specifies the registry setting. You can define the registry key at different levels, including category, policy, policy page or UI control, and it
keyname
applies to all child levels. You can also override the setting at any child level. You should determine whether to use an existing registry key or
keynameid
create a new, custom key. See Defining the User Interface for a Policy for a discussion of when to use keynameid instead of keyname.
Defines the policy. Use title or titleid for the display name, keyname or keynameid to specify the registry key, and page to define the property page
policy
user interface.
Provides a page on which you can provide an explanation or instructions for the policy. The best practice is to provide a textid string for the
explainpage page, and define the content (the explanatory text) of this and other strings in a separate section of the file. See Defining the User Interface
for a Policy for more information.
Defines the property page for the policy. Use title or titleid for the page title. See Defining the User Interface for a Policy for a description of the
page
tags you can use within page tags to define the property page.
Defining the User Interface for a Policy
You define the user interface for a group policy property page using the page tag. The template provides a number of tags that enable you to define a variety
of controls, buttons, and dialogs for finding and entering Active Directory information to set group policies. Place any of the following tags within the page
/page tags to define the user interface:
Note: This chapter is not intended as a complete reference to the xml schema for an administrative template file, but rather shows how tags are
commonly used to define a policy. For example, the current section shows how to construct the user interface to a group policy property page;
specifically, it shows the tags used to create the user interface of the group policy property page. A complete reference would also show all the
elements that could go into creating a dialog box, but this is not generally relevant to creating a property page and hence is not covered in this
chapter.
| For this type | You can specify | |-----|-----| | text | Defines a text label control. Use text or textid to define the text to be displayed in the text label. | | groupbox |
Groups a set of UI controls on a policy page. Use text or textid to provide a name for the box. Use keyname or keynameid to specify the registry setting. Setting the
registry key at this level overrides any setting at a higher level, for example, at the category level. | | edittext | Creates a box in which a user can enter text. It
requires the valuename keyword and value. The value should be the name used in the registry, if applicable. You can also use the following with edittext:
* text or textid to display a name for the box.

* default to display a default value when the policy is first enabled.
* keyname or keynameid to specify the registry setting. Setting the registry key at this level overrides any setting at a higher level, for example, at the category
level.
* maxlength value maximum length of the string
* charcasing to specify whether to leave the case of characters in the box as is or convert them to lowercase or uppercase. The default is to leave them as is
(Normal).
* required to require a value be set.
* readonly to specify whether the value can be changed. The default is to allow the value to be changed (false).
* button to define a button to be displayed after the text control box.
* validation to define validation for user input. | | numeric | Creates a numeric text box control that allows a user to adjust a numeric value up or down. It requires
the valuename keyword and value. The value should be the name used in the registry, if applicable. You can also use the following with numeric:

level.
* valuetype to display the type of the value in the registry setting.
* default to display a default value when the policy is first enabled.
* min value to set the minimum value allowed.
* max value to set the maximum value allowed.
* spin to define the amount to increment or decrement on each button click. The default increment is 1.
* decimalplaces to specify the number of decimal places for the value to be filled in. The default is 0.
* required to specify that the user must enter a value. The default is false, that is, the field is not required.
* validation to define validation for user input. | | listbox | Provides a list view in which a user may add, remove, or edit setting values. Use dialog to associate a
dialog box that enables a user to add a new entry or edit an existing entry in the list box. Specify the type of the listbox (listboxtype) to specify the kind of values
the listbox generates:
* Single The box contains one column and generates a single value that is a concatenation of values from all rows separated by the separator attribute.
* Prefix The box contains one column and generates a list of registry values. The registry value name is defined by the prefix attribute and with a row number
appended to the prefix name.
* Explicit The box contains two columns and generates a list of registry values. The first column contains the registry value name while the second column
contains the registry value.
You can also use the following with listbox:

level.
* prefix to define the prefix of the value name of the registry setting. Use this attribute with a listtype of Prefix.
* separator to separate values when the listtype is Single.
* min to set the minimum number of rows allowed.
* max to set the maximum number of rows allowed.
* sort to specify whether sorting is enabled in the list box. | | checkbox | Boolean values. This keyword requires the valuename keyword and value, and the valuetype.
The value should be the name used in the registry, if applicable. You can also use the following with this checkbox:

level.
* checked to set the check box to checked when the policy is first enabled. Without this keyword, the check box is not checked by default.
* valueon to define the registry setting when the check box is checked.
* valueoff to define the registry setting when the check box is not checked. | | radiogroup | Defines a set of two or more radio buttons (radiobutton) from which a
user must make a single choice. This keyword requires the valuename keyword and value, and the valuetype. The value should be the name used in the registry, if
applicable.
You can also use the following with radiogroup:

level.
* radiobutton to define radio buttons for the control. Use checked=true to specify the default radio button. | | radiobutton | A list of suggestions to allow the user to
select or type a value. It requires the valuename keyword and value. The value should be the name used in the registry, if applicable. You can also use the following with
combobox: * textortextidto display a name for the box. *checkedto define the default state for the radio button. The default isfalse(not checked). *valueonto specify
a value to be written to the registry when the radio button is checked. | | dropdownlist | A list of suggestions to allow the user to select a value. It requires thevaluenamekeyword andvalue.
The value should be the name used in the registry, if applicable. You can also use the following attributes with dropdownlist: * valuetypeto define the type of value in the registry
setting. *textortextidto display a name for the box. *keynameorkeynameidto specify the registry setting. Setting the registry key at this level overrides any setting at a higher
level, for example, at the category level. *editableto specify whether the value in the dropdown list may be edited. The default isfalse(cannot be edited). *requiredto require a value
be set. *sortto specify whether sorting is enabled in the dropdown list box. You can use the following tags withindropdownlist: * listitemto define an item in the drop-
down list. *validationto define validation for user input. | | button | Creates a button for a text field defined byedittext. Use the dialog or adbrowse tags with button to define a
dialog box to be shown when a user clicks the button. You can also use the following attributes with button: * textortextidto display a name for the box. *valueidto
identify the value returned from the dialog box that is launched by clicking the button. | | dialog | Provides a dialog box. You associate a dialog box to a button or to alistbox. Use
titleortitleidto specify the title for the dialog. You can use the following child tags to define a dialog box: *groupboxto define a group box control in the dialog. *textto
define a text control in the dialog. *edittextto define a text edit box control in the dialog. *numericto define a numeric up down control in the dialog. *listboxto define a list box
control in the dialog. *checkboxto define a check box control in the dialog. *radiogroupto define a group of radio button controls in the dialog. *dropdownlistto define a drop
down list control in the dialog. *validationto define the validation on the user inputs in the dialog. | | adbrowse | Provides a dialog box for browsing. You associate an adbrowse dialog box
to a button or to alistbox. Use textortextidto specify the title for the dialog. To browse Active Directory, useadbrowsetype to identify the type of browsing: 
 *FindADUser *FindADGroup *FindUnixUser *FindUnixGroup *FindComputer Usemultiselectto define whether a user can select multiple search
results in the Active Directory browse dialog. Useseparatorto specify the separator for multiple results. You can use the following child tags to define anadbrowsedialog
box: *groupboxto define a group box control in the dialog. *textto define a text control in the dialog. *edittextto define a text edit box control in the dialog.
 *numericto define a numeric up down control in the dialog. *listboxto define a list box control in the dialog. *checkboxto define a check box control in the dialog.
 *radiogroupto define a group of radio button controls in the dialog. *dropdownlist` to define a drop down list control in the dialog. |
Using String IDs
When entering strings, such as text, keynames, and titles, you have the choice of using strings or string IDs. String IDs offer several advantages, such as a
cleaner, more modular design, and the ability to customize the text if you plan to port to different languages.
The best practice is to put the string IDs in a ‘Strings’ section of the template file, which makes them easy to locate and modify in case of porting to other
languages.
For example, the following segment from a template file shows how the explainpage tag specifies a string ID to attach explanatory text for a policy to the
policy dialog box, while the actual text is defined in a ‘Strings’ section at a different place in the template:
- 
- <policy title="Set login password prompt"

valuename="pam.password.enter.enabled">
- <page\>
- <edittext text="Set login password prompt"

valuename="pam.password.enter.mesg"
maxlength="1024" default="Password:">
</edittext>
</page>
__<explainpage textid="CentrifyDCPasswordPrompt_Explain" />__
</policy>
- 
- <![CDATA[
using System;
using System.Text;
public class Utility
/// <summary>
/// Check for a list of Unix names separated by seps
/// </summary>
/// <param name="value">\</param>
/// <param name="seps">\</param>
/// <param name="displayText"></param>
/// <returns></returns>
public static string[] CheckUnixNames(string value, char[]

seps, string displayText)
]]>
</code>
</dotnetscript>
Adding a Mapper Program to the Agent
To implement group policies for UNIX computers and users, you need to create the custom scripts or programs that modify the appropriate UNIX
configuration files or settings. You can create the programs or scripts using the programming or scripting language of your choice. Most of the Centrify
policies use Perl scripts and you can use those scripts for models if you choose to use Perl.
Once you create a program or script to implement a group policy, you need to:
Place the program or script in the /usr/share/centrifydc/mappers/machine directory if it is a computer configuration group policy, or in the
/usr/share/centrifydc/mappers/user/user_name directory if it is a user configuration group policy.
Make the program or script an executable file.
Use the runmappers command to test that the program or script works as expected and updates the appropriate configuration file.
By default, when you use the runmappers command, it executes all of the programs in both the /usr/share/centrifydc/mappers/machine and the
/usr/share/centrifydc/mappers/user/user_name directories. Optionally, you can run the command to only execute your custom program. For example, if you have
created an executable script called setport.pl as a UNIX computer configuration policy and placed the file in the /usr/share/centrifydc/mappers/machine directory, you
could use a command similar to the following to execute the script along with the other computer configuration mapper programs and test its behavior:
runmappers machine map
Note: To run the mapping programs for a user, you must specify the user’s UNIX login name to identify which user’s group policies should be
mapped or unmapped. For example, to run the mapping programs for the UNIX user account jgarcia in the /usr/share/centrifydc/mappers/user/jgarcia
directory, you could use a command similar to the following:
runmappers user jgarcia map
Network Information Services
This section provides a brief overview of Network Information Services (NIS), including the basic advantages and limitations of using NIS to publish
information. It also describes the Centrify solution for using NIS to respond to client authentication and lookup requests.
You should use this section to help you determine whether the Centrify Network Information Service (adnisd) is an appropriate solution for your organization's
needs.
Introduction to the Basics of NIS
In some environments, a Network Information Server (NIS) provides centralized storage and distribution of information that needs to be known throughout
the network. In a typical NIS environment, one or more NIS servers are used to centrally manage a set of database maps that correspond to the system
configuration files that are commonly found on UNIX systems. For example, there are NIS maps that correspond to the /etc/passwd, /etc/group, /etc/hosts, and
/etc/services files. The maps provide the centralized information to a given set of computers that make up a NIS domain.
Each NIS map corresponds to a specific configuration file, such as the /etc/passwd or /etc/hosts file, and consists of a set of keys and values, and a version
number for the data. When computers on the network require information stored in NIS maps, they send a NIS client request to the NIS listening port to
query the NIS server for the information.
When a computer needs the information stored in a NIS map, it runs the ypbind process to identify and connect to the NIS server best suited to respond to its
requests. When the NIS server receives a request, it replies with the appropriate information from its set of NIS maps.
Limitations of using NIS
Although NIS can be very efficient in responding to queries for network information, it is not a secure mechanism for providing authentication and
authorization services. For example:
If NIS clients use the broadcast service to locate NIS servers on the network, intruders can easily introduce their own NIS server with their own privileged
accounts. Once a client binds to the rogue NIS server, the intruder can gain access to that client and perform unauthorized operations.
The NIS server’s only security policy is the securenets setting. The securenets setting identifies which NIS clients to accept queries from. If an intruder
impersonates a client that the securenets setting allows the NIS server to accept, he can download all of the NIS data. Even if an intruder fails the securenets
test, he could potentially inspect all of the NIS requests and decode the data to gain access.
If NIS is used for authentication, password hashes are sent around the network in clear text and can be easily captured and cracked, making client
systems vulnerable.
Because of these security risks, in most cases, you should plan to replace any legacy NIS environment with Active Directory as the central repository of
identity information and the Centrify Agent for *NIX (adclient) as the “client” requesting information. In some cases, however, if may not be practical or
desirable to completely replace an existing NIS infrastructure. To handle those cases, Centrify provides its own Network Information Service (adnisd) that
enables existing NIS clients to remain in place and co-exist with Active Directory.
Deciding to Maintain NIS in your Environment
Active Directory and the Centrify Agent for *NIX (adclient) provide more secure authentication, authorization, and directory services than provided by
traditional NIS client-server communication. Therefore, when you install the Centrify Agent and join a domain, the Name Service Switch configuration file,
nsswitch.conf, is normally modified so that account lookup requests are passed to Active Directory through the adclient process. This change to the nsswitch.conf
file effectively bypasses the NIS client and server environment.
There are some situations, however, in which maintaining an ongoing or temporary NIS environment may be desirable or necessary. For example:
If you have a legacy Network Information Server (NIS), you may have configured network information, such as netgroup or automount maps, that you want to
make available in response to client requests.
You may have applications that require access to a NIS server because they send requests directly to the NIS port and expect a NIS process to be
listening there.
You may have computers or devices, such as Network Attached Storage devices or computers with older or unsupported operating systems where you
cannot install the Centrify Agent, that need access to information normally stored in NIS maps. Those computers or devices cannot join an Active
Directory domain, but are capable of submitting NIS client requests. For those computers or devices, a NIS server may be the only option for providing
authentication and look-up services.
If any of these scenarios apply to your organization, you may want to plan a deployment that includes the Centrify Network Information Service to
complement the agent.
Using the Network Information Service
To support computers and applications that are capable of submitting NIS client requests to a NIS server, the Server Suite provides its own Network
Information Service. The Centrify Network Information Service, adnisd, is an optional process that can be installed on any computer where adclient is
installed.
Once installed and running, the Centrify Network Information Service functions like a standard NIS server, but it responds to NIS client requests using the
information stored in Active Directory, including any information imported from passwd and group NIS maps or from /etc/passwd and /etc/group files. The
Centrify Network Information Service has some of the same security limitations as a standard NIS server, but it does allow you to provide encrypted
authentication and directory service to computers where adclient cannot be installed.
The Centrify Network Information Service can be useful in environments where you plan a phased migration from existing NIS servers and clients or when the
environment includes legacy systems that you cannot migrate or upgrade to support the Centrify Agent for *NIX.
How NIS Client Requests are Processed
If you have decided to maintain a NIS environment, on either an ongoing or temporary basis, you can use the Centrify Network Information Service to replace
existing NIS servers and the Access Manager console to migrate NIS map data to Active Directory.
The Centrify Network Information Service (adnisd) can run on any computer that has the adclient agent service installed. Computers that need access to the
information stored in Active Directory can then be configured as NIS clients that send their NIS queries to the computer where both the adclient and adnisd
service run.
When adnisd receives a request from the NIS client, it checks its local cache of map data, then responds to the client that made the request. The local cache of
map data is generated from the map data adnisd receives from Active Directory.
The following figure provides a simplified view of operation.
Derived and Explicitly-defined Maps
Within the local cache, there are two types of maps: explicitly-defined maps and derived maps. Explicitly-defined maps are NIS maps imported into
Active Directory from an existing NIS domain, imported from text files, or created manually using the Centrify Access Manager console. Derived maps are
maps that are automatically generated from the information stored in Active Directory. Derived maps access the same data as the explicitly-defined maps
using different keys. For example, the user and group maps in the local cache are not retrieved directly from Active Directory, but are generated based on the
users and groups that have been enabled for the local computer’s zone.
The maps derived from the zone information are passwd.byname, passwd.byuid, group.byname, and group.bygid. These automatically generated maps are placed in the
local cache, and can then be used to look up or authenticate users by user name or by UID value, and groups by group name or by GID value. The Centrify
Network Information Service also generates derived maps for explicitly-defined network maps that are stored in Active Directory. If adnisd finds a NIS map
defined in Active Directory with a name it recognizes, such as netgroup or services, it automatically derives related maps. For example, a netgroup map will
automatically generate the netgroup.byhost and netgroup.byuser maps. A services base map will generate the services.byname and services.byservicename maps.
Accessing NIS Maps in the Local Cache
Periodically, theadnisdprocess connects to Active Directory through the adclient process to locate updates to explicitly-defined NIS maps. It then
synchronizes the local cache of NIS map data to mirror any changes detected in Active Directory. After polling Active Directory for updates to explicitly-
defined maps, the adnisd process retrieves all users and groups in the current zone from adclient, and generates the derived maps for user and group
information.
In essence, the computer where both adclient andadnisdrun acts as the NIS server for the local computer’s zone. The NIS clients on the network communicate
withadnisdusing Remote Procedure Calls (RPC) sent to the NIS port on the Centrify-managed computer. The adclient process is responsible for all
communication with Active Directory and maintains its own separate cache of data from whichadnisdcan derive the user and group information for the zone.
Theadnisdprocess then stores all of the explicitly-defined and derived maps in its own local cache of map data (in most cases, /var/centrifydc/nis/*).
Becauseadnisdalways responds to NIS client requests using the data in its local cache, it can respond even when Active Directory is not available.
The following figure provides a simplified summary of operation.
Note: Theadnisdprocess cannot be used with any legacy NIS servers in a NIS domain. It can only be used in conjunction with Active Directory and
the Centrify Agent for *NIX.
Migrating Information from Existing Maps
If you have a legacy NIS environment, you can import user, group, and network information from existing NIS servers and domains. To import the information
directly from an existing NIS server, you need to be able to access the NIS server and NIS domain from the Windows computer where the Access Manager
console is installed. For example, if you have configured an existing NIS server to be accessible over the Windows network using Samba or a similar program,
you can connect directly to that server and NIS domain to import maps. If the NIS server and NIS domain are not accessible from the Windows computer
where the Access Manager console is installed, you should export the NIS maps to text files, then import the text files.
Note: Importing existing maps simply provides a mechanism for migrating existing information to the Active Directory. Once the information is
imported into Active Directory, the original maps are no longer used and the Centrify Network Information Service uses Active Directory to
generate the maps it needs to service authentication requests.
For more information about importing existing user, group, or network information, see Importing and managing NIS maps.
Managing Automounts without Using NIS
If your primary reason for wanting to use NIS is to manage automount information, you have the option of storing the information in Active Directory then
retrieving it through the adnisd process or directly through an LDAP request that bypasses the adnisd process.
Note: The automount information must be stored in Active Directory. You can then choose whether to retrieve it using the Centrify Network
Information Service (adnisd) or an LDAP query.
As an alternative to using the adnisd process, you can use the optional adauto.pl script located in the /usr/share/centrifydc/etc directory to get automount data. The
adauto.pl script gets mount point information directly from Active Directory using LDAP. With the adauto.pl script, you can automount home directories using the
information from NIS maps without running the adnisd server process.
The adauto.pl script uses the information you store in the auto.home NIS map for the joined zone and any parent zones up the zone hierarchy from which the local
computer inherits NIS map entries. Once you add the script to your automount configuration, the automounter program invokes the script and passes it the user
name of the user logging on. The adauto.pl script then uses the ldapsearch command to retrieve the mount point information from Active Directory and returns
the path to the remote home directory for the user logging on. The automounter will then attempt to connect to that home directory.
To use the adauto.pl script:
1. Add the appropriate auto.home mount points to Active Directory by importing or creating automount NIS maps.
For more information about importing existing auto.home or auto_home NIS maps, see Importing Network NIS Maps. For information about creating NIS
network maps directly in Active Directory, see Creating new NIS Maps in Active Directory.
For example:
Open Access Manager to navigate to a specific zone.
Expand the zone to display NIS Maps.
Select NIS Maps, right-click, then click New > Automount.
Type auto.home or auto_home as the map name, then click O K.
Select the new map, right click, then click New to add a new individual map record. For example, create a map record similar to this for all users in a
zone:
Name: * Network Path: lmrh2:/home/&

Comments: This is the automount path for users in this zone
2. If you are managing mount points on Linux or Solaris, edit the /etc/nsswitch.conf file to change the automount entry from nis to files. For example:
vi /etc/nsswitch.conf
...
automount: files
For other platforms, such as AIX, you can skip this step.
1. Verify the adauto.pl file is available in the /usr/share/centrifydc/etc/ directory and is executable. For example:
ls -l /usr/share/centrifydc/etc/adauto.pl
total 1208
-rwxr-xr-x 1 root root 1921 Sep 27 10:37 adauto.pl
2. Create a symbolic link for /etc/auto.home or /etc/auto_home to the adauto.pl file. For example, on Linux computers:
ln -s /usr/share/centrifydc/etc/adauto.pl /etc/auto.home
On AIX computers, create the link to /etc/auto_home:
ln -s /usr/share/centrifydc/etc/adauto.pl /etc/auto_home
3. Edit the /etc/auto.master or /etc/auto_master file to call the /etc/auto.home file.
For example, on Linux computers add the following line to the auto.master file:
/export/home program:/etc/auto.home
The specific syntax for the entry is different on different platforms. For example, not all platforms allow you to specify the program keyword in the
/etc/auto.master file. For more information about the format of the entry, see the main page for auto.master. For example, on SuSE Linux, the entry should look
like this:
/export/home /etc/auto.home
On SuSE Linux 10, the corresponding entry is:
/export/home program /etc/auto.home
On AIX and Solaris computers, add an entry like this to the /etc/auto_master file:
/export/home /etc/auto_home
On some platforms, you can invoke automount from the command line without editing the /etc/auto.master file. For example, you can invoke automount without
editing the /etc/auto.master file by running a command similar to the following on Linux:
automount /export/home/ program /etc/auto.home
Command line mount points are not supported by automount on AIX.
4. Restart the autofs process. For example, on Linux:
service autofs restart
On AIX:
automount
On Solaris 10, the automount service is managed by the service management facility, smf, under the service identifier:
svc:/system/filesystem/autofs:default
You can use svcadm to perform administrative actions, such as stopping and restarting the service.
Mounting Home Directories with the nosuid Option
To increase security when automatically mounting file systems, you might want to configure the auto_home or auto.home NIS map to prevent users from
switching their user or group identity. You can prevent users from mounting file systems with a different user context by specifying the nosuid option.
To set the nosuid option in the auto_home or auto.home NIS map:
1. Open Access Manager to import or create a NIS map to be stored in Active Directory.
2. Expand the appropriate zone and the UNIX Data node to display NIS Maps.
3. Select NIS Maps, right-click, then click New > Automount.
4. Type auto.home or auto_home as the map name, then click O K.
5. Right-click the new map.
6. Click New > Map entry to add a new individual map record.
7. Set the fields in the map record similar to the following, to enable mounting of home directories with the nosuid option for all users in a zone:
Name: * Network Path: homeservername:/home/&

Options: -nosuid
You can use a similar approach to specify other or additional mount options—such as noexec and nodev—to the map entry.
Using Executable Maps
On some platforms, local maps that have the execute bit set in their file permissions can be executed by the automount program and provided with a key to be
looked up as an argument. The executable map is expected to return the content of an automount map entry on its stdout or no output if the entry cannot be
determined. Direct maps cannot be made executable.
For more information about executable maps, see the main page forautomount.
Testing the Status of the Automount Service
After restarting the automount service, you can check the status of the service. For example, on Linux run the following command:
service autofs status
On all platforms, you can run the following command and check the output to verify automount operation:
/usr/sbin/automount -V
You should see output similar to the following:
automount: /export/home mounted automount: no unmounts
Running the adauto.pl script
You can run the adauto.pl script with no command-line options to manually refresh the automount NIS maps on demand. Alternatively, you can manually add
the adauto.reloadtime configuration parameter to the /etc/centrifydc/centrifydc.conf file to control how frequently automount NIS maps are retrieved for the zone. If you
manually add this parameter to the configuration files, you can set the value to specify that maps with a time stamp older than the specified number of
minutes should be reloaded.
By default, the adauto.pl script gets automount NIS maps from the zone to which the local computer is joined. If the maps are not found in the joined zone, the
script will attempt to get the maps from its parent zone of the joined zone. Alternatively, you can create the file /var/centrifydc/kset.automap and type the common
name (CN) of the specific Centrify zone from which you want to load the automount NIS maps.
Testing the adauto.pl script results
After you have configured the auto.home and auto.master maps, you can test that the adauto.pl script is working by entering one of the following commands:
/etc/auto.home userid /etc/auto_home userid
This command should return the path from the auto.home or auto_home NIS map stored in Active Directory. For example:
/server/home/userid
Restarting the Automount Service
If you make any changes to the NIS maps in Active Directory, you should restart the automount service.
Distributing Automount Maps
You can create auto.master and auto.home files as NIS maps in Centrify zones and distribute them using symbolic links to the adauto.pl script. In this scenario, you
can take advantage of the capability to support executable maps. Depending on your operating system, however, you might be able to take advantage of the
Centrify NSS module to automatically mount home directories instead. If your operating system allows you to use the Centrify NSS module, you can add
centrifydc to the automount line in the /etc/nsswitch.conf file.
In most cases, you can use the Centrify NSS module to distribute auto.home maps. You cannot use this approach, however, to distribute the auto.master map on
most operating systems. For the auto.master map, your options are typically limited to doing one of the following:
using NIS.
using LDAP.
using a local file.
For information about using LDAP, see “Using the Centrify LDAP proxy service” in the Administrator’s Guide for Linux and UNIX. If you use a local file, you can
use an adedit script to synchronize the auto.master map to a local /etc/auto.master file. The following example illustrates the steps to synchronize the auto.master
map to a local /etc/auto.master file.
1. Add the File Copy group policy to a Group Policy Object that applies to Centrify-managed computers.
2. Enable the group policy to copy a script similar to the following to the directory /usr/share/centrifydc/mappers/machine:
#!/bin/sh
# Restart adedit using tclsh \
exec adedit "$0" "$@"
# Bind to an Active Directory domain \
bind -machine domain
# Select a zone context \
select_zone zone
catch {
select_nis_map auto.master
set output [open /etc/auto.master w 0644]
foreach line [gnm] {
puts $output [regsub ":1" $line ""]
}
close $output
}
}
By adding a script similar to this sample script to a GPO, every 90 to 120 minutes the group policy update will execute the script to read the contents of the
auto.master map in Active Directory and create a local copy of the /etc/auto.master file.
You can also use this same approach to synchronize all of the maps stored in Active Directory to the local /etc directory. For example:
#!/bin/sh
# Restarts using tclsh \
exec adedit "$0" "$@"
bind -machine [adinfo domain]
slz [adinfo zone]
foreach map [get_nis_maps] {
if ([regexp "auto*" $map]) {
slnm $map
set output [open /etc/$map w 0644]
foreach line [gnm] {
puts $output [regsub ":1" $line ""]
}
close $output
}
}
Discontinuing Use of Legacy NIS Servers
If you have existing NIS servers running on your network, you can configure your NIS clients to use the Centrify Network Information Service over time, as
needed. Once you have the Network Information Service running, you can also incrementally update the NIS data that’s stored in Active Directory using the
Access Manager console. Any updates you make are then propagated to all of theadnisdservers automatically.
When you are satisfied that you have all of the appropriate NIS information stored in Active Directory and have deployedadnisdacross the enterprise, as
needed, you can then stop any remaining legacy NIS servers and complete the migration to Active Directory for secure, centralized directory service.
Note: Although you can leave the standard NIS servers in place indefinitely, you should plan to migrate all of your data and NIS clients to use the
Centrify Network Information Service if you want you to centralize all authentication and directory service in Active Directory. Once you have
imported all of the data you need into Active Directory and configured your existing NIS clients to use the Centrify Network Information Service in
the appropriate zone, you can decommission any legacy NIS servers and stop any related services.
Preparing for Agentless Authentication for NIS Clients
This section describes the activities that are specific to preparing your environment to handle agentless authentication and authorization. If you only plan to
use Delinea Network Information Service (adnisd) to publish network information, such as automount mount points, netgroup membership rules, or custom maps,
you can skip this chapter.
Deciding to Use Agentless Authentication
Normally, the adclient agent is installed locally on a computer to handle all account authentication and lookup requests that need to be passed to Active
Directory. On computers and devices where you cannot install a Delinea Agent locally, you may be able to use the Delinea Network Information Service
(adnisd) to provide agentless authentication.
With agentless authentication, computers that have older or unsupported operating systems that can be, or already are, configured as NIS clients can submit
NIS requests to the Delinea Network Information Service. The Delinea Network Information Service can then check its cached Active Directory information to
verify whether a user or group has valid credentials and is authorized to log on.
The following figure provides a simplified view of this environment.
In this scenario, the Delinea zone acts as the NIS domain for a group of computers or devices that are configured as NIS clients. Those clients submit requests
to the Delinea Network Information Service, adnisd, listening on the NIS port.
The Delinea Network Information Service periodically contacts the adclient agent to get updated information from Active Directory and generates a set of
“maps” that it stores locally. The Delinea Network Information Service can then use the information in these maps to respond to NIS client requests for
authentication or other services.
The user and group “maps” are generated automatically based on the users and groups that have profiles currently enabled in the zone. Network information
and custom maps can also be published for a zone, but those maps must be manually imported or created. The maps for agentless authentication only
require you to add and enable a profile for each Active Directory user and group who should have access to the zone. In this way, the Delinea Network
Information Service can be used to service agentless authentication requests from computers or devices where adclient itself cannot be installed.
Planning for Agentless Authentication
In planning a deployment that supports agentless authentication for NIS clients, you should keep in mind that the zone associated with the computer where
adnisd is installed defines the scope of information available to the NIS clients that the adnisd process serves. Each instance of adnisd supports one and only one
zone, which is equivalent to a single NIS domain. The adnisd process can only look up information for the computers, groups, and users that exist in the same
zone as the local computer account, and all instances of the adnisd in the same zone respond to queries using the same information from Active Directory.
For users and groups to be available for agentless authentication, therefore, they must be enabled for the zone the Delinea Network Information Service
serves. In addition, each zone that supports agentless authentication requires an Active Directory attribute for storing the password hash for UNIX-enabled
users. The password hash is not created in Active Directory by default, so it must be generated then maintained using a password synchronization service
installed on all of your domain controllers. The Active Directory attribute that holds the password hash must be accessible to the computers you are using as
NIS servers in each zone.
Note: If you install the Delinea Network Information Service on multiple computers, whether in the same zone or across multiple zones, all of
these instances are zone-specific peers. There are no master/slave instances.
If you decide you want to use the Delinea Network Information Service to support agentless authentication, you should:
Identify the zones for which you want to publish information. For example, if you want user and group information broadly available to NIS clients across
the network and you have a parent zone, you may want to allow agentless authentication for all of the users in that zone. If you want to strictly control
which users can be authenticated to NIS clients, you may want to create a separate agentless-authentication child zone that only contains those users
and their groups. For each zone that supports agentless authentication, you must specify the Active Directory attribute for storing the password hash.
Identify the computers that should service NIS client requests in each zone. You can designate any computer that has the Delinea Agent installed to also
act as the Delinea Network Information Server in the zone. Any computer you want to use as the NIS server must have the Delinea Agent for *NIX
installed and must be joined to an Active Directory domain.
Install a password synchronization service on all of the domain controllers in the joined domain.
Install and configure the Delinea Network Information Service (adnisd) on the selected computers in each zone. On the computers that will act as NIS
servers in a zone, you must manually install and start the adnisd service. Alternatively, you can modify the startup script on each local computer so that
the adnisd process starts whenever the local computer is rebooted. You also may want to customize the configuration parameters that control the
operation of the adnisd process.
Configure computers and devices as NIS clients that bind to the Delinea Network Information Service on the selected computers in each zone. If any
existing NIS servers are running, you will need to reconfigure the NIS clients on the network to use the computer where the Delinea Network Information
Service is installed as their NIS server.
Import and enable the users and groups who need to be authenticated to NIS clients for the zone. You can migrate this information from existing NIS
servers or local configuration files by importing passwd and group NIS maps or local /etc/passwd and /etc/group files using the Import from Unix wizard, or
you can manually or programmatically create UNIX profiles for users and groups, as needed. The users and groups must have UNIX profiles stored in
Active Directory and enabled for the local computer’s zone for the Delinea Network Information Service to generate the maps it needs to service
agentless authentication and lookup requests from NIS clients.
Import and manage any additional NIS maps you want to make available to NIS clients. For example, you can import network maps such as netgroup and
automount NIS maps or create custom maps using the Access Manager console.
Note: Importing existing NIS maps simply provides a mechanism for migrating information to the Active Directory. Once the information is
stored in Active Directory, any original NIS maps you imported are no longer used. Instead, the Delinea Network Information Service uses the
information stored in Active Directory to automatically generate the maps it needs to service authentication and lookup requests. This local
cache of data is updated at a regular interval.
Selecting a Zone to Use for NIS Authentication
A computer’s zone is equivalent to a NIS domain for the Delinea Network Information Service. Each instance of the Delinea Network Information Service
supports one and only one zone. All instances of the Delinea Network Information Service in the same zone respond to queries using the same information
from Active Directory.
If user information from a zone needs to be available to NIS clients for agentless authentication, the Delinea Network Information Service must be able to
access the password hash for zone users. However, because Active Directory does not generate a password hash for users by default, there’s no default
attribute for storing this information.
To enable the password hash to be stored for users in a zone:
3. Select the zone that will service NIS client requests, right-click, then click Properties.
For example, if you want to work with a child zone, sanfrancisco, expand the parent zone and Child Zones nodes, select the sanfrancisco zone right-click, then
click Properties.
4. On the General tab, select the Support agentless client option.
5. Select the Active Directory attribute to use for storing the password hash.
Depending on the password synchronization service you are using and the Active Directory schema, select one of these attributes:
altSecurityIdentities if you are using the Delinea Password Synchronization program. Do not select this option if you are using a Microsoft
password synchronization service.
msSFU30Password if you are using the Microsoft Windows Services for UNIX Password Synchronization Service. If you are using the Delinea
Password Synchronization program, you can choose this attribute if you have the SFU schema installed.
unixUserPassword if you are using the Microsoft UNIX Identity Management Service and are using the Delinea Password Synchronization
program.
6. Verify the default NIS domain name.
By default, the zone name is used as the NIS domain name because this makes it easy to identify the scope of the information available to NIS clients.
You can type a different name in the zone properties if you choose. Whether you use the default name or another name for the NIS domain, you must use
the same name when you configure the NIS clients. For more information about configuring NIS clients, see Configuring NIS clients.
7. Click O K to save the changes and close the zone Properties.
Selecting a Computer for NIS Authentication
You can designate any computer in a zone to act as the NIS server for the zone by setting the Allow this computer to authenticate NIS users computer
property as described in “Adding Support for Agentless Clients” in the Administrator’s Guide for Linux and UNIX. For example, expand the Computers node in
the zone that will service NIS client requests, select the computer account, right-click to select Properties, then click the Delinea Profile tab to set this
option.
The computer account acting as a NIS server for the zone must be able to access the attribute containing the password hash for agentless authentication to
be successful.
Selecting Allow this computer to authenticate NIS users adds the computer account to thezone_nis_servers Active Directory group. Computer accounts
that are placed in the zone_nis_servers group are automatically granted permission to read the attribute that stores the password hash for users in the zone.
This property setting enables the computer account to access the password hash so that it can authenticate users in response to NIS client requests.
However, you must manually install and start the Delinea Network Information Service on the physical computer before the computer can act as a NIS server.
Configuring a Password Synchronization Service
The Delinea Network Information Service must be able to retrieve the current password hash for zone users in order for it to respond to agentless
authentication requests from NIS clients. Active Directory, however, does not generate a password hash for users by default. This task is handled by the
password synchronization service.Therefore, to generate the password hash for zone users, you first need to install a password synchronization service.
You can install the password synchronization service with the Server Suite or separately using a standalone setup program. Once deployed, it ensures the
passwords served by the Delinea Network Information Service are always up-to-date. With a password synchronization service, any time users change their
Active Directory password, the corresponding password hash in their user profile is updated to reflect the change. Depending on your environment, you can
choose to install one of the following:
Delinea Password Synchronization program

Microsoft Windows Services for UNIX Password Synchronization Service
Microsoft Windows UNIX Identity Management Service
Note: Regardless of the password synchronization service you choose to use, the service must be installed on all domain controllers in the Active
Directory domain where you are enabling agentless authentication.
Using Delinea Password Synchronization
You can install the Delinea Password Synchronization program using the Server Suite setup program. Alternatively, you can install Delinea Password
Synchronization independent of the the Server Suite using it own setup program. If you install the Delinea Password Synchronization program using the setup
program, you can skip this section.
To install the Delinea Password Synchronization program:
1. Copy the CentrifyDC_PasswordSync-n.n.n-win64 package to your Active Directory domain controller.
2. Open the CentrifyDC_PasswordSync-n.n.n-win64 executable or Microsoft software installation (.msi) file to start the setup program.
Note: You can run the setup program interactively or silently if you use the Microsoft software installation (.msi) file. If you are installing
silently using the msiexec program, you can skip the steps in this section.
4. Review the terms of the license agreement. If you accept the license agreement, select I accept the terms of the license agreement, then click
Next.
5. Type your name and company, select who should be able to use this application on the computer, then click Next.
6. Select a restart option, then click Finish.
Once installed, the Delinea Password Synchronization program will generate the initial password hash when users next change their password, then update
the password hash at each password change thereafter. The password hashes are created using DES encryption with a two character salt. If the password
hash is stored in the altSecurityIdentities attribute, it has a prefix of cdcPasswordHash, for example:
cdcPasswordHash:VkievQ69VhYKc
If the password hash is stored in one of the other supported attributes, it is stored without a prefix.
When a user changes his Active Directory password, the Delinea Password Synchronization program discovers the zones to which that user has access and
updates the appropriate attribute that holds the password hash for that user in each zone.
Note: The initial password hash is only generated when the user changes his password. You may want to force users to change their password at
the next logon to get the password set at the earliest opportunity. Client authentication requests may fail for users who do not have a password
hash available. If the password hash field in the passwd.byname or passwd.byuid map displays a single exclamation point (!), it indicates that the user’s
password hash has not been set.
Using Microsoft Password Synchronization Service
If you choose to use one of the password synchronization services provided by Microsoft instead of the Delinea Password Synchronization program, follow
the instructions provided with the software to install the service. In general, you need to do the following to use the Microsoft password synchronization
services:
Set the Windows domain to the domain you joined after installing the Delinea Agent for *NIX.
Set the NIS domain name to the zone name you specified when you joined the domain. For example, if you are using the default zone, set the NIS
domain to default. Although you can set the NIS domain name to something other than the zone name when creating or modifying a zone’s properties,
you must use the zone name for this setting if you use Microsoft password synchronization.
Set the NIS Server name to the host name of the computer running both the adclient and adnisd services.
Give user accounts access to the zone and NIS domain. If you are using the Microsoft Windows Services for UNIX, select the zone name from the list of
NIS domains on the UNIX Attributes tab.
The rest of the fields on the UNIX Attributes tab are not used by Server Suite, but you are required to enter information for these fields to enable the NIS
domain for the user. Therefore, you should specify a UID, Login shell, Home directory, and Primary group for the user account, then click O K.
Locating Zones for Password Synchronization
Only Active Directory users with a UNIX profile created using the Access Manager console include the attribute (parentLink) needed to look up their zone
information for password synchronization. You can use the Orphan Unix data objects option in the Analyze Wizard to check the forest for accounts
missing this attribute setting and attempt to correct the problem.
If the Analysis Results display a Warning for the Orphan Unix data objects check, you can right-click, then select Properties to view additional details.
If the profile is missing the parentLink attribute, select the warning, right-click, then select Populate parentLink attribute to define this attribute for the
user.
For more information about troubleshooting issues for the Delinea Network Information Service, see Troubleshooting and Logging NIS Operations. For more
information about using the Analyze wizard in the Access Manager console, see “Analyzing information in Active Directory” in the Administrator’s Guide for
Linux and UNIX.
Configuring the Centrify NIS server
This section describes how to install and configure the Centrify Network Information Service (adnisd). Theadnisd process allows a Centrify-managed
computer to act as the NIS server for NIS clients in a joined domain. Using adclient and adnisd together, you can store authentication, authorization and network
information in Active Directory, and respond to NIS client requests from computers and devices even where adclient cannot be installed.
Installing the Centrify NIS Server
Whether you want to use the Centrify Network Information Service for agentless authentication, managing network information, or publishing custom maps,
you must install and configure adnisd on at least one computer in at least one zone before you can begin responding to NIS client requests.
In most cases, adnisd is installed as part of a custom installation of the Server Suite or as a separate software package, independent of the installation of
adclient. The naming convention for the standalone software package is:
centrifydc-nis-n.n.n-os-architecture
Keep in mind:
You must install adnisd on a computer whereadclient is also installed.

The Active Directory domain and zone the local computer has joined defines the NIS domain, and therefore the information available to NIS clients.
You cannot use adnisd to serve NIS maps if your managed computer joined the domain using the --workstation option.
Using the --workstation option adds a computer to the single Auto Zone where user and group profiles are generated automatically. Computers in the Auto
Zone cannot be used as NIS servers or NIS clients.
You can install adnisd using any installation program appropriate for the local operating environment, such as RPM, SMIT or YAST.
If you are upgrading from a previous release of Server Suite and have an earlier version of adnisd, stop the existing adnisd service and use install.sh to
remove the old packages before installing the new version of adclient and adnisd.
The following steps are only an example of how to installadnisd locally on a computer. The specific steps required depend on the local operating environment
and the installation program you choose.
1. As root on the managed computer, use adinfo to verify that adclient is installed, and that the local computer is joined to a domain and can connect to
Active Directory:
su -
Password:
adinfo

Zone: ajax.org/Program Data/Centrify/Zones/default
2. Copy the package appropriate to the local computer’s operating environment, from the Server Suite CD or a download directory, to a local directory.
For example, if the operating environment is Solaris 9 SPARC:
cp /tmp/centrifydc-nis-n.n.n-sol8-sparc-local.tgz .
3. If the package is a compressed file, unzip and extract its contents. For example, on Solaris:
gunzip -d centrifydc-nis-n.n.n-sol8-local.tgz
tar -xf centrifydc-nis-n.n.n-sol8-sparc-local.tar
4. Run the appropriate command for installing the package. For example, on Solaris:
pkgadd –d CentrifyDC-nis -a admin
Adding IP Addresses from Which to Accept Requests
By default, the Network Information Service accepts only local NIS client requests. To accept requests from any other NIS clients in a network, modify
nisd.securenets in the /etc/centrifydc/centrifydc.conf file to specify the computer subnets from which to accept NIS requests. This parameter configures adnisd to filter
NIS client requests by IP address. It ignores all other NIS client requests.
For example, to restrict NIS requests to the single trusted subnet 172.68.0.0, add a line similar to the following to nisd.securenets:
nisd.securenets: 172.68.0.0/255.255.0.0
To specify multiple subnets, separate the entries with commas or spaces:
nisd.securenets: 172.68.0.0/255.255.0.0,196.48.0.0/0
To accept NIS client requests from any computer, use this:
nisd.securenets: 0/0
On systems with multiple Ethernet interfaces, adnisd configures RPC to the first interface. If an NIS client is trying to communicate on a different interface,
adnisd will not receive the request.
Before creating sockets, adnisd reads the centrifydc.conf file to see if an IP address and TCP and UPD ports are specified. If not, it uses localhost and random port
numbers assigned by the operating system.
You set the IP address, TCP port and UDP port using the nisd.net_addr, nisd.port.tcp, and nisd.port.udp configuration parameters, respectively in the centrifydc.conf file.
For more information, see the Configuration and Tuning Reference Guide.
Starting the adnisd Process
After you have specified the subnets from which to accept NIS client requests, you can either manually start theadnisd process at the command line, or reboot
the local computer. By default, theadnisd process starts automatically whenever the computer is rebooted. If you don’t want the process started
automatically, you should modify the startup script on the local computer to removeadnisd from the processes started.
Note:: The installer adds theadnisd process to a computer’s startup script for you. If you are not importing NIS maps right away, you may want to
modify the startup script to prevent theadnisd process from starting before you are ready to begin servicing client requests.
To start theadnisd process at the command line:
1. Verify that adclient is running and the local computer is joined to a domain.
2. Verify that RPC is running on the local computer. For example:
rpcinfo -p localhost
Theadnisd process requires RPC services. If you restart RPC, you also need to restart theadnisd process.
3. Type the appropriate start command. For example, on Red Hat Linux, type:
/sbin/service adnisd start
On most other platforms, run:
/etc/init.d/adnisd start
On Solaris 10 or later, the daemon is controlled through the Solaris Service Management Facility. For example:
svcadm enable nis/centrifydc-server
When theadnisd process starts, it connects to Active Directory through adclient and does the following:
Retrieves the current user, group, network and custom information stored in Active Directory for its zone.
Generates additional maps derived from the retrieved information, such as netgroup.byuser, netgroup.byhost, passwd.byuid, passwd.byname, group.byname, and
group.bygid.
Stores the information retrieved or derived from Active Directory in a local cache of NIS map data.
After the initial connection,adnisd periodically connects to Active Directory through adclient to retrieve updated information for its zone. However,adnisd always
responds to NIS client requests using the data in its local cache so that it can respond to NIS requests even if Active Directory is unavailable.
Customizing the Update Interval for NIS Maps
By default, every 30 minutes (1800 seconds),adnisd uses adclient to connect to Active Directory. At the update interval,adnisd does the following:
Checks for network NIS maps explicitly defined in Active Directory to determine whether any records have changed.
Generates derived maps for any explicitly defined network maps thatadnisd recognizes. For example, if the netgroup map is found in Active
Directory,adnisd generates thenetgroup.byuser and netgroup.byhost maps.
Updates the local cache with all changes to the network NIS maps.
Updates the local cache with changes to the derived maps for user and group information in the zone.
Note: In most cases, updating the local cache of NIS data does not require you to restart any services.
In most organizations, the default update interval is adequate. In a more volatile or stable NIS map environment, reduce or increase the time between
updates, as appropriate, by modifying the nisd.update.interval parameter in /etc/centrifydc/centrifydc.conf to specify a different number of seconds between updates;
for example:
nisd.update.interval: 900
Customizing the NIS Maps to PUblish
By default, theadnisd process retrieves all NIS maps stored in Active Directory at each update interval, updates its local cache as needed, and makes all such
data available to its NIS clients. In some cases, you may want to prevent NIS clients from accessing data in specific maps or from looking up information using
a specific key.
If you want to customize the list of maps to make available to NIS clients, modify the nisd.maps or nisd.exclude.maps parameter in /etc/centrifydc/centrifydc.conf, or
apply a group policy.
With the nisd.maps parameter, you explicitly list the NIS maps, including derived maps, to include in the local cache of map data; for example:
nisd.maps: hosts.byname,hosts.byaddr,automount
With the nisd.exclude.maps parameter, you list the NIS maps to exclude from responses to NIS client requests (typically user and group information). When
you specify a map, its derived maps are excluded as well. For example:
nisd.exclude.maps: group passwd
Configuring the Maximum Number of Map Sets
Whenadnisd receives data for explicitly-defined NIS maps, the data comes from the domain controller selected by the adclient process. If the domain controller
the adclient process has changed – for example, if it is unavailable – the adclient process attempts to find another available domain controller.
To ensure the data consistency of the NIS maps retrieved from Active Directory,adnisd keeps a separate set of NIS records from each domain controller. This
enablesadnisd to switch between domain controllers efficiently, but uses more space in the local cache.
You can control the maximum number of alternate sets of NIS maps to maintain (default is two) by modifying the nisd.maps.max parameter in
/etc/centrifydc/centrifydc.conf. For example, to keep up to four sets of NIS maps, specify:
nisd.maps.max: 4
Handling Large Active Directory Groups
In most cases, the NIS server cannot send more than 1024 characters of data to NIS clients in response to a query. This limitation can create problems when
the NIS client requests information for a large group with a long membership list. By default, theadnisd process automatically truncates the list at 1024
characters.
You can configureadnisd to split large groups into several groups of conforming size and names using nisd.largegroup.suffix and nisd.largegroup.name.length in
/etc/centrifydc/centrifydc.conf.
Splitting a single large group into multiple new groups
If you specify any value for the nisd.largegroup.suffix parameter,adnisd splits large groups into multiple new groups automatically, creating a new group whenever a
group’s data size exceeds 1024-character limit by appending the string you define in nisd.largegroup.suffix plus a sequential number.
For example, if you have a large group named performix-worldwide-corp, and have defined the suffix string as “-all”, when the performix-worldwide-corp group
membership is split into multiple groups, the groups are named as follows:
...
performix-worldwide-corp-all n
All of the new groups have the same group identifier (GID) as the original group.
Setting the maximum length of new group names
If the new group names would exceed the maximum length for group names on a platform, use the nisd.largegroup.name.length parameter. If you do this,adnisd`
truncates the original group name so as not to exceed the maximum name length.
For the example above, if you set a maximum name length of 14, the split groups are named:
performix-all1
...
performi-all10
...
perform-all100
All of the new groups have the same group identifier (GID) as the original group.
Making the NIS Server Available
After you install and configureadnisd on a computer, you must configure other computers or devices on the network to use the computer runningadnisd for NIS
client requests.
In general, configuring NIS clients to use the Centrify Network Information Service involves:
Stopping any existing legacy NIS server processes.

Modifying the NIS client’s configuration file to identify the zone and computer name of the computer where theadnisd process is installed.
Sending a bind request from the NIS client to the new Centrify NIS server.
For more information, see Configuring NIS clients.
Configuring NIS Clients
This section describes how to configure NIS clients to receive authentication, authorization, and network information through the Delinea Network
Information Service.
Specifying the Server for NIS Clients to Use
After you install and configureadnisd on a computer, you must configure other computers or devices to send their NIS lookup requests to the computer running
adnisd. The specific steps for configuring the NIS client are slightly different in different operating environments. In general, configuring NIS clients involves:
Stopping the connection to any existing NIS server.

Identifying the zone and computer name of the computer whereadnisd is installed in the client’s NIS configuration file.
Binding to the new Delinea NIS server.
Restarting services that use NIS, or rebooting the computer.
For information about configuring the NIS client in different operating environments, see the appropriate section below.
Note: The client configuration instructions assume that you are using the zone name as the NIS domain name. If not, substitute the NIS domain
name you specified when you created the zone where applicable. For more information about configuring NIS clients on any specific platform and
OS version, consult the documentation for that platform.
Configuring NIS Clients on Linux
To configure the NIS client on a Linux computer:
1. Stop any running NIS service and remove all files from the /var/yp/binding directory. For example, run the following commands:
/sbin/service ypbind stop

rm -rf /var/yp/binding/*
2. Set the NIS domain name for the client to the zone name or NIS domain name of the computer where theadnisd process is running.
domainname zone_name
For example, if you have installedadnisd on a computer in the corpHQ zone:
domainname corpHQ
3. Edit the NIS configuration file, /etc/yp.conf, to specify the Delinea zone and the name of the computer whereadnisd is installed.
domain zonename server hostname
For example, add a line similar to this to /etc/yp.conf:
domain corpHQ server localhost
If your NIS clients are configured for broadcast discovery, this step may not be necessary.
4. Start the ypbind service.
On Red Hat Linux, run:
/sbin/service ypbind start
On Debian 3.1, run the nis script (controlled using the file /etc/default/nis). By default, the script starts the NIS client, ypbind. For example, run the
following command:
/etc/init.d/nis start
One SuSE Linux 9.3 Professional, run:
/etc/init.d/ypbind start
5. Modify the passwd, group, and shadow lines in /etc/nsswitch.conf file to use compat as the source:
passwd: compat
group: compat
shadow: compat
6. Restart services that rely on the NIS domain, or reboot the computer to restart all services. The most common services to restart are autofs, NSCD, cron
and sendmail.
Configuring NIS Clients on Solaris
To configure the NIS client on a Solaris computer:
1. Stop any running NIS service and remove all files from the /var/yp/binding directory. For example, run the following commands on Solaris 8 or 9:
kill ypbind
On Solaris 10, stop the service by running:
svcadm disable network/nis/client
2. Set the NIS domain name for the client to the zone name of the computer whereadnisd is running.
For example, if you have installedadnisd on a computer in the corpHQ zone:
domainname corpHQ
3. Run the ypinit -c command and enter the name of the computer whereadnisd is installed.
This step is not required if you use the broadcast option to locate the server when you run the ypbind command. You must use ypinit, however, if your network
topology would prevent a broadcast from reaching the desired servers. For example, if the router does not transmit broadcasts across subnets, use the ypinit -c
command to specify a server on a different subnet.
Start the ypbind service. On most versions of Solaris, run:
/usr/lib/netsvc/yp/ypbind
If you are using the broadcast option to locate the server, start the service with that option. For example:
/usr/lib/netsvc/yp/ypbind -broadcast
On Solaris 10, run:
svcadm enable network/nis/client
Modify the passwd, group, and shadow lines in /etc/nsswitch.conf file to use compat as the source:
passwd: compat
group: compat
shadow: compat
Restart services that rely on the NIS domain or reboot the computer to restart all services. The most common services to restart are autofs, NSCD, cron and
sendmail.
Configuring NIS Clients on HP-UX
To configure the NIS client on an HP-UX computer:
1. Stop any running NIS service and remove all files in the /var/yp/binding directory. For example, run the following commands:
/sbin/init.d/nis.client stop
2. Edit the NIS configuration file, /etc/rc.config.d/namesvrs, to set the NIS_CLIENT to 1 and the NIS_DOMAIN to the name of the Delinea zone. For example:
NIS_CLIENT=1
NIS_DOMAIN="zone-name"
3. Add the -ypset option to the YPBIND_OPTIONS variable and set the YPSET_ADDR variable to the IP address of the computer whereadnisd is installed. For
example:
YPBIND_OPTIONS="-ypset"
YPSET_ADDR="15.13.115.168"
This step is not required if you want to use the broadcast option to locate the server when you run the ypbind command.
4. Set the NIS domain name for the client to the zone name of the computer where theadnisd process is running.
5. Start the ypbind service. On HP-UX, you can start the service by running:
/sbin/init.d/nis.client start
6. Modify the passwd, group, and shadow lines in /etc/nsswitch.conf file to use compat as the source:
passwd: compat
group: compat
shadow: compat
7. Restart services that rely on the NIS domain or reboot the computer to restart all services. The most common services to restart are autofs, pwgrd, cron and
sendmail.
Configuring NIS Clients on AIX
To configure the NIS client on an AIX computer:
1. Stop any running NIS service and remove all files from the /var/yp/binding directory. For example, run:
stopsrc –s ypbind
If the computer is not already a NIS client, you can use the System Management Interface Tool (smit) and the mkclient command to add adnisd to the
computer.
2. Open the /etc/rc.nfs file and verify that the startsrc command is configured to start the ypbind daemon:
if [ -x /usr/etc/ypbind ]; then
startsrc -s ypbind
fi
3. Set the client’s NIS domain name to the zone name of the computer whereadnisd is running. For example:
4. Start the ypbind service:
startsrc -s ypbind
5. Restart services that rely on the NIS domain or reboot the computer to restart all services. The most common services to restart are autofs,NSCD, cron and
sendmail.
Note: Theadnisd service is not supported in a workload partitioning (WPAR) environment (Ref: CS-30588c).
Verifying the Client Configuration
Run the domainname command to verify that the client is configured to use the appropriate Delinea zone or NIS domain name. For example, if you have
configured a computer to service NIS requests for the sanfrancisco zone and are using the zone name as the NIS domain name:
domainname
sanfrancisco
To test that the client can connect to the Delinea Network Information Service, run one or more NIS client request commands; for example:
ypwhich
ypwhich -m
ypcat -k mapname
Checking the Derived passwd and Group Maps
On a computer you have configured as an NIS client, verify that the NIS maps required for agentless authentication are available by running the following
command:
ypwhich -m
At a minimum, you should see the passwd.* and group.* map names, followed by the name of the computer you are using as the NIS server. For example, if the
computer running adclient andadnisd is iceberg-hpux, you should see output similar to this:
passwd.byuid iceberg-hpux
passwd.byname iceberg-hpux
group.byname iceberg-hpux
group.bygid iceberg-hpux
These passwd.* and group.* maps are automatically generated based on the information stored in Active Directory for the zone, including all Active Directory
users and groups granted access to the zone. You can view information from any of these maps using a command like ypcat passwd.byname. The output
displayed should look similar this:
paul:Xq2UvSkNngA:10000:10000:paul:/home/paul:/bin/bash
mlopez:!:10002:10000:Marco Lopez:/home/mlopez:/bin/bash
jsmith:!:10001:10000:John Smith:/home/jsmith:/bin/bash
In this example, the user paul has a password hash, but users mlopez and jsmith do not.
If a user account is new, disabled, locked, requires a password change, or is not enabled for a zone, the Delinea NIS server sets the user’s hash field to “!”
Note: On some platforms, you may see ABCD!efgh12345$67890 as the password hash for users who need to set their password.
Importing and Managing NIS Maps
This section describes how to import, create and manage NIS maps and map entries using the Access Manager console.
Note: You can also use ADSI Edit, ADEdit, custom scripts or other tools to add, modify and remove NIS maps and map entries. To import NIS maps,
however, you must use the Access Manager console.
Importing and Creating User and Group Profiles
If you want to make user and group information available to NIS clients, whether for agentless authentication or in response to other lookup requests, you
must first make sure the appropriate users and groups have zone profiles and role assignments defined in the zone. The zone information is used for
automatic generation of the maps passwd.byname, passwd.byuid, group.byname, and group.bygid. If you disable a user profile in the zone, the user’s information cannot
be retrieved or published in response to NIS client requests, or used to authenticate the user’s identity.
You can import existing user and group information directly from existing NIS servers and domains or from properly formatted text files, such as local
/etc/passwd and /etc/group files, using the Import from UNIX wizard, or you can create new profiles for Active Directory users using the Access Manager
console.
Once the appropriate user and group profiles have been added to the zone you are using as a NIS domain, the information is available to NIS clients unless you
explicitly restrict the publication of this information.
Note: For information about restricting the maps published, see Customizing the NIS maps to publish. For information about importing or creating
user and group profiles in a zone, see the Administrator’s Guide for Linux and UNIX.
Publishing Network or Custom Information
In addition to user and group information, adnisd can publish network information or make custom information available to NIS clients. For example, you can
import information from standard NIS maps such as automount, netgroup, and automaster, if these maps exist in your environment. Importing network
information or creating custom maps, however, requires you to have the NIS Extensions.
Note: NIS Extensions are installed by default when you run the setup program. If you did not select this option, rerun the setup program and select
NIS Extensions from the list of Access Manager Administration components.
If you have the NIS Extensions installed, you should see the NIS Maps node under each zone. For example, if you are using hierarchical zones, you can see NIS
Maps under the UNIX Data node for the parent or child zone you select:
Importing Network NIS Maps
To use Access Manager to import a standard network NIS map into Active Directory:
2. In the console tree, navigate to the specific zone into which you want to import NIS maps.
3. Expand the console tree to display NIS Maps.
4. Select NIS Maps, right-click, then click Import Maps.
5. Select whether you want to connect to the NIS server and domain or import the information from a text file, then click Next.
If you are importing maps directly from an existing NIS server, type the name of the NIS domain and NIS server. Using this option requires
network connectivity to the NIS server from the Window computer you are using.
If you are importing a map from a text file, click Browse to navigate to the map file you want to import. If you cannot connect directly to the NIS
server, you should export the NIS database to a file; then import the information using this option.
6. Select the NIS maps to import if you are importing directly from an existing NIS server, or type a map name and define the file format if importing from a
file, then click Next. The Import Maps wizard does not validate the information to be imported. If the map has invalid entries, they are imported as-is.
If you importing from a text file:
Type a Map name that describes the type of map being imported. In most cases, you should use the base name that identifies the configuration
file used to generate the NIS database. For example, use hosts to identify the map generated from the /etc/hosts file.
Type the Field separator character used to separate fields in the map file.
Type the column number that defines the start of the Key field.
Specify any additional options as appropriate for the file you are importing. For example, select Comments are included in the file after and
type the character used to designate comments if the file includes comments.
For Access Manager to correctly interpret the map file, you need to provide accurate information about the file format, such as the type of
separator used between fields.
Because the Centrify NIS server does not include comments in response to service requests, you must save the map to a text file and import from
that file to retrieve comments contained in NIS maps.
7. When the import is complete, click Finish.
8. After importing NIS maps, restart the adnisd service.
Creating New NIS Maps in Active Directory
If you cannot import network information from existing NIS maps, you can create new maps by adding the appropriate information directly to Active Directory
using Access Manager. Once you add the information to Active Directory, adnisd can use the information to automatically generate a local cache of the map
data and make the information in those generated maps available to NIS clients.
Note: If you are creating NIS maps manually, keep in mind that the Network Information Service can return a maximum of 1024 characters of data
in response to a query from any NIS map, so make sure all NIS map entries have less than 1024 characters of data.
To create a new network NIS map in Active Directory
2. Navigate to the specific zone for which you want to create maps.
3. Expand the console tree to display NIS Maps.
4. Select NIS Maps, right-click, then click New and select the type of map you want to create.
For most map types, you can only use the recognized map name for the new map. Recognized map names enable you to use derived maps to retrieve
information using different keys. If you are creating a new Automaster map, you must choose either auto_master or auto.master as the map name to
retrieve the names of the automount maps.
If you select the Generic Map option, you can create a custom NIS map for any key/value pairs that you want to make available to NIS clients. For more
information, see Creating generic custom maps.
5. Select the new empty map, right-click, then click New > Map Entry or New > netgroup to add a new individual map record.
The file format and the specific fields used in individual map records depend on the type of map you are working with.
6. Type the appropriate information for the fields listed, then click O K to save a record in the new map.
For more information about the fields required in any NIS map, see the man page for the type of map you are creating. For example, see the man page for
netgroupto see detailed information about required and optional fields and the format of netgroup maps.
You can use Active Directory groups in netgroup records. Using Active Directory groups in netgrouprecords enables dynamic changes to user and computer
pairings based on their Active Directory group membership. If you have existing processes for adding and removing users and computers in Active
Directory groups, you can leverage those processes in netgroup records.
Creating Maps for Common Network Services
Centrify uses explicitly-defined NIS maps to generate derived maps automatically. Once a recognized base map is imported or created manually in Active
Directory, the agent generates and stores its derived maps so that information can be retrieved searching on different keys.
Note: In most cases, you can import recognized base maps directly from an existing NIS server and domain or from generated text files (for
example, files created using the niscat command). Alternatively, you can create the base maps manually using the corresponding map type in
Access Manager.
The following table describes the recognized base maps and their derived maps.
aliases
The aliases map is the abbreviated name for the mail.aliases map. The derived maps are mail.aliases and mail.byaddr. In most cases, the NIS map is created from the
/etc/aliases or /etc/mail/aliases file. A typical line looks like this:
alias: address1 [address2 addressn...] # comment
For example:
acme: amy.adams@acme.com bill.byrnes@acme.com

widgetco: aaron@widgetco.com,...,zuza@widgetco.com
For the mail.alias map, the entries are defined like this:
Key is the alias name: acme
Value is the list of addresses for the alias: amy.adams@acme.com bill.byrnes@acme.com
For the mail.byaddr map, the entries are defined like this:
Key is an address: amy.adams@acme.com

Value is the corresponding alias: acme
If you create an aliases map in Active Directory, you must include the key as part of the value. For example:
Key: acme
Value: acme: someone@acme.com
Comment: someone@acme.com is the address
audit_user
In most cases, the audit_user map is created from the /etc/security/audit_user file. A typical line looks like this:
user_name:always_audit_flags:never_audit_flags
For example:
root:lo:no
wily:lo,am:io,cl
kris:lo,ex,+fc,-fr,-fa:io,cl
For the audit_user map, entries are defined like this:
Key is the user name: root

Value takes the following format: user_name:always_audit_flags:never_audit_flags
If you create an audit_user map in Active Directory, you must include the key as part of the value. For example:
Key: root
Value: root:lo:no
This map is only applicable for Solaris.
auth_attr
In most cases, the auth_attr map is created from the /etc/security/auth_attr file. A typical line looks like this:
name:res1:res2:short_description:long_description:attr
For example:
solaris.::All Solaris Authorization::help=SolarisAuth.html

solaris.user.manage:::Manage Users::help=ManageUsers.html
If you create an auth_attr map in Active Directory, you must include the key as part of the value. For example:
Key: solaris.
Value: solaris.:::AllSolarisAuthorizations::attribute
Comment: This map provides authorization attributes for Solaris.
bootparams
In most cases, the bootparams map is created from the /etc/bootparams file. A typical line looks like this:
client_name key=value:[key=value:...]
For example:
client root=sr04:/export/client/root domain=nyc.test

engr1 root=smoketest:/export/engr1/root rootopts=:vers=2
If you create a bootparams map in Active Directory, the value must consist of key and value pairs. For example:
Key: client
Value: root=sr04:/export/client/root domain=nyc.test
Comment: The value consists of key=value pairs separated by colons (:).
ethers
The ethers map is the abbreviated name for the ethers.by name map. The derived maps are ethers.byname and ethers.byaddr. In most cases, the NIS map is created
from the file /etc/ethers file. A typical line looks like this:
ethernet_address host_name
For example:
52:ef:75:72:4e:c8 rhel9
31:ee:c5:72:4e:18 finance
For the ethers.byname map, entries are defined like this:
Key is the host name: rhel9

Value is the ethernet address for the host name: 52:ef:75:72:4e:c8
For the ethers.byaddr map, entries are defined like this:
Key is an address: 52:ef:75:72:4e:c8
Value is the host name: rhel9
If you create an ethers map in Active Directory, you must include the key as part of the value. For example:
Key: rhel9
Value: 52:ef:75:72:4e:c8 rhel9
Comment: The host name for 52:ef:75:72:4e:c8 is rhel9
exec_attr
In most cases, the exec_attr map is created from the /etc/security/exec_attr file. A typical line looks like this:
name:policy:type:res1:res2:id:attr
For example:
Application Server Management:susuer:cmd:::/usr/bin/admin:

DBA:unix-dba:cmd:::/usr/db/bin/dbadmin:
dbuser:unix-dbuser:cmd:RO::/usr/sbin/db/opensql
If you create an exec_attr map in Active Directory, you must include the key as part of the value. For example:
Key: Application Server Management

Value: execution profile name and properties followed by attributes defined as key and value pairs for the profile:
Application Server Management:suser:cmd::: \ /usr/appserver/bin/admin:
hosts
The hosts map is the the abbreviated name for the hosts.byname map. The derived maps are hosts.byname and hosts.byaddr. In most cases, the NIS map is created
from the /etc/hosts file. A typical line looks like this:
host_ip_address host_name [alias,...] # comment
For example:
127.0.0.1 localhost.localdomain localhost

192.168.22.1 arcade.cendura.net arcade arc1 # clustername
For the hosts.byname map, entries are defined like this:
Key is the host name: localhost
Value is the IP address and any aliases defined for the host: 127.0.0.1 localhost.localdomain localhost
For the hosts.byaddr map, entries are defined like this:
Key is an address: 127.0.0.1

Value is the IP address and any aliases defined for the host: 127.0.0.1 localhost.localdomain localhost
If you create a hosts map in Active Directory, you must include the key as part of the value. For example:
Key: 127.0.0.1
Value: IP address and any aliases defined for the host: 127.0.0.1 localhost.localdomain localhost
Comment: The value includes both the host name and IP
netgroup
The netgroup map defines a hierarchy of netgroupgroups and members. The netgroupmap controls access by user name, host name, or NIS domain name. The
derived maps are netgnetgroup.byhostroup.byhost and netgroup.byuser. In most cases, the NIS map is created from the /etc/netgroup file. A typical line looks like this:
netgroup_name (host,user,NIS_domain)[,netgroup]...
The keys in a netgroupmap are the names of each netgroup. The values in a netgroupmap are one or more space-separated elements. An element can be:
a set of three comma-separated components.

a netgroupname.
When specifying an element as a set of three components, you can omit any component to allow any value for that component or specify the special
character dash (-) to eliminate a component as a valid value.
The netgroup.byhost map uses the host name as the key and the value is the list of all netgroups that contain the key host somewhere in the hierarchy.
The netgroup.byuser map uses the user name as the key and the value is the list of all netgroups that contain the key user somewhere in the hierarchy.
If you create a netgroupmap in Active Directory, you must not include the key as part of the value. To illustrate, the following example has entries for two
netgroups—onlyhosts and onlyusers—and how the groups become key and value entries in the derived NIS maps.
netmasks
In most cases, the netmasks map is created from the /etc/inet/netmasks or /etc/netmasks file. A typical line looks like this:
IP_addressnetmask # comment
For example
192.168.4.0 255.255.252.0
192.168.4.1 255.255.255.0
If you create a netmasks map in Active Directory, you must not include the key as part of the value. For example:
Key: 192.168.4.0
Value: 255.255.252.0
Comment: This is a 22-bit netmask.
networks
The networks map is the the abbreviated name for the networks.byaddr map. The derived maps are networks.byname and networks.byaddr. In most cases, the
networks map is created from the /etc/networks file. A typical line looks like this:
network_name network_address [alias1,...] # comment
For example:
arpa 10 arpanet
intra_1 123.45.67.89 intranet # headquarters
sf_site 171.22.0.0 sf1 # san francisco satellite
For the networks.byname map, entries are defined like this:
Key is the network name: intranet

Value is the network address and any aliases defined for the network: intranet 171.22.0.0 intra
For the networks.byaddr map, entries are defined like this:
Key is the network address: 171.22.0.0

Value is the network name and any aliases defined for the network: intranet 171.22.0.0 intra
If you create a networks map in Active Directory, you must include the key as part of the value. For example:
Key: intranet
Value: intranet 171.22.0.0 intra
Comment: The value includes the network name and address
printers
In most cases, the printers map is created from the /etc/printers.conf file. A typical line looks like this:
destination_name key=value[,key=value,...] # comment
For example:
buildx:paddr=buildx.acme.com,105004,1,sys,lp,buildxspl,1:
printer3:bsdaddr=server,ps_printer # in copy room
If you create a printers map in Active Directory, you must include the key as part of the value. For example:
Key: printer3
Value: printer name followed by key and value pairs for the printer properties: printer3:bsdaddr=server,ps_printer
Comment: in copy room
prof_attr
In most cases, the prof_attr map is created from the /etc/security/prof_attr file. A typical line looks like this:
profile_name:res1:re2,description:attr
For example:
all:::Execute any command as the user:help=AllRights.html

guest:RO::Allow read-only:audit-flags=all:project=web
If you create a prof_attr map in Active Directory, you must include the key as part of the value. For example:
Key: all
Value: profile name and properties followed by attributes defined as key and value pairs for the profile: all:::Execute any cmd as user or role:help=All.html
project
In most cases, the project map is created from the/etc/project file. A typical line looks like this:
project_name:projectid:comment:user_list:group_list:attr
For example:
DB-backup:14709:Back up DB:dba,root:!*:project.max-tasks=5
web:101:Web services deployment:root:as-team: \\ task.maxlwps=(privileged,101,signal=SIGTERM)
If you create a project map in Active Directory, you must include the key as part of the value. For example:
Key: DB-backup
Value: project name and properties followed by attributes defined as key and value pairs: DB-backup:14709:Back up DB:dba,root:!*: \\ project.maxtasks=5
protocols
The protocols map is the the abbreviated name for the protocols.bynumber map. The derived maps are protocols.byname and protocols.bynumber. In most cases, the
protocols map is created from the /etc/protocols file. A typical line looks like this:
protocol number alias # comment
For example:
ip 0 IP # internet protocol, pseudo protocol number

udp 17 UDP # user datagram protocol
For the protocols.byname map, entries are defined like this:
Key is the protocol name: udp

Value is the protocol name, number, and any aliases defined for the protocol: udp 17 UDP
For the protocols.bynumber map, entries are defined like this:
Key is the protocol number: 17

Value is the protocol name, number, and any aliases defined for the protocol: udp 17 UDP
If you create a protocols map in Active Directory, you must include the key as part of the value. For example:
Key: udp
Value: udp 17 UDP
Comment: user datagram protocol
rpc
The rpc map is the the abbreviated name for the rpc.bynumber map. The derived maps are rpc.byname and rpc.bynumber. In most cases, the rpc map is created from
the /etc/rpc file. A typical line looks like this:
rpc_name port_number alias1 alias2 ... # comment
For example:
portmapper 100000 portmap sunrpc

rpcbind 100001
For the rpc.byname map, entries are defined like this:
Key is the rpc name or alias, so there would be separate entries for: portmapper, portmap, sunrpc, and rpcbind.
Value for each of the portmapper, portmap, and sunrpc key entries would be the same: portmapper 100000 portmap sunrpc
For the protocols.bynumber map, entries are defined like this:
Key is the rpc number: 100000

Value is the rpc name, number, and aliases: portmapper 100000 portmap sunrpc
If you create a rpc map in Active Directory, you must include the key as part of the value. For example:
Key: portmapper
Value: portmapper 100000 portmap sunrpc
Comment: portmap and sunrpc are aliases for portmapper
services
The services map is the the abbreviated name for the services.byname map. The derived maps are services.byname and services.byservicename. In most cases, the
services map is created from the /etc/services file. A typical line looks like this:
service port/protocol alias1 alias2 ... # comment
For example:
uucp 540/tcp uucopy # this entry is for uucp
For the services.byname map, entries are defined like this:
Key is the service name or alias, so there would be separate entries for: uucp and uucopy.
Value for each of the uucp and sunrpc key entries would be the same: uucp 540/tcp uucopy
For the service.byservicename map, entries are defined like this:
Key is the port number and protocol: 540/tcp

Value contains the same set of fields: uucp 540/tcp uucopy
If you create a services map in Active Directory, you must include the key as part of the value. For example:
Key: uucp
Value: uucp 540/tcp uucopy
Comment: uucopy is an alias for uucp
user_attr
In most cases, the user_attr map is created from the /etc/user_attr file. A typical line looks like this:
user:qualifier:res1:res2.attr
For example:
root::::auths=solaris.*,solaris.grant; \\
profiles=Web Console Management,All; \\ lock_after_retries=no; min_label=admin_low; \\ clearance=admin_high
If you create a user_attr map in Active Directory, you must include the key as part of the value. For example:
Key: root
Value: user name and properties followed by attributes defined as key and value pairs for the profile:
all::::auths=solaris.*;profiles=DBA,all;lock_after_retries=no
Creating Generic Custom Maps
You can create generic maps to publish any type of custom information that you want to make available to NIS clients. Generic custom maps consist of a
simple key/value format and optional comments. You can also use generic maps to manually create standar
To add a custom map to Active Directory:

2. In the console tree, select Zones, and open the specific zone you want to work with.
3. In the console tree, select NIS Maps and right-click; then click New and select Generic Map.
4. Type a name for the new map; then click O K.
5. In the details pane, select the new map, right-click; then click New > Map entry.
6. Type the appropriate information for the map record you are adding; then click O K. For example:
Type the Key to use in a client request for looking up the corresponding value.
Type the Value associated with the key.
Type any optional Comments for the key/value pair.
For example:
Changing the Map Type
When you import or create NIS maps, the map type determines the fields defined. For example, a Generic map type consists of three fields: the Key field
(required) the Value field (required), and the Comment field. If you don’t select the correct map type, the Centrify Network Information Service will not be
able to interpret the records in the map correctly or respond to client requests with the proper information.
To change the map type of an existing NIS map:
3. In the console tree, open NIS Maps; then the select the map name you want to change. For example, if you have created a map named nethosts, select
the nethosts map.
4. Right-click; then click Change Type and select the correct map type. For example, if the records in nethosts map should consist of a Key, a Value, and
an optional Comment, select Generic Map as the map type.
If records have already been defined for the map using the incorrect map type, in most cases, you will need to modify the fields after changing the map
type.
Maintaining Map Records in Active Directory
Once NIS maps are stored in Active Directory, you must maintain the records in Active Directory to ensure changes are reflected in the local map cache that
the Centrify Network Information Service uses to respond to NIS client queries. You can use Access Manager to manually add, edit, or delete individual map
records for any map. The specific fields available in each record, and which fields are required and which are optional, depend on the type of map you are
editing. For example, the fields in an auto.master map entry are different from the fields in a netgroupmap entry. For information about the fields in different
types of maps, see Creating new NIS maps in Active Directory.
Modifying Map Records in Active Directory
Specific users and groups can be given the right to add, modify, and delete NIS map entries using the Zone Delegation Wizard. For information about the
rights required, see the Planning and Deployment Guide.
To edit individual map records:
3. In the console tree, open NIS Maps, the select the map you want to modify. For example, select the auto.master map.
4. Select an individual map record and right-click.
5. Click Properties to modify the fields for the selected record or click Delete to remove the record from the map.
If deleting a map record, click Yes to confirm the operation.
Deleting a map stored in Active Directory
Specific users and groups can be given the right to delete NIS maps using the Zone Delegation Wizard. For information about the rights required, see the
Planning and Deployment Guide.
To remove a NIS map from Active Directory:

3. In the console tree, open NIS Maps, the select the map you want to remove.
4. Right-click; then click Delete to remove the map from Active Directory.
Troubleshooting and Logging NIS Operations
This section describes how to use diagnostic tools and log files to retrieve information about adnisd operation and correct problems.
Analyzing Zones for Potential Issues
One way to avoid problems with agentless authentication or incomplete information is to periodically analyze the zone in the Active Directory forest using the
Analyze wizard.
Note: When you run the Analyze wizard, it checks only open zones in the Active Directory forest. Make sure the zone you are using as a NIS
domain is open before analyzing the forest.
To check for potential problems in the Active Directory forest:
2. If so prompted, specify the forest domain or domain controller to which to connect.
3. In the console tree, select the Access Manager root node, right-click, and click Analyze.
5. Select the checks to perform (at least the two in the table below) and click Next.
Select this
To do this
option
Inconsistency in
Check that a zone_nis_servers group exists in each zone that supports agentless authentication, and that the group contains all NIS
granting NIS
servers defined for the zone (to ensure data integrity). This group is required for assigning permissions to Delinea-managed
server
computers that act as NIS servers. Do not delete or modify it manually.
permissions
Check for profile objects whose parent objects have been deleted – for example, manually deleted zone objects whose user,
Orphan UNIX data
group or computer UNIX profile data may be left in Active Directory. This option removes UNIX-specific data from Active
objects
Directory.
6. Review the summary report and click Finish.
7. If the summary report indicates any issues, select Analysis Results in the console tree and view the details listed in the right pane. For example:
To drill down further, or to resolve the issue, select the warning or error, right-click, and select Properties. For example:
Verifying NIS Configuration for Servers and Clients
If you are troubleshooting issues with the Delinea Network Information Service or NIS client look-ups, start by verifying whether the current environment is
configured properly by doing the following:
Check the connectivity between the NIS client and the NIS server with a ping command. If the ping command fails, check the network connection and the
DNS configuration for name resolution problems.
Verify that the nisd.securenets parameter allows responses to NIS clients on other computers. By default, the adnisd process responds only to local NIS
requests.
Verify that the adnisd process is running, for example with the ps command. If adnisd is not running, restart it.
Verify that ypserv is not currently running. If ypserv is running, stop it, modify the system initialization files so ypserv does not start when the computer is
rebooted, and restart adnisd.
Verify that adnisd has registered with RPC by running rpcinfo -p localhost on the adnisd server. You should see two entries in the RPC table for the ypserv
program (100004):
program vers p r o t o port
100004 2 udp 844 ypserv
100004 2 tcp 846 ypserv
If no table is displayed, restart RPC services. If the ypserv process is not listed, restart adnisd.
Verify RPC connectivity from the NIS client:
rpcinfo -p server
You should see the same table and entries as when you listed RPC entries for the adnisd server. For example:
program vers p r o t o port
100004 2 udp 844 ypserv
100004 2 tcp 846 ypserv
If no table is displayed, check the access permissions to the RPC server. For example, on Linux, check /etc/hosts.allow and /etc/hosts.deny files.
Make sure the correct NIS domain name is configured on the NIS client. The NIS domain name is usually the same name as the name of the zone that the
server is joined to. To set the domain name, log on as root run the following command:
Verify that the ypbind process is running on the NIS client using the ps command. If ypbind is not listed as a running process, configure and start it.
Verify that ypbind on the NIS client has found the Delinea NIS server by running ypwhich on the NIS client machine.
If the client is not bound to the correct server name, check the ypbind configuration files and start-up options.
If you are transitioning from an existing NIS infrastructure to the Delinea Network Information Service, the most common reasons for errors are an
incorrect domainname setting or an improper ypbind configuration. For example, if your existing NIS domain names do not match the zone name, some
clients may fail because they use the old NIS domain name instead of the domain name you have set up for the Delinea Network Information Service
domain.
Updating the Startup Sequence
On some platforms, the adnisd package might prevent the ypbind service from starting properly because of the order in which services are started. For example,
if ypbind is configured to start before the adnisd service, the bind will fail. In most cases, this issue does not occur if you are installing new packages because the
installation process checks and corrects the startup sequence to ensure that the bind will be successful. However, to prevent unintended changes to the
existing startup sequence during an upgrade, upgrading the adnisd package will not modify your existing startup configuration. You can manually correct the
startup sequence after an upgrade by running the chkconfig script. For example, run the following command after the adnisd upgrade:
chkconfig adnisd on
Using NIS Command Line Utilities
The Delinea Network Information Service supports common command-line utilities for performing administrative and diagnostic tasks. The following table
lists those you may find useful in the Delinea NIS environment.
Use this
To do this
command
ypwhich Display the name of the NIS server the client is connected to.
ypwhich -m List the maps that are served by the current NIS server.
ypwhich -x Display the nicknames that are defined for NIS maps.
Use this
To do this
command
ypcat -k map Display the contents of the specified map. This command displays both keys and values.
ypmatch key
Look-up the specified key in the specified map.
map
Check the version number of the specified map. This command is only available on Solaris and HP-UX environments. The version number is
yppoll map
displayed as an integer. The adnisd process does not use timestamps.
Configuring Logging for adnisd
By default, the adnisd process logs errors, warnings, and informational messages in the syslog and /var/log/messages files, along with other kernel and program
messages. You might find it useful to log additional details about the operation of the adnisd process for troubleshooting purposes.
To enable logging for the Delinea Network Information Service:
1. As root, set the logging level for the Delinea Network Information Service by modifying the log.adnisd parameter in the centrifydc.conf file.
You might also want to suppress log messages from adclient to make it easier to collect and analyze the messages that are specific to adnisd operation.
For example, set the log.adnisd parameter to DEBUG to log all adnisd operations, and the log parameter for adclient to INFO or WARN to limit messages
generated by the adclient process:
log: WARN log.adnisd: DEBUG
If you only want to collect diagnostic information for netgroup processing, set the log.adnisd.netgroup parameter instead of the log.adnisd parameter. For
example:
log.adnisd.netgroup: DEBUG
2. Set the syslog facility to use for logging adnisd operations using the logger.facility.adnisd configuration parameter. This parameter enables you to log adnisd
messages using a different syslog facility than the facilities used for logging general adclient messages or adclient audit messages.
This parameter value can be any valid syslog facility. For example, set this parameter to log messages to auth (default), authpriv, daemon, security, or local0-7
facilities. For example:
logger.facility.adnisd: auth
For performance and security reasons, only enable DEBUG logging when necessary – for example, when requested to do so by Delinea Support, or while
diagnosing a problem.
Note: Sensitive information may be written to this file. Evaluate the contents before giving others access to it.
The following topics are available in the Smart Card Configuration Guide:
Smart Card for Red Hat Linux

Configuring Smart Card Authentication
Verifying Smart Card Authentication
Using Smart Card at Login
Disabling Smart Card Support
Troubleshooting Smart Card Login
Smart Card for Red Hat Linux
This document explains how to set up smart card authentication for logging on to Red Hat Linux computers.
Why and How to Use a Smart Card to Log On
Smart cards provide an enhanced level of security for Red Hat Linux computers when users log on to Active Directory domains. If you use a smart card to log
on, authentication requires a valid and trusted root certificate or intermediate root certificate that can be validated by a known and trusted certification
authority (CA).
Because smart cards rely on a public-private key infrastructure (PKI) to sign and encrypt certificates and validate that the certificates were issued by a
trusted certification authority and have not expired or been revoked, authentication using a smart card is more secure than a user name and password.
Configuring a smart card for use on a Red Hat Linux computer that is running the Delinea Agent requires that you have already set up a smart card for use in a
Windows domain. You do not need to add any smart card infrastructure to the Linux computer, other than a smart card reader and a provisioned smart card.
In a Windows environment, a smart card may be set up either for a single user account or for multiple user accounts. For example, an individual contributor
might have access to a single Active Directory account that he uses for all his work. In this case, the card is set up for a single user and the card is linked
directly to a UPN. When a user inserts the card to log on, the smart card system looks for the UPN in Active Directory and prompts for a PIN.
Windows 2008 also provides a name-mapping feature that enables configuring a smart card with multiple user accounts. For example, a user might want to
log in with a regular account to check mail or perform routine tasks, but log in with an administrator’s account to perform privileged tasks. To set up a card for
multiple users, an administrator maps a certificate to each user account on the card. When a user inserts the card to log on, the smart card system prompts
the user to select which account to use, and prompts for the card’s PIN.
If you have set up smart card login for Windows clients in a domain, you can use Access Manager to configure smart card login for Red Hat Linux clients joined
to the same domain. If you have provisioned a smart card for use on a Windows computer — either for a single user or multiple users — once you configure
smart card support for a Linux computer, you can use the same smart card to log in to a Red Hat Linux computer.
Note: Configuring smart card support in Access Manager is nearly the same for a single-user or multi-user card with the exception that for multi-
user cards, you must set an extra configuration parameter as explained in Enabling Support for Multi-User Smart Cards.
Setting up a single user smart card login for Windows computers requires either:
Microsoft enterprise root certification authority; see the Microsoft TechNet article: Install an enterprise root certification authority.
A third party certification authority — see the Microsoft KB article: Guidelines for enabling smart card logon with third-party certification authorities.
Setting up a multi-user smart card login for windows requires mapping the certificate on the card to the users who the card is associated with. See the
following Microsoft Technet Blog post: Mapping One Smart Card to Multiple Accounts for more information on how to do this.
Configuring Smart Card Authentication
You configure Red Hat Linux computers for smart card authentication primarily through group policy settings. Enabling support for smart cards requires that
you set a single policy (“Enable smart card support”). Supporting the use of multi-user smart cards requires that you set a configuration parameter on each
Red Hat computer. In addition, Server Suite provides several group policies to control how smart card authentication works after you enable it.
Complete the procedures in the following sections to configure smart card authentication for Red Hat Linux computers:
Enabling smart card support in which you enable smart card authentication for Active Directory users. This is the only procedure you need to complete
to enable smart card authentication. The other procedures allow you to configure different aspects of smart card authentication, such as locking the
screen if the smart card is removed, or preventing users from logging in without a smart card.
Enabling support for multi-user smart cards in which you set the smart card.name.mapping configuration parameter to enable the use of smart cards
provisioned with multiple users on a particular computer.
Enforcing smart card authentication in which you prevent users from logging in with a user name and password on Red Hat Linux computers that have
smart card authentication enabled. You can require all users on a computer to use a smart card for logging in or require specific users to use a smart
card.
Configuring certificate validation in which you specify how to use a Certificate Revocation List (CRL) to check the status of certificates stored on a
revocation server
Locking the screen if a smart card is removed in which you require that the computer’s screen is locked when a smart card is removed.
Enabling a certificate without extended key usage in which you enable a Windows group policy setting to allow using certificates without the EKU
attribute for smart-card log in.
Configuring applications for smart card access in which you configure applications such as Firefox and Thunderbird that require smart card
authentication to gain access to sensitive sites and data.
Before Configuring Smart Card Authentication
To use a smart card to log on to a Red Hat Linux, CentOS, Debian, or Ubuntu computer, verify that the computers meet these requirements:
Are running one of the following operating systems:
Red Hat Linux (32- or 64-bit) version 5.6 or later
CentOS version 5.6 or later
Ubuntu 18.04.x LTS, 20.04.x LTS and 21.04 (amd64)
Debian 9.x and 10.x (amd64)
Rocky Linux (amd64)
AlmaLinux (amd64)
Note: For Debian and Ubuntu systems, be sure to have the opensc-pkcs11, pcscd, and libnss3-tools packages installed.
Are running the GNOME desktop. The agent does not support use of a smart card with the KDE desktop.
If a system is running RedHat Linux or CentOS 8.0 or later, the system needs Delinea Agent for *NIX version 5.7.0 or later.
If a system is running Debian or Ubuntu, the system needs Delinea Agent for *NIX version 5.8.0 or later.
Are joined to the Windows domain.
Have a supported smart card reader attached.
Other prerequisites for enabling smart card support differ depending on whether you have configured a single-user or multi-user smart card.
For a single-user card, before enabling smart card support, make sure you do the following:
Provision a smart card with an NT principal name and PIN. Currently, Access Manager supports Common Access Card (CAC), Personal Identify
Verification (PIV), cards with both CAC and PIV profiles (CACNG), and Alternative Logon Token (ALT) smart cards.
Verify that the Active Directory Zone user’s UPN matches the UPN on the smart card.
For a multi-user card, before enabling smart card support, make sure you have the following in place:
A Windows Server 2008, or later, domain controller for authentication.

The card is not configured with a UPN. If a card with a UPN is inserted, the computer prompts for a PIN rather than prompting for a user name and
password.
An administrator has added the certificate on the card to the name mapping for the users the card is associated to. See the following Microsoft Technet
Blog post: Mapping One Smart Card to Multiple Accounts for more information on how to do this.
For either type of card, verify that the public key infrastructure to support smart card login is operational on the Windows computer running Active Directory
and Access Manager. If the user is able to log in to a Windows computer with a smart card, and you have a card reader and a fully-provisioned card for the
Linux computer, the user should be able to log in to the Linux computer once you configure it for smart card support.
Although the Linux computer has its own infrastructure for enabling and managing smart card authentication, the Delinea Agent for *NIX and smart card
utility (sctool) enable authentication through Active Directory. After you enable smart card support through the Delinea Agent, the Red Hat smart card
configuration options have no effect.
Enabling Smart Card Support
Smart card authentication requires configuration changes to certain Red Hat or CentOS Linux files, depending on the version of Red Hat Linux or CentOS you
are using.
For example, if you are using Red Hat Linux 5.6 or 6.0, the files affected may include the following:
/etc/pam.d/gdm
/etc/pam.d/gnome-screensaver
/etc/pam.d/password-auth
/etc/pam.d/smartcard-auth
Smart card authentication also requires configuration changes to certain system Coolkey symbolic links such as the following:
/usr/lib(64)/libckyapplet.so.1.0.0
/usr/lib(64)/pkcs11/libcoolkeypk11.so
After you enable smart card authentication, the agent makes the required changes and creates backup copies of the affected files.
The smart card components on the Linux computer are configured by default to use the Delinea Coolkey PKCS #11 module for authentication. Although this is
the optimal configuration, if your smart cards are not supported by Coolkey, Delinea allows you to specify a different PKCS #11 module to use for
authentication. Delinea does not supply PKCS #11 modules other than the default Coolkey module. If you need to use a third-party module, you must install it
yourself.
Some PKCS #11 modules may not work seamlessly with the GDM environment. For example, some card events, such as locking the screen upon card removal,
may not work.
To configure a different module, do one of the following:
If you are enabling smart card support with group policy, you can specify an alternate PKCS #11 module when you enable the group policy; see the
procedure: To enable smart card support by using group policy.
If you are manually enabling smart card support by running sctool, you can set a configuration parameter on each Linux computer to specify the module
to use; see the procedure: To manually enable smart card and specify a different PKCS .
Steps
If you are running Red Hat Linux 6.0, you must install some support packages before enabling smart card support; see To install required packages on Red Hat
Linux 6.0.
You can enable smart card authentication by either of the following methods:
Use the “Enable smart card support” group policy, which enables smart card support on all computers to which the Group Policy object applies. Note
that configuration changes do not take place until the next group policy update or when you run adgpupdate on the Linux computers.
Run the sctool -enable utility on each computer that you want to enable for smart card support.
To install required packages on Red Hat Linux 6.0
1. Log on to a Red Hat computer with root privilege and open a terminal window.
2. Run the following command:
[root]#yum groupinstall "Smart card support"
To Enable Smart Card Support Using Group Policy
1. On a Windows computer, open Group Policy Management to create or select a Group Policy object that is linked to a site, domain, or organizational unit
that includes Red Hat Linux computers; right-click the Group Policy object, then select Edit.
2. In the Group Policy Management Editor, expand Computer Configuration > Policies > Delinea Settings > Linux Settings, click Security, then
double-click Enable smart card support.
3. Select Enabled, then click O K to save the policy setting, or go to the next step to change the PKCS #11 module used for authentication.
This group policy modifies Red Hat Enterprise Linux configuration files to look for a smart card user’s credentials in Active Directory and verify the
identity of the user with the smart card certificate.
4. Optionally, to specify a PKCS #11 module other than the Delinea default module, type the complete path to the module in PKCS #11 Module:
Note: Your smart card environment performs optimally when configured to use the default Coolkey module. You should specify a different
module only if your smart cards are not supported by Coolkey. Otherwise, skip this step and click O K to save the group policy setting.
This field supports the use of the $LIB environment variable in the path to allow a single group policy to work for 32-bit and 64-bit systems. At run time on
32-bit systems$LIBresolves tolib, while on 64-bit systems it resolves to lib64.
For example, the following path specifies the OpenSC PKCS #11 module:
/usr/$LIB/pkcs11/opensc-pkcs11.so
5. To apply the group policy immediately to any computer you must restart the computer or run the adgpupdate command on it.
Otherwise, all affected computers will be updated automatically at the next group policy update interval. After computers are restarted or receive the
policy update, they are ready for smart card use.
To Manually Enable Smart Card Support Running sctool
2. Run the sctool utility with the --enable option:
3. Repeat steps 1 and 2 for each computer on which to enable smart card authentication.
To Manually Enable Smart Card and Specify a Different PKCS
1. Open the Delinea configuration file with a text editor, find the rhel.smartcard.pkcs11.module parameter, and set its value to the complete path for your
PKCS #11 module.
Be certain to remove the comment for the parameter.
For example, the following parameter value sets PKCS #11 to the OpenSC module:
[user]$ vi /etc/centrifydc/centrifydc.conf
...
rhel.smartcard.pkcs11.module: /usr/$LIB/pkcs11/opensc-pkcs11.so
This parameter supports the use of the $LIB environment variable in the path to allow a single path specification to work for 32-bit and 64-bit systems.
At run time on 32-bit systems $LIB resolves to lib, while on 64-bit systems it resolves to lib64.
3. Enable, or re-enable smart card support by running the following sctool commands as root:

4. Refresh the GNOME environment by running the following command as root:
[root]$ /usr/sbin/gdm-safe-restart
Next Steps
After you enable smart card support, the computer is ready for smart card authentication. You can attach a smart card reader and log in with a valid card and
matching Active Directory user.
The next step is to configure one or more of the following smart card authentication options if you wish:
Enabling support for multi-user smart card which sets the smartcard.name.mapping configuration parameter to enable the use of smart cards
provisioned with multiple users on a particular computer.
Enforcing smart card authentication which prevents users from logging on with just a user name and password.
Configuring certificate validation which specifies how certificates are validated.
Locking the screen if a smart card is removed which locks the screen when a smart card is removed to provide enhanced security.
If you have no other options to configure, you can go directly to Verifying smart card authentication to confirm that you can log on to one of the Linux
computers that you have configured for smart card authentication.
Enabling Support for Multi-User Smart Cards
If you plan to use multi-user smart cards on a Red Hat Linux computer in your domain, you must set the smartcard.name.mapping parameter to true in the Delinea
configuration file for that computer by completing the following the procedure. If your environment exclusively uses single-user smart cards, you can skip
this section.
Note: Setting the configuration parameter with this procedure has no effect on single-user smart cards. There is no conflict with using single-
user and multi-user on the same computer. However, if a Red Hat Linux computer is accessed through a multi-user card, you must set the
configuration parameter by using this procedure.
To enable support for multi-user smart cards
1. On the Red Hat Linux computer, open the Delinea configuration file in a text editor, /etc/centrifydc/centrifydc.conf, with a text editor.
2. Type the following:
smartcard.name.mapping: true
By default, this parameter is set to false and the configuration file should have a commented line showing this setting. So, alternately, you can find this
parameter in the file, remove the comment, and change the value to true.
Enforcing Smart Card Authentication
By default, enabling smart card support does not force all users to log on using a smart card. If you want to require all Active Directory users to authenticate
by using a smart card, you have the option to configure a computer group policy. If you want to require only specific Active Directory users to authenticate by
using a smart card, you can configure their user account properties to require a smart card for authentication.
You can enable the “Require smart card login” group policy to ensure that all Active Directory users logging on to a computer must insert a smart card for
authentication. If you enable this policy, Active Directory users who forget their smart card will be unable to log on to their computers. However, you add
exceptions to this group policy to allow users who forget their smart card to log on using their user name and password on the computers where the policy
with exceptions is applied.
Note: If you use this approach to enforce smart card login for all users, be certain that all users have their accounts set with the “Password never
expires” option. If a user attempts to log on with a smart card but the password for the account has expired, the smart card login fails with an error
message about changing the password. If you use the account option to require smart card for specific users, you can ignore password expiration.
Enforcing smart card authentication applies to all forms of log on, including GUI login, SSH, telnet, and so on. However, it is enforced for Active Directory users
only. If a computer is configured with one or more local accounts, those accounts are still able to log on even if you set the group policy to require smart card
authentication.
Steps
To require smart card login, complete one of these procedures
To require smart card login for all users on a computer

To require smart card login for a specific user
To require smart card login for all users on a computer
1. On a Windows computer, open Group Policy Management and select the Group Policy object where you enabled smart card support for Red Hat Linux
computers; right-click the Group Policy object, then click Edit.
2. In the Group Policy Management Editor, expand Computer Configuration > Policies > Centrify Settings > Linux Settings, click Security,
then double-click Require smart card login.
3. Select Enabled.
Click A d d if you want to add exceptions to this group policy now, then click Browse to search for and select the Active Directory group allowed to log on
using a user name and password if they forget their smart card. If you only want to configure exceptions when they are needed, click O K to enable the
group policy without exceptions.
4. To apply the group policy immediately to any computer, you must restart the computer or run the adgpupdate command on it.
Otherwise, all affected computers will be updated automatically at the next group policy update interval.
To require smart card login for a specific user
1. On a Windows computer, open the Access Manager console or Active Directory Users and Computers.
2. Select the user.
For example, in the Administrator’s Console, open domainName __> Zones >** zoneName **> UNIX Data > Users.
3. Right-click the user’s name and select AD Properties.
4. In the User Properties window for the user, click the Account tab.
5. In “Account options”, scroll until Smart card is required for interactive logon is visible, then select it.
6. Click O K.
Configuring Certificate Validation
You can use the Certificate validation method group policy to configure how certificates are validated or rejected by using a Certificate Revocation List
(CRL) stored on a revocation server.
To Configure How Certificates are Validated
then double-click Certificate validation method.
3. Select Enabled.
4. Choose one of the following options from Certificate Revocation List:
Off: To disable certificate validation.
If you select this setting, no revocation checking is performed.
Best attempt: To check that certificates are not rejected as invalid, untrusted, or revoked by the certificate revocation list (CRL).
This setting is appropriate for most organizations.
Require if cert indicates: To check whether there is a successful connection to the revocation server.
If a URL to the revocation server is provided in the certificate, this setting requires a successful connection to a revocation server, and checks that
certificates are not rejected as invalid, untrusted, or revoked by the CRL. You should only use this setting in a tightly controlled environment that
guarantees the presence of a CRL server. If a CRL server is not available, certificate validation may prevent furthering processing of an
Require for all certs: To require successful validation of all certificates.
You should only use this setting in a tightly controlled environment that guarantees the presence of a CRL server. If a CRL server is not available,
certificate validation may prevent furthering processing of an authentication request.
5. Click O K to save the policy settings.
6. To apply the group policy immediately to any computer, restart the computer or run the adgpupdate command on it.
Otherwise, all affected computers will be updated automatically at the next group policy update interval.
Locking Screen if Smart Card is Removed
Depending on what you consider best practices for using a smart card, you may want the screen to lock whenever a user removes the smart card. If you want
to lock the screen when a smart card is removed, you can do so by enabling the Removing a smart card locks screen user group policy.
To lock the smart card screen when a smart card is removed
then double-click Lock Smart Card screen for RHEL.
3. Select Enabled, then click O K.
Note: Policies are turned off by default on Linux systems but can be turned on with a group policy setting. To ensure that the “Removing a
smart card locks screen” policy takes effect, verify that the following computer policy is enabled by completing the following two steps.
4. Expand Computer Configuration > Centrify Settings > DirectControl Settings, click Group Policy Settings, then double-click Enable
user group policy.
5. Verify that Enabled is selected, and if not, select it, then click O K.
6. To apply the group policy “Lock Smart Card screen for RHEL” immediately to any computer you must restart the computer or run the adgpupdate command
on it.
policy update, the screen is locked if a smart card is removed.
Enabling a Certificate Without Extended Key Usage
Normally, smart card use requires certificates that contain the extended key usage (EKU) attribute. However, Windows provides a group policy that allows
the use of certificates that do not have the EKU attribute.
Note: This group policy is implemented as an administrative template (.adm file), not as an xml file, as are the Delinea group policies.
To use certificates without the EKU attribute with smart cards:
1. Open the group policy editor and edit the GPO that contains the Linux computers enabled for smart-card login.
2. Open Computer Configuration > Policies > Administrative Templates > Windows Components > Smart Card and double-click Allow
certificates with no extended key usage certificate attribute.
3. Click Enabled and click O K.
When you enable this policy, it sets the smartcard.allow.noeku parameter to true in the Delinea configuration file. Certificates with the following attributes
can also be used to log on with a smart card:

4. In a Terminal window, run the sctool command as root with the -E (--no-eku) parameter to re-enable smart card support. You must use either the -a (--altpkinit)
or -k (--pkinit) parameter with the -E option; for example:
sctool -E -k jsmart@acme.com
Configuring Applications for Smart Card Access
Many applications, including Firefox and Thunderbird, that require smart card access to sensitive sites or data, create their own NSS database for the user.
To give these applications access to the certificates and control revocation lists (CRL) used by the agent for log on, you enable the group policy “Specify
applications to import system NSSDB”, which synchronizes the system NSSDB file on a computer with each application’s NSSDB file.
Each application, such as Firefox, creates a profile file (profile.ini) that specifies the location for its certificates and CRLs. With the “Specify applications to
import system NSSDB” policy, you specify the location of the profile file for an application. A Delinea mapper file parses the profile file to determine the
location of the application’s certificates and CRLs and copies certificates and CRLs to this location.
Steps
If the computers you manage use applications such as Firefox that require smart card access to sensitive sites or data, configure NSS database
synchronization to ensure that these applications have access to current certificates and control revocation lists.
To configure NSS database synchronization
computers; right-click the Group Policy object, then select Edit.
2. In the Group Policy Management Editor, expand User Configuration > Policies > Centrify Settings > Linux Settings, click Security, then
double-click Specify applications to import system NSSDB.
3. Select Enabled, then click A d d.
4. In Application, specify the application directory in which to import the system NSS database.
For each application enter the location of its profiles.ini file. Specify the entry in relation to the home directory of the user by starting the path with ~/.
For example, the following entry specifies the default location of the Firefox profiles.ini file
~/.mozilla/firefox.
5. Click A d d to add as many application directories as necessary, then click O K to save the settings.
Note: User policies are turned off by default on Linux systems but can be turned on with a group policy setting. To ensure that the “Specify
applications to import system NSSDB” policy takes effect, verify that the following computer policy is enabled:
6. Expand Computer Configuration > Centrify Settings > DirectControl Settings, click Group Policy Settings, then double-click Enable
user group policy.
7. Verify that Enabled is selected, and if not, select it, then click O K.
8. To apply the group policy immediately to any computer, restart the computer or run the adgpupdate command on it.
policy update, the screen is locked if a smart card is removed.
Configuring Citrix VDA Smart Card Authentication
You can integrate Delinea Agent for *NIX with the Citrix Virtual Delivery Agent (VDA) for Active Directory user authentication. This integration helps users log
in to remote Red Hat Linux (RHEL) virtual desktop sessions with a smart card connected to the client device.
The Delinea Authentication Service supports pass-through authentication if the Citrix requirements are met. For details, see https://docs.citrix.com/en-
us/linux-virtual-delivery-agent/current-release/system-requirements.html.
Be sure that you have set up smart card authentication already on Windows systems in your domain before continuing.
To configure Citrix VDA smart card authentication:
1. Install the Citrix Linux VDA.
For details, see the Citrix documentation: https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/installation-overview.html.
For example, you might run a command that looks like the following:
sudo yum -y localinstall XenDesktopVDA-19.9.0.3-1.el7_x.x86_64.rpm
2. According to the Citrix VDA documentation, install the necessary software and perform the required system integrations.
NTP isn't required to be configured in an Active Directory environment, but Citrix Linux VDA does require certain software, such as PostgreSQL and
openJDK. For details, see https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/configuration.html.
3. Install Delinea Agent for *NIX version 19.9 or later and join the computer to the domain.
For details, see the Planning and Deployment Guide.
4. To configure the agent integrations with the Citrix Linux VDA, add the following setting to the centrifydc.conf file:
smartcard.login.service.accounts: ctxsrvr
The Citrix smart card login service runs as the ctxsrvr account. This parameter allows you to specify a list of non-root user accounts that use the smart
card login services.
5. Configure the Citrix Linux Virtual Delivery Agent (VDA).
For details, see the Citrix documentation: https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/configuration.html and

https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/installation-overview/redhat.html.
Below is an example of running ctxsetup.sh in interactive mode; be sure to adjust as needed for your environment.
$ sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
Welcome to the Citrix Linux VDA setup script. This script will guide you through the
configuration of the Linux VDA system services. You can re-run this script at
any time to reconfigure the system.
Gathering information...
Checking CTX_XDL_DOTNET_RUNTIME_PATH... Value not set.
Dotnet Core runtime environment is needed to run Linux VDA.
Linux VDA will install it to /opt/dotnet by default.
If required, please specify an absolute path in valid format here (e.g., /the/path). [\<none\>]:
Checking CTX_XDL_SUPPORT_DDC_AS_CNAME... Value not set.
The Virtual Delivery Agent supports specifying a Delivery Controller name using a DNS CNAME record.
Do you want to enable support for DNS CNAME records? (y/n) [n]: y
Checking CTX_XDL_DDC_LIST... Value not set.
The Virtual Delivery Agent requires a space-separated list of Delivery Controller Fully Qualified Domain Names
(FQDNs) to use for registering with a Delivery Controller. Please provide the FQDN of at least one Delivery
Controller: CS.CITRIX.TEST
Checking CTX_XDL_VDA_PORT... Value not set.
The Virtual Delivery Agent by default communicates with Delivery Controllers using TCP/IP port 80.
Please provide the TCP/IP port the Virtual Delivery Agent service (ctxvda) should use to communicate with a
Delivery Controller [80]:
Checking CTX_XDL_REGISTER_SERVICE... Value not set.
The Linux VDA services support starting during boot.
Do you want to register these services to start on boot? (y/n) [y]:
Checking CTX_XDL_ADD_FIREWALL_RULES... Value not set.
The Linux VDA services require incoming network connections to be allowed through
the system firewall. Do you want to automatically open the required ports (by default ports 80, 1494, 2598, 8008 and 6001\~6099) in the
system firewall for the Linux VDA? (y/n) [y]:
Checking CTX_XDL_AD_INTEGRATION... Value not set.
The Virtual Delivery Agent requires Kerberos configuration settings to authenticate with Delivery Controllers. The
Kerberos configuration is determined from the installed and configured Active Directory integration tool on this
system. Please select the Active Directory integration tool configured on this system:
1: Winbind
2: Quest
3: Centrify 4: SSSD
5: PBIS
Select one of the above options (1-5) [1]: 3
Checking CTX_XDL_HDX_3D_PRO... Value not set.
Linux VDA supports HDX 3D Pro, a set of graphics acceleration technologies designed to optimize the
virtualization of rich graphics applications. HDX 3D Pro requires a compatible NVIDIA Grid graphics card to be
installed. If HDX 3D Pro is selected the Virtual Delivery Agent will be configured for VDI desktops (single-session)
mode. Do you want to enable HDX 3D Pro? (y/n) [n]:
Checking CTX_XDL_VDI_MODE... Value not set.
Linux VDA supports delivery of hosted shared desktops (multi-session) or VDI desktops (single-session).
Do you want to enable VDI desktops (single session) mode? (y/n) [n]: y
Checking CTX_XDL_SITE_NAME... Value not set.
The Virtual Delivery Agent discovers LDAP servers using DNS, querying for LDAP service records. To limit the DNS
search results to a local site, a DNS site name may be specified.
If required, please specify a local DNS site name. [\<none\>]:
Checking CTX_XDL_LDAP_LIST... Value not set.
The Virtual Delivery Agent by default queries DNS to discover LDAP servers, however if DNS is unable to provide
LDAP service records, you may provide a space-separated list of LDAP Fully Qualified Domain Names (FQDNs) with
LDAP port (e.g. ad1.mycompany.com:389).
If required, please provide the FQDN:port of at least one LDAP server. [\<none\>]:
Checking CTX_XDL_SEARCH_BASE... Value not set.
The Virtual Delivery Agent by default queries LDAP using a search base set to the root of the Active Directory
Domain (e.g. DC=mycompany,DC=com), however to improve search performance, a search base may be specified
(e.g. OU=VDI,DC=mycompany,DC=com).
If required, please provide an LDAP search base. [\<none\>]:
Checking CTX_XDL_FAS_LIST... Value not set.
The Federated Authentication Service (FAS) servers are configured through AD Group Policy. But because
the Linux VDA does not support AD Group Policy, you can provide a semicolon-separated list of FAS servers instead.
Caution 1: The sequence must be the same as configured in AD Group Policy.
Caution 2: If any server address is removed, you must fill its blank with the '\<none\>' string and keep the index of server addresses without any changes.
If required, please specify the list of FAS servers (e.g., fasserver.company.com). [\<none\>]:
Checking CTX_XDL_START_SERVICE... Value not set.
The Linux VDA services may be started after configuration is complete.
Do you want to start these services once configuration is complete? (y/n) [y]:
Configuring Citrix Linux VDA ...
Configuration complete.
6. In Citrix Virtual Apps or Citrix Virtual Desktops, create the machine catalog and delivery group.
For details, see https://docs.citrix.com/en-us/linux-virtual-delivery-agent/current-release/installation-overview/redhat.html#step-8-create-the-

machine-catalog-in-citrix-virtual-apps-or-citrix-virtual-desktops.
7. (Optional) Enable the group policy entitled "Enable smart card support."
8. Verify that the smart card login is enabled on the Linux computer:
$ sudo sctool -s
Delinea Smart Card support is enabled.
If you have not enabled the group policy enabled "Enable smart card support", you may need to run the following command to enable smart card login:
$ sctool -e
For details about this group policy, see the Smart Card Configuration Guide.
9. Reboot the Linux computer.
10. In Citrix StoreFront, enable smart card authentication.
For details, see https://docs.citrix.com/en-us/storefront/current-release/configure-authentication-and-delegation/configure-authentication-

service.html.
Verifying Smart Card Authentication
After you enable smart card support, you should verify that a user is able to authenticate with a smart card on a Red Hat Linux computer.
To verify smart card authentication:
1. On the Red Hat Linux computer, run the following command to check the status of smart card support:
[root]#sctool --status DirectControl Smart Card support is enabled.
Note: On Red Hat Linux computers, when enabling smart card support, the agent bypasses the native, Red Hat, smart card infrastructure.
Therefore, after you enable smart card with the agent (through the group policy setting or the sctool command), the sctool --status command
will show that smart card is enabled but the Red Hat system (GNOME: System > Administration > Authentication > Authentication) might
show that it is not enabled. You can ignore the GNOME setting because it is for native smart card authentication, not the authentication used
by the agent.
2. Click System > Administration > Smart Card Manager.
3. Insert the smart card in the reader and click View Certificates.
4. Double-click the certificate for a user account that has a profile in the zone the Red Hat Linux computer has joined, for example, JOBS.BILL.20013.
5. Scroll to find the NT Principal name; for example:
NT Principal Name jbill.20013@myDomain.com
6. On a Windows computer, open Activity Directory Users and Computers or the Access Manager console. For example, in the Access Manager console,
navigate to the zone that the Red Hat Linux computer has joined and open UNIX Data > Users, then double-click the user.
The NT Principal name in the certificate should match the login name in the Delinea UNIX profile, or in the Active Directory Account tab.
7. Log out of the Red Hat computer.
8. Re-insert the smart card in the reader and enter the user’s PIN.
Using a Smart Card at Login
When a user inserts a smart card into the card reader attached to a Red Hat Linux computer that is waiting for login, the login dialog is replaced by a smart-
card enabled login (if the card is provisioned for an Active Directory user who is enabled for the Delinea zone to which the computer is joined). However, the
actual log on screen varies depending on whether the card is provisioned for a single user or for multiple users.
How the Login Screen Appears for a Single-User Card
When a user inserts a single-user card, the smart card login shows the name of the user for whom the card is provisioned, and provides a single text box in
which the user can type the PIN associated with the card.
If the user is not enabled for the zone, or is not a valid Active Directory user at all, the smart card login screen is replaced by either a list of local users, or user
name and password text entry fields.
The user will be successfully logged in if the following conditions are met:
The user enters the correct PIN for the smart card.
The card is trusted by the domain and has not been revoked. The card is checked locally first, online or offline, to ensure that the issuing certificate
authority is trusted by the Red Hat Linux computer through the certification authority trust chain, which is set up when the computer joins the domain,
and is periodically refreshed.
Checking is performed by the domain controller when the computer is online, and by a local service, based on cached CRLs, when the computer is offline. If
the user is not connected to the network but has previously logged on — with a smart card or in some other way — the Delinea Agent gets the UPN from the
card and looks up the user in the cached data.
If login fails, no feedback is provided to the user as to why the login is being denied. However, information is logged into various system log files,
/var/log/system.log, /var/log/secure.log, and the Delinea log file (/var/log/centrifydc.log) if logging is enabled, that can help determine the reason for a
denied login.
How Login Screen Appears for a Multi-User Card
When a user inserts a card that is provisioned for multiple users, the smart card login provides a Username box that allows the user to enter the name of the
account to use.
When the system finds the user account in Active Directory, it prompts the user to enter the PIN for the card.
If the user is not enabled for the zone, or is not a valid Active Directory user at all, the smart card login dialog is replaced by the previous login screen, either a
list of local users or username and password text entry fields.
The user will be successfully logged in if the following conditions are met:
The user enters the correct PIN for the smart card.
The card is trusted by the domain and has not been revoked. The card is checked locally first, online or offline, to ensure that the issuing certificate
authority is trusted by the Red Hat Linux computer through the certification authority trust chain, which is set up when the computer joins the domain,
and is periodically refreshed.
Checking is performed by the domain controller when the computer is online, and by a local service, based on cached CRLs, when the computer is offline. If
the user is not connected to the network but has previously logged on — with a smart card or in some other way — the Delinea Agent gets the name from the
log on screen and looks up the user in the cached data.
If login fails, no feedback is provided to the user as to why the login is being denied — as is the case when logging in with a password. Information is logged into
various system log files that can help determine the reason for a denied login, /var/log/system.log, /var/log/secure.log, and the Delinea log file
(/var/log/centrifydc.log) if logging is enabled.
Screen Saver Shows Password Not PIN Prompt
Most smart card users are allowed to log on with a smart card and PIN only — they cannot authenticate with a user name and password. However, it is possible
to configure users for both smart card/PIN and user name/password authentication. Generally, this set up works seamlessly: the user either enters a user
name and password at the log on prompt, or inserts a smart card and enters a PIN at the prompt.
However, for multi-user cards, it can be problematic when the screen locks and the card is in the reader. When a user attempts to unlock the screen, the
system prompts for a password, not for a PIN, although the PIN is required because the card is in the reader. If the user is not aware that the card is still in the
reader and enters his password multiple times, the card will lock once the limit for incorrect entries is reached.
What Happens After Login
In general the user experience is the same in both connected and disconnected modes, with the exception of single sign-on (SSO). Because the agent does
not cache the smart card’s PIN, single sign-on (SSO) is available for smart card authentication only while the computer is connected to the domain.
Of course, certain behaviors and system responses are specific to smart card login:
If the user removes the smart card after logging on, the response of the system depends on whether the group policy “Lock smart card” screen is
enabled in the domain. If it is, the screen locks. Otherwise, the screen does not lock and the user may continue working.
Note: For a smart card that is provisioned for multiple users, if the screen locks, the system prompts for a Password, not for a PIN, when the
user logs back in. However, the user must enter the PIN for the card, not the password, when logging back in.
If the user inserts a smart card while the screen saver is active, the response depends on whether “Lock smart card screen” is enabled in the domain. If it
is, the screen saver deactivates. If the policy is not enabled, the screen saver continues running until the user moves the mouse or touches a key.
If you want to disable smart card support, you must disable the group policies you configured to establish smart card authentication.
To Disable Smart Card Support by Using Group Policy
1. Edit the Group Policy object linked to the site, domain, or OU that includes Red Hat Linux computers.
2. Expand Computer Configuration > Policies > Centrify Settings > Linux Settings, click Security, then double-click Enable smart card
support.
3. Select Disabled and click O K.
When the policy takes effect, smart card strings are removed from /etc/pam.d/system-auth on Red Hat Enterprise Linux 5.6 and /etc/pam.d/smartcard-auth and
/etc/pam.d/gnome-screensaver on Red Hat Enterprise Linux 6.0.
4. Expand Computer Configuration > Policies > Centrify Settings > Linux Settings, click Security, then double-click Lock Smart Card
screen for RHEL.
6. To apply these group policies immediately to any computer, restart the computer or run the adgpupdate command on it.
policy updates, they are no longer enabled for smart card use.
To Disable Smart Card Support by Running sctool
2. Run the sctool utility with the --disable option:
3. Repeat steps 1 and 2 for each computer on which to disable smart card authentication.
Note: If you originally enabled smart card support through group policy by setting “Enable smart card support” you cannot disable it by using
sctool --disable. Although this command will temporarily disable smart card support, it will be re-enabled by the policy at the next group policy
update interval. To permanently disable smart card support, you must disable Enable smart card support as described in the previous
procedure, To disable smart card support by using group policy.
If you have problems with smart card login, Server Suiteprovides a command-line tool, sctool, that you can run to configure smart card login, as well as to
provide diagnostic information. For example, you can run sctool with the following options:
sctool --status to show whether smart card support is enabled.
sctool --dump to display information about the smart card system setup as well as any smart cards that are attached to the computer.
sctool --pkinit userPrincipalName to obtain Kerberos credentials on a single-user smart card for troubleshooting purposes.
During login with a smart card, the agent calls sctool --pkinit to obtain Kerberos credentials from the smart card currently in the reader. Because this option
simulates a good portion of the smart card login process, if you are having trouble logging in you can run sctool --pkinit to obtain useful troubleshooting
information. If the command executes successfully, the name of the user will be displayed. If the command fails, you will receive an error message that
may help you troubleshoot the issue.
sctool --altpkinit unixName to obtain Kerberos credentials on a multi-user smart card for troubleshooting purposes.
During login with a multi-user smart card, the agent calls sctool --altpkinit to obtain Kerberos credentials from the smart card currently in the reader
(because the card is configured for multiple accounts, the user is prompted to provide a username, which the command uses to obtain the Kerberos
credentials). Because this option simulates a good portion of the smart card login process, if you are having trouble logging in you can run sctool --altpkinit
unixName to obtain useful troubleshooting information. If the command executes successfully, the name of the user will be displayed. If the command
fails, you will receive an error message that may help you troubleshoot the issue.
sctool --check-kdc-eku to enable checking of the KDC certificate for the Extended Key Usage (EKU) extension "Kerberos Authentication". Do not use this
option if you have not updated your KDC to include the required EKU. Enable EKU checking after updating your KDC certificate.
EKU checking is disabled by default.
This parameter must be used with the -k (--pkinit) parameter or the -a (--altpkinit) parameter
For more information about using sctool, see the sctool man page.
Administration Guides
The following administrator guides are available
Linux/Unix Administrator Guide

Windows Administrator Guide
macOS Administrator Guide
Unix/Linux Quick Start
MFA Guide
Auto-Enrollment Guide
Administering Linux / Unix
Refer to the following topics:
Server Suite for Linux / Unix

Managing Zones and Delegating Admin Tasks
Managing Account Profiles and Identity Attributes
Authorizing Basic Access
Defining Rights to Use Commands
Defining Rights to Use PAM Applications
Using Secure Shell Sessions-based Rights
Creating and Assigning Custom Role Definitions
Working with Managed Computers
Importing sudoers Configuration Files
Using Centrify OpenLDAP Proxy Service
Using Workstation Mode and Auto Zone
Troubleshooting Authentication and Authorization
Using Centrify Commands for Administrative Tasks
Using Python with Centrify Objects
Server Suite for Linux and UNIX
Server Suite is an IT management solution that provides key services for managing user and group profiles, role-based access rights, elevated privileges for
administrative activity, and auditing-based regulatory compliance. These services can be used together or independently, depending on the requirements of
your organization. The topics in this section introduce the key Server Suite that enable you to centrally manage Linux and UNIX computers. It includes an
overview of how Centrify enables your organization to manage identity attributes, role-based access rights, and administrative activity through an integrated
set of services.
Why Securing Access is Crucial
For most organizations, it is critical to control access to computer and application resources to prevent disruptions of service, data tampering, or security
breaches. For many organizations, it is also critical to monitor and report on user activity to ensure regulatory compliance with government or industry
standards. However, managing who has access to sensitive data, core business services, and the computers and applications that perform vital functions is
especially difficult in data centers that include a mix of virtual and physical computers running different operating systems and platform versions.
Why Managing User Account Information Might be a Problem
In a cross-platform environment, you are likely to have multiple identity stores that might have overlapping or conflicting information about the user
population. You might also have several different authentication methods—with varying degrees of security—that you are required to manage. For example, in
a typical environment with a mix of Linux and UNIX computers, you might have to maintain any combination of the following authentication methods:
Local configuration files on individual UNIX servers and workstations to identify local users and groups.
NIS or NIS+ servers and maps to store account and network information for groups of UNIX servers and workstations.
Kerberos realms and a Key Distribution Center to provide authentication for some users and services.
Lightweight Directory Access Protocol services to support LDAP queries and responses.
Managing all of these services separately can be costly and inefficient. In addition, users who have access to more than one application or computer platform
often have to remember multiple login accounts with conflicting user name or password policy requirements. Individual applications might also require the
use of a specific authentication method. For example, a database application or a web service might require users to have a database- or application-specific
account.
If you have an environment where user and group account information is stored in multiple locations rather than in a single repository, it is likely that you have
overlapping, conflicting, or out-of-date information about who should have access to the computers in your organization. You might also be using less secure
authentication and authorization services than required, if you are relying on local configuration files or NIS servers and maps. For example, if you are in an
organization that is subject to regulatory compliance, an audit might require you to improve the security of the authentication and authorization services you
use.
Why Managing Access and Privileges Might be a Problem
Most organizations require some groups of users to be allowed to use administrative accounts and passwords. For example, you might want to grant these
permissions to allow some users to log on to computers that host administrative applications or data center services, but restrict access so that users can
only log on when appropriate.
In many cases, the primary way you secure access to computers is by granting a limited number of users or groups root administrative privileges or
configuring sudoers rights locally. These common practices leave computers vulnerable to insider threats and present a security risk that might be exploited
by an external attack. As common as it is, granting administrative access rights is likely to violate the principal of least privilege, which is intended to minimize
your exposure to these types of risks.
In other cases, users who need administrative privileges to perform specific tasks might use a shared administrator and service account password. However,
shared passwords reduce accountability, leave computers vulnerable to insider threats, and are also often flagged by auditors as a security issue. If you are in
an industry that has compliance requirements, shared passwords might present a significant business risk.
How Centrify can Reduce Security Risks
To reduce the overhead of managing account information and access rights across your organization, Centrify provides the following key features:
Secure Authentication and Identity Management
Centrify enables you to define and manage the identity attributes in user profiles, consolidate and simplify the management of account information, improve
the security of authentication and directory services, and enforce consistent password and account policies.
Role-based Access Rights
Centrify enables you to define and manage access rights and role definitions, restrict which users can do what on specific sets of computers or during
specific periods of time, and control and restrict access to administrative privileges.
Delegation of Authority
Centrify enables you to delegate administrative activity on a task-by-task basis. By delegating individual tasks to specific users or groups, you can establish a
separation of duties at the level of granularity you require.
Auditing of Activity
Centrify enables you to collect and store an audit trail of user activity when and where you want it. With the auditing service, you can selectively capture and
analyze only audit trail events or all user and computer activity.
These features can be used together or independently, depending on the type of licenses you purchase and the specific requirements of your organization.
For example, some licenses for Server Suite might enable identity management, access control, and privilege management. Other licenses might enable
auditing of user activity and reporting services.
How Zones Help you Organize Information
One of the most important aspects of managing computers with Centrify software is the ability to organize computers, users, groups, and other information
about your organization into Centrify zones. A Centrify zone is a logical object that you create to organize computers, rights, roles, security policies, and
other information into logical groups. These logical groups can be based on any organizing principle you find useful. For example, you can use zones to
describe natural administrative boundaries within your organization, such as different lines of business, functional departments, or geographic locations. You
can also use zones to isolate computers that share a common attribute, such the same operating system.
Zones provide the first level of refinement for access control, privilege management, and the delegation of administrative authority. For example, you can use
zones to create logical groups of computers to achieve the following goals:
Control who can log on to specific computers.

Grant elevated rights or restrict what users can do on specific computers.
Manage role definitions, including availability and auditing rules, and role assignments on specific computers.
Delegate administrative tasks to implement “separation of duties” management policies.
You can also create zones in a hierarchical structure of parent and child zones to enable the inheritance of profile attributes, rights, roles, and role
assignments from one zone to another or to restrict local or remote access to specific computers for specific users or groups.
Because zones enable you to grant specific rights to users in specific roles on specific computers, you can use zones as the first level of refinement for
controlling who has access to which computers, where administrative privileges are granted, and when administrative privileges can be used.
You can also use zones to establish an appropriate separation of duties by delegating specific administrative tasks to specific users or groups on a zone-by-
zone basis. With zones, administrators can be given the authority to manage a given set of computers and users without granting them permission to perform
actions on computers in other zones or giving them access to other Active Directory objects.
Improving Security: Access and Privilege Management
Centrify provides its identity management, access control, and privilege management features for Linux and UNIX computers through a combination of
features provided by Access Manager and by the Centrify Agent on the computers you want to manage.
You can install Access Manager and related management tools on one or more Windows computers. For example, the central console for performing most
identity management, access control, and privilege management tasks is Access Manager. From Access Manager, you can perform all of the following
common administrative tasks:
Define and manage identity attributes for the Active Directory users who need access to Linux and UNIX computers.
Import and migrate UNIX users, groups, and network information from local configuration files and NIS maps.
Define and manage rights that allow users to run command-line programs, PAM applications, and secure shell operations.
Select rights to create role-based access control role definitions and assign those roles to the appropriate users and groups.
Delegate administrative tasks and control the specific permissions granted to users who are managing the computers in your organization.
For example, you can use Access Manager to delegate specific administrative tasks—such as the ability to add and remove users or assign roles—to a
particular user or group. As an administrator, you can also use Access Manager to configure roles that have specific start and expiration dates or that limit
the availability of a role to specific days of the week or hours of the day. You can use zones in combination with rights and roles to restrict or grant access to
specific Linux and UNIX computers in your organization.
Through the use of zones and roles, Centrify provides granular control over w h o can do what, and control over where and when those users should be
granted elevated privileges.
Consolidating User Account Information
Centrify enables you to consolidate all of your user and group account information in a single repository. By consolidating user account information, you can
improve IT efficiency and overall operational security. For example, you can automate the provisioning of new accounts and the elimination of accounts that
are no longer used without changes to your existing infrastructure or processes.
A single repository also enables you to establish consistent password policies for all of the computers you manage. For example, you can enforce consistent
rules for password complexity and minimum length for all users on all computers. A single repository also benefits users, who only have to remember one
password, regardless of the computer they use.
By using Centrify zones and override controls, you can migrate your entire user population without modifying any existing account attributes. For example,
you can map multiple UNIX profiles with different identity attributes to a single user account, or resolve conflicts if the profiles for different users have the
same identity attributes. This flexibility ensures that you can migrate legacy user accounts without changing any existing profile attributes, so that all of the
existing directory and file ownership remains unchanged.
Over time, you can then continue to improve organizational security by eliminating legacy identity stores, directories, and databases, including all locally
managed /etc/passwd files and local user accounts.
Defining Role-based Access Rights
Role-based access rights are more flexible than UNIX group membership rights and easier to define than user specifications in a sudoers configuration file.
Role-based access rights can be narrowly applied or broadly inherited across any number of computers. You can restrict when role-based rights can be used
by defining roles that are available only on certain days of the week or only during specific hours of the day. You can also make role assignments temporary by
setting a date and time for the assignment to start or expire. For example, you might given the user Jonah elevated privileges to run administrative commands
in the Backup Operators role for a period of two weeks while the primary backup administrator is on vacation.
Role-based access rights also prevent password sharing for privileged accounts, helping to ensure accountability. Users who need to run privileged
commands can either temporarily elevate their privileges in an unrestricted login shell or be required to run the commands in a tightly controlled restricted
shell without being prompted to provide the administrative password. All of their privileged or restricted shell activity can be traced to the account they used
to log on.
Improving Accountability: Auditing User Activity
Centrify provides its auditing and analysis features through a combination of auditing components on Windows computers and the auditing features of the
Centrify Agent on the computers you manage. The auditing service includes several components to support the multitier architecture of the auditing
infrastructure. These components are installed on Windows computers to enable you to collect and store detailed information about user activity.
The central console for configuring the auditing infrastructure and managing audit-related features is Audit Manager. From Audit Manager, you can perform
the following common administrative tasks:
View the status of all audited computers and the other components of the auditing infrastructure.
Manage the scope and security for auditing-related activity.
Set permissions for the tasks granted to specific auditors.
There is also a separate Audit Analyzer console for searching and replaying captured activity.
Why auditing User Activity is Important
Just as it is important to protect assets and resources from unauthorized access, it is equally important to track what the users who have permission to
access those resources have done. For the users who have privileged access to computers and applications with sensitive information, auditing helps ensure
accountability and improve regulatory compliance. With the audit and monitoring service, you can capture detailed information about user activity and all of
the events that occurred while a user was logged on to an audited computer.
If you choose to enable auditing on Linux or UNIX computers, the Centrify Agent on that computer starts recording user activity as soon as a user logs on. The
agent continues recording until the user logs out or the computer is locked because of inactivity. The user activity captured includes an audit trail of the
actions a user has taken and a keystroke record of the text that was entered (stdin) and the results that were displayed (stdout and stderr). The information
recorded while a user is logged on—which is called a session—is collected as it happens, so you can monitor computers for suspicious activity or
troubleshoot problems immediately after they occur.
Reviewing User Activity
When you audit user activity on a computer, the information is transferred to a Microsoft SQL Server database so that it is available for review and follow-up.
Because sessions and audit trail events are stored in the database, you can create queries and reports to find information of interest. For example, you can
search the stored user sessions to look for policy violations, command-line execution errors, or malicious activity that may have led to a service degradation
or an outage.
In addition to saving the input and output recorded, sessions provide a summary of actions taken so that you can scan for potentially interesting or damaging
actions without playing back a complete session. After you select a session of interest in Audit Analyzer, the console displays a list of commands in the order
in which the user executed them. You can then select any command in the list to start viewing the session beginning with that action. For example, if the user
ran a command that reports credit card information, you can scan the list of commands for the command that accesses credit card information and begin
reviewing what happened in the session from that time on.
Using Access and Auditing Features Together
You can use access-related features and components without auditing if you aren’t interested in collecting and storing information about session activities.
You can also deploy auditing-related features and components without access control and privilege management features if you are only interested in
auditing user activity on Linux and UNIX computers. However, you can recognize the most value from Server Suite by using all of the services as an integrated
solution for managing elevated privileges and ensuring accountability and regulatory compliance across all platforms in your organization.
Enabling Access Control without Auditing on a Managed Computer
If you only enable access control features, the agent enforces the role-based privileges that enable users to log on, access PAM-based application, and run
administrative or restricted shell commands. All of the role-based activity is traceable to the user’s own account credentials. However, the audit trail of user
activity is only recorded in the computer’s local system log (syslog) facility. Information that is only stored in a computer’s syslog facility can be more difficult
to monitor and query than information stored in a central repository such as Microsoft SQL Server database.
Enabling Auditing without Access Control on a Managed Computer
If you only enable auditing, the agent captures detailed information about the command input and output in the login shell of the managed computer. All of the
activity is stored in the Microsoft SQL Server database and available to you for queries and reports. However, there’s no role-based enforcement of what
activity is allowed on the audited computer.
Enabling Access Control and Auditing on a Managed Computer
If you use the infrastructure access management and auditing services together, you can define role-based access rights, restrict when and where roles are
available, identify roles that should be audited, trace activity when roles with elevated permissions are selected and used, and play back session activity
based on the criteria you choose.
By combining access management and auditing on the same computer, you can have an audit trail and, optionally, a video record of all actions performed
with elevated privileges. For example, when you deploy access management, users must be assigned to a role with permission to log on. If they are allowed to
log on and auditing is deployed, the agent begins auditing their activity. If a user accesses a PAM-based application or executes a privileged command, the
action is recorded and can be traced back to the account used to log on.
The following illustration provides a simplified view of the architecture and flow of data when you deploy components for access control, privilege
management, and auditing on a Linux or UNIX computer.
Linux or UNIX computer
However, auditing requires database storage for the audited sessions audit trail events. Auditing also requires additional management of the network
connections used to collect and transfer audit-related information from computers being audited to one or more databases where the sessions and audit
trail events are stored. If you plan to use the infrastructure access management and auditing services together, you also need to decide which roles should
require auditing and which features to enable on each computer you want to manage. In most cases, you choose whether to enable access control features,
auditing features, or both feature sets when you install the agent on a computer.
Although it is not depicted in the illustration, you do not have to enable the auditing service to record audit trail events locally for successful or failed
operations. By using the auditing service, however, you can store the audited sessions and audit trail events in a database and report on specific types of
activity, such as the execution of privileged commands or access to applications and information that must be kept secure. With auditing enabled, the audit
trail and the user activity are available for display, querying, and analysis from any computer where you install Audit Analyzer. Through rights and roles you
can restrict access to sensitive information and control who can run commands with elevated privileges or perform administrative tasks. Through queries
and reports, you can track all of the activity taking place—by user, computer, the time the activity took place, the role that was used, the command that was
executed, or other criteria—to verify that only authorized users are performing authorized tasks and to investigate and correct any unauthorized access
anywhere in your organization.
For complete information about setting up and managing an audit installation, see the Auditing Administrator’s Guide.
Managing Zones and Delegating Administrative Tasks
Zones are the key component for organizing account profiles, identity attributes, role-based access rights, and role assignments. Zones also enable you to
establish logical administrative boundaries and delegate specific administrative tasks to the appropriate users and groups for Linux and UNIX computers.
This chapter describes the different types of zones and how to use Access Manager to create and manage zones, modify zone properties, and delegate
administrative tasks to other users and groups in your organization.
Starting Access Manager for the First Time
The first time you start Access Manager, you can use the Setup Wizard to prepare the Active Directory forest with organizational units and containers for
Centrify objects. From the Setup Wizard, you can create either the recommended deployment structure or a custom deployment structure and set all of the
appropriate permissions for the objects automatically. If you skip this initial configuration, you can rerun the Setup Wizard at a later time or create
organizational units and containers manually. At a minimum, however, you need to select a location in Active Directory for license keys and zones. For more
information about the recommended organizational units and permissions, see the Planning and Deployment Guide.
What to do Before Updating Active Directory
Before you use Access Manager the first time, you should contact the Active Directory administrator to determine the appropriate location for the
deployment structure and whether you have the appropriate rights for completing this task. The specific administrative rights required for this task depend
on the policies of your organization and who has permission to create classStore and parent and child container objects in Active Directory.
Rights Required for this Task
If you don’t have administrative rights to create container objects in Active Directory, a domain administrator in the forest root domain can run the Setup
Wizard or manually create the container objects and set the rights on those objects to allow other users to complete the initial configuration without being
members of an administrative group.
The following table describes the minimum rights that must be granted on manually created container objects for other users to successfully complete the
configuration with the Setup Wizard.
This target
object
Licenses
Read all properties Create classStore objects Modify permissions This object only
container

Write Description property Write displayName property
objects
By default, all Authenticated Users have read and list contents permission for the Licenses container and all
of its child objects.
Zones container Read all properties Create classStore objects Create Container objects This object only

objects
If you are a domain administrator and manually creating the container objects, you should add a security group for Zone Administrators to Active Directory.
Set the following permissions on the parent Zones container to allow other users to manage zones.
Zones container Read all properties Create Container objects Delete Container objects This object only
Write displayName property This object and all child objects
Who Should Perform this Task
A Windows Active Directory administrator performs this task, depending on your organization’s policies, by running the Setup Wizard or by manually creating
container objects and notifying another user of the location of the container objects. The user who runs the Setup Wizard must be granted the rights required
to create classStore objects.
How often you Should Perform this Task
In most organizations, you only do this once for an Active Directory forest. However, if you want to create more than one administrative boundary, you can
create additional parent containers as needed.
Steps for Completing this Task
The following instructions illustrate how to run the Setup Wizard from Access Manager.
To update Active Directory using Access Manager:
2. Verify the name of the domain controller and the user credentials for connecting to the forest, then click O K.
5. Select Generate the Centrify recommended deployment structure if you want to create all of the containers for the recommended
deployment structure automatically.
If you select this option, select whether you want to generate the default deployment structure or generate a custom structure, then click Next.
If you are generating the default structure, clicking Next enables you to select or create the location for the deployment structure in Active
Directory. For example, if you want to create the top of the default deployment structure at the domain level, click Next, then click Browse to
select the domain name. After you have selected a location, click O K. then click Next to create the deployment structure.
If you are generating a custom structure, clicking Next enables you to export the script that creates the default structure or run a script you have
previously written.
If you are generating a default or custom deployment structure, verify the successful execution of the script that creates the structure, then click
Next to continue.
6. Verify the parent container for licenses is in the top-level Centrify container if you are using the default deployment structure or the container of your
choice, then click Next.
You can add other Licenses containers in other locations later using the Manage Licenses dialog box.
7. Review the permission requirements for the container, then click Yes to continue.
9. Verify the Create default zone container option is selected and the parent container for zones is in the top-level Centrify container or the
container of your choice, then click Next.
If you run the Setup Wizard at any time after the initial creation of the Zones container, this step displays the Change default zone container
option and the current container location. Select this option and click Browse to change the default container for zones, then click Next.
10. If you are using the recommended deployment structure, click Next to continue.
This option allows “self-service” join operations for computers in the Computers container. It is only applicable if you are not using the recommended
deployment structure. If you want to support “self-service” join operations and are not using the recommended deployment structure, select Grant
computer accounts in the Computers container permission to update their own account information, then click Next.
11. If you plan to use Access Manager to manage information stored in Active Directory and maintain data integrity, click Next to continue.
You should select Register administrative notification handler for Microsoft Active Directory Users and Computers snap-in if you
want to automatically maintain the integrity of the information in Centrify profiles.
This option prevents Centrify profile information from being left “orphaned” when changes are made to Active Directory objects such as users and
groups. This option is not selected by default because it requires you to be a member of Enterprise Admins or Domain Admins group for the forest root
domain.
12. Select Activate Centrify profile property pages if you want to be able to display Centrify profiles in any Active Directory context, then click Next.
Setting this option ensures that displaying the properties for a user, group, or computer always displays the Centrify Profile tab regardless of how you
navigate to the Properties dialog box.
What to Do Next
Create at least one parent zone.
Where you can Find Additional Information
If you want to learn more about the importance and benefits of using zones, see the following topics for additional information:
How zones help you organize information
Improving security: access and privilege management
Improving accountability: auditing user activity
Preparing to Create Zones
As discussed in How zones help you organize information, Centrify zones help you organize computers, users, groups, access rights and other information
into logical groups similar to Active Directory organizational units or Network Information Service (NIS) domains. You have several options when choosing the
type of zone to create, and the type of zone you select depends entirely on what your organization needs. The first decision to make is the type of zone to
create:
Hierarchical, which is the default and supports inheritance and overrides.

Classic, which is backward-compatible to support older versions of the Centrify Agent.
SFU, which supports the Microsoft Services for UNIX schema and rarely used.
Auto Zone, which is a simplified “zone” for computers to join when you don’t need any control over profiles, access rights, or roles and role assignments.
With the exception of SFU zones, you can mix and match any combination of zone types in the same Active Directory forest, as needed. For example, you can
create one or more classic zones to support legacy agents, an Auto Zone for a group of computers that don’t require the management of identity attributes or
access rights, and hierarchical zones for the computers for which you want to actively manage access rights and privileges.
Creating Hierarchical Zones
Hierarchical zones enable you to establish parent-child zone relationships, allowing profile attributes, rights, role definitions, and role assignments to be
inherited down the zone hierarchy. In most cases, you define information in a parent zone so that is available in one or more child zones, as needed. At any
point in the zone hierarchy, you can choose to use or override information from a parent zone.
You should use hierarchical zones if your organization has any of the following requirements:
You have existing user and group profiles that must be migrated with legacy identity attributes to maintain existing file ownership.
You have user and group profiles that have conflicting identity attributes on different computers.
You have users and groups that require different role-based access rights, privileges, and role assignments on different sets of computers.
If you are using hierarchical zones, you can use the local account management feature as described in Managing account profiles and identity attributes
You can configure multi-factor authentication for login access to Centrify-managed Linux and UNIX computers and for privileged command execution in
hierarchical zones, classic zones, and Auto Zone. However, some of the steps differ depending on the type of zone where you want to use multi-factor
authentication. For details about configuring multifactor authentication, see "Preparing to use multi-factor authentication" and the Multi-factor
Authentication Quick Start Guide.
Creating Classic Zones
Classic zones do not support inheritance or overrides and have other limitations in how they support role-based access rights. For example, in classic zones,
authorization is disabled by default, and must be consciously enabled on a zone-by-zone basis before any role-based access rights or privileges can be
configured or assigned.
You should only create new classic zones if your organization has any of the following requirements:
You must support older versions of the Centrify Agent for *NIX.
You have a user population with very few or no identity attribute conflicts.
You have little or no need to centrally manage access rights and privileges.
If you are using classic zones, you cannot use the local account management feature as described in Managing account profiles and identity attributes
You can configure multi-factor authentication for access to Centrify-managed Linux and UNIX computers and for privileged command execution in classic
zones. However, the implementation is slightly different than in hierarchical zones, so some of the steps differ depending on the type of zone where you want
to use multi-factor authentication. For details about configuring multifactor authentication, see "Preparing to use multi-factor authentication" and the Multi-
factor Authentication Quick Start Guide.
Creating an Auto Zone
Most organizations that deploy the Centrify Agent on Linux or UNIX computers have an existing user population to migrate to Active Directory, and
hierarchical zones make the most sense. However, multiple zones are not required for all situations. You can greatly reduce the time required and complexity
of your deployment if a single zone suits your organization’s needs. This type of zone is created automatically when computers join the domain using the --
workstation option.
An Auto Zone automatically enables all of the users and groups in an Active Directory forest to become valid users and groups on the Linux and UNIX
computers that join the Auto Zone.Their profiles are generated automatically and there’s no need to manage account profiles, access rights, privileges, or
delegated administrative tasks.
You should only use the Auto Zone option if your organization meets the following requirements:
You are not migrating an existing user population.

You want to automatically generate profiles for all or most Active Directory users and groups without managing identity attributes.
You don’t want to configure and manage role-based access rights and privileges or role assignments.
If you are using an Auto Zone, you cannot use the local account management feature as described in Managing account profiles and identity attributes
You can configure multi-factor authentication for both licensed and Express agents to control access to Centrify-managed Linux and UNIX computers. For
licensed agents, you can also require multi-factor authentication to run privileged commands in an Auto Zone. However, the implementation is slightly
different than in hierarchical zones, so some of the steps differ depending on the type of zone where you want to use multi-factor authentication. For details
about configuring multi-factor authentication, see the Multi-factor Authentication Quick Start Guide.
Creating a New Parent Zone
In most cases, you design a basic zone structure as part of the deployment process. After the initial deployment, you can create new hierarchical zones any
time you have new administrative boundaries. For example, if you acquire another organization, add offices that are managed by a different group, or
restructure the organization along different functional lines, you are likely to need new zones.
You can create as many parent zones as you need. You must create at least one new zone before you begin adding Linux and UNIX computers to the Active
Directory domain, unless you are joining with the --workstation option.
What to do before creating a new parent zone
Before you can create parent zones, you must have installed Access Manager and run the Setup Wizard. You should also have a basic zone design that
describes how you are organizing information, for example, whether you are using one top-level parent zone or more than one parent zone. You should also
decide whether to create the new zone in the default Zones container object or in another container or organizational units within Active Directory. There are
no other prerequisites for performing this task.
Rights required for this task
Only the user who creates a zone has full control over the zone and can delegate administrative tasks to other users and groups through the Zone Delegation
Wizard. To create new zones, your user account must be a domain user with the following permissions:
Select this target

object
Parent container for new On the Object tab, select Allow to apply the following permission to this object and all child objects: Create Container
zones, for example: Objects Create Organizational Unit Objects Note Both permissions are required if you want to allow zones to be created as
domain/Acme/Zones either container objects or organizational unit objects.
Parent container for On the Object tab, select Allow to apply the following permission to this object only: Create group objects Write Description
Computers in the zone property
Note: If the Active Directory administrator manually sets the permissions

required to create zones, you should verify that the account also has permission
to add an authorization store, define rights and roles, and manage role
assignments.
Who should perform this task
A Windows domain administrator performs this task, depending on your organization’s policies. The user who creates the zone is responsible for delegating
administrative tasks to other users or groups, if necessary. In most organizations, this task is done using an account with domain administrator privileges.
How often you should perform this task
After you are fully deployed, you create new zones infrequently to address changes to your organization.
Steps for completing this task
The following instructions illustrate how to create a new parent zone using Access Manager. Examples of scripts that use the Access Module for Windows
PowerShell, ADEdit, or the Centrify Windows API are available in other guides, the Centrify Software Developer’s Kit, or in community forums on the Centrify
website.
To create a new parent zone using Access Manager:
2. Select Zones, right-click, then click Create New Zone.
In most cases, you should use the default parent container and container type that you created when you configured the Active Directory forest and use
the default zone type, which creates the new parent zone as a hierarchical zone, then click Next.
The only reasons for changing the default settings would be if you want to:
Create a zone as an organizational unit because you want to assign a Group Policy Object to the zone.
Create a classic or SFU zone to support legacy Centrify Agents or to store data using the Microsoft Services for UNIX schema.
For additional information about any field in the new zone wizard, you can press F1 to view the context-sensitive help.
4. Review information about the zone you are creating, then click Finish.
What to do next
After you create a new parent zone, you might want to create its child zones.
Where you can find additional information
How zones help you organize information
Preparing to create zones
Creating Child Zones
The primary reason for creating child zones is to inherit profile attributes, role definitions, and role assignments from a parent zone. You can then use the
child zone to override the specific profile attributes that might be different on a given set of Linux and UNIX computers than you have defined in the parent
zone. Less often, you might want to use a child zone to override specific access rights, role definitions, or roles assignments that you have made in a parent
zone. For example, if you have created a role definitions that allows a user to run a specific application with administrative privileges in a parent zone, you can
use child zones to limit the scope of that right to specific subsets of computers.
What to do before creating child zones
Before you create child zones, you must have installed Access Manager, run the Setup Wizard to create the Zones container, and created at least one parent
zone. You should also have a basic zone design that describes the zone hierarchy for the child zone. There are no other prerequisites for performing this task.
Wizard. To create new child zones, your user account must be a domain user with the following permissions:
Container for the parent zone, for On the Object tab, select Allow to apply the following permission to this object and all child objects: Create
example if the parent zone is berlin: Container Objects Create Organizational Unit Objects Note Both permissions are required if you want to allow
domain/MyOU/Zones/berlin zones to be created as either container objects or organizational unit objects.
On the Object tab, select Allow to apply the following permission to this object only: Create group objects Write
Description property These permissions are only needed if you are supporting “agentless” authentication in the new
the zone
zone.
Note: If the Active Directory administrator manually sets the permissions

required to create zones, you should verify that the account also has permission
to add an authorization store, define rights and roles, and manage role
assignments.
A Windows administrator performs this task, depending on your organization’s policies. The user who creates the zone is responsible for delegating
After you are fully deployed, you create new child zones infrequently to address changes to the scope of ownership and administrative tasks.
The following instructions illustrate how to create a new child zone using Access Manager. Examples of scripts that use the Access Module for Windows
website.
To create a new child zone using Access Manager:
2. Expand Zones and the individual parent or child zones required to select the zone name that will contain the new child zone.
3. Right-click, then click Create Child Zone.
Because this is a child zone, you should use the default parent container and container type, then click Next.
5. Review information about the child zone, then click Finish.
Opening and Closing Zones
Because properties and objects are organized into zones, you must open a zone to work with its contents. If you open a parent zone, its child zones are also
available for you to use by default. If you open a child zone, you can choose whether to open its parent zone.
To open an individual parent or child zone:
2. Select Zones, right-click, then click Open Zone.
3. Type all or part of the name of the zone you want to open, then click Find Now.
4. Select the zone to open from the list of results, then click O K. You can use the CTRL and SHIFT keys to select multiple zones.
Loading all zones
As an alternative to opening individual or parent and child zones manually, you can automatically load all zones in a forest or all zones in a specific container
at startup time. If you choose to load all zones, you cannot manually close zones.
To load all zones automatically:
2. Select Access Manager, right-click, then click Options.
3. On the Filter Settings tab, select Load all zones, then select connected forest to automatically load all zones in the forest or click Browse to
navigate to specific container.
You should not select the Load all zones option if you want to manually open and close zones for performance reasons.
Closing individual zones
After you open a zone, it stays open during your current sessions unless you close it. If you have a large number of zones, however, you should close any zones
you aren’t actively working with for better performance.
To close an open zone:
2. Expand Zones and select an open parent zone, right-click, then click Close.
3. Click Yes to confirm that you want to close the zone.
Delegating administrative tasks
If you have created at least one zone, you can give other users and groups permission to perform specific types of administrative tasks within that zone. For
example, assume you have created a new zone called Finance and you want to give the users who access computers in this zone the permissions required to
perform certain kinds of tasks based on their role. You can accomplish this goal by selecting a group or users, then assigning that group or user one or more
tasks. For example, in the Finance zone, you might want to delegate administrative tasks like this:
The members of the Active Directory group FinanceITStaff are allowed to perform all administrative tasks in the Finance zone.
The members of the Active Directory group FinanceManagers are allowed to add, modify, and remove user and group profiles in the Finance zone.
The members of the Active Directory group FinanceUsers are allowed to join computers to the Finance zone, but perform no other tasks.
The Active Directory users jason.ellison and noah.stone are granted permission to manage role assignments in the Finance zone.
In most cases, each zone should have at least one Active Directory group that can be delegated to perform all administrative tasks, so that members of that
group can manage their own zone. You are not required to create or use a zone administrator group for every zone. However, assigning the management of
each zone to a specific user or group creates a natural separation of duties for administrative tasks.
If you delegate control for individual tasks—for example, by assigning only the join computers task to one group and only the add and remove users tasks to
another—you should ensure the members of each group know the tasks they are assigned.
You can delegate administrative tasks for parent zones, for child zones, and for individual computers. Because computer-level overrides are essentially
single computer zones, you can assign administrative tasks to users and groups at the computer level.
What to do before delegating administrative tasks
Before you delegate administrative tasks for a zone, you must have created at least one zone. For each zone you create, you should also identify at least one
user or group that can be delegated to perform all administrative tasks. For example, if you have a Finance zone, you might want to create a Finance Admins
group in Active Directory, then delegate All tasks to that group so that members of that group can manage their own zone.
There are no other prerequisites for performing this task.
Only the user who creates a zone has full control over the zone and can delegate administrative tasks to other users and groups.
For information about the permissions set when you select different administrative tasks in the Zone Delegation Wizard, see the Planning and Deployment
Guide.
The domain administrator who creates the zone is responsible for delegating administrative tasks to other users or groups, if necessary. Only the account
used to create a zone has full control over the zone’s properties and permission to delegate administrative tasks to other users. The user who creates a zone
is also the only user who can add NIS maps to the zone. The right to create NIS maps is exclusive to the creator of a zone because it requires permission to
create containers in Active Directory. The zone creator can, however, grant other users permission to add, remove, or modify NIS map entries.
In most organizations, you delegate administrative tasks any time you create a new zone. You also might change the delegation to change the either tasks
assigned or the users and groups that have been assigned specific tasks periodically to address changes to your organization. For example, if an existing zone
administrator takes over new responsibilities or leaves the organization, you might need to delegate additional tasks or select a different user or group to
perform administrative tasks.
The following instructions illustrate how to delegate zone administration tasks to a user, group, or computer using Access Manager. Examples of scripts that
use the Access Module for Windows PowerShell, ADEdit, or the Centrify Windows API are available in other guides, the Centrify Software Developer’s Kit, or in
community forums on the Centrify website.
To delegate administrative tasks to specific users and groups in a zone:
2. Expand Zones and the individual parent or child zones required to select the zone name for which you want to delegate administrative tasks.
4. Click A d d to find the users, groups, or computer accounts to which you want to delegate specific tasks.
5. Select the type of account—User, Group, or Computer—to search for, type all or part of the account name, then click Find Now.
6. Select one or more accounts from the list of results, then click O K.
7. When you are finished adding users and groups to which you want to assign administrative tasks, click Next.
8. Select the tasks you want to delegate to the user or group, then click Next.
For example, if you want all of the members of the group you selected in the previous step to be able perform all administrative tasks for a zone, check
the All task. To restrict the administrative tasks a user or group can perform, select only those specific tasks.
restrict the administrative tasks
10. Review your selections, then click Finish.
If you have delegate administrative tasks to one or more groups that have members logged on, you should notify the group members to log out and log back on
before they attempt to perform the administrative tasks assigned to the group.
Changing Zone Properties
After you create a zone, you can change its zone properties at any time. For example, if you want to change the parent zone for a child zone, you can do so by
modifying the child zone’s properties. Depending on whether you are viewing a classic, hierarchical, or SFU zone and the components you have installed, you
might see and be able to set different zone properties.
To display the properties for a zone:
2. Expand Zones and the individual parent or child zones, as required, to locate and select the zone name for which you want to display properties.
3. Right-click, then click Properties.
If the zone you have selected is a hierarchical zone, the properties are organized on the following tabs.
Use this
To do this
tab
View and set general information about the selected zone, including the location of the zone in Active Directory, the zone type, and the zone
General
description. For additional details about general properties, see the following topics:
Changing the zone description
Changing the parent zone or location of a zone
Setting the master domain controller for a zone
Selecting a license container for a zone
Adding support for agentless clients
Setting custom permissions for a zone
View and set the identity platform instance to use for the selected zone. For additional details about setting identity platform properties, see
Platform the following topic:
Selecting a identity platform instance for a zone
User Set default values for user profile attributes in the selected zone. For additional details about user default properties, see the following topic:
Defaults Setting user defaults
Set default values for group profile attributes in the selected zone. For additional details about group default properties, see the following
Group
topic:
Defaults
Setting group defaults
Add or edit user-defined variables or override the default values of predefined variables in the selected zone. For additional details about
Variables zone variables, see the following topic:
Configuring variables for a zone
Configure automated provisioning for user and group profiles if you have the Zone Provisioning Agent installed on the local computer. For
additional details about provisioning properties, see the following topic:
Provisioning
Configuring automated provisioning The Provisioning tab is only displayed if the Zone Provisioning Agent is installed. For detailed information
about configuring automated provisioning, see the Planning and Deployment Guide.
Changing the zone description
You can set or change the optional description for a zone at any time. For example, if you didn’t specify a description when you created the zone or if there
have been changes in your organization that warrant a change in the description of a zone, you can modify the Description field to make the change.
To change the zone description
3. Right-click, then click Properties to display the General tab.
4. Type a description for the zone in the Description field, then click O K.
Changing the parent zone or location of a zone
From Access Manager, you can make any existing hierarchical zone the child of another zone or make any child zone a new parent zone by dragging and
dropping the zone into a new location or by changing the Parent zone field on the zone’s General properties tab.
Selecting the default location when moving a zone
If you make changes to the zone hierarchy, Access Manager prompts you to specify the new Active Directory location for the zone. In most cases, you should
accept the default location for the zone you are moving. The default Active Directory location will be either:
The new parent zone container if you are moving a child zone from one parent to another or if you moving a parent zone to become a child zone.
The default Zones container you created the first time you started Access Manager if you are making a child zone a new top-level parent zone.
You are not required to accept the default Active Directory location when changing the zone hierarchy. If you select a different Active Directory location for
the zone, however, you should note the location and whether the zone you are moving is now a parent or a child zone. If the zone structure displayed in Access
Manager is different from the zone container structure you are using in Active Directory, you might find unexpected problems with inheritance and overrides,
with modifying zone properties, or with deleting zones.
Moving a zone without changing its Active Directory location
When you are prompted to specify the Active Directory location for a zone you are moving, you have the option to select N o and leave the current Active
Directory location unchanged. If you change the parent zone without changing the Active Directory location for a zone, you should note that the location does
not reflect the zone hierarchy. In rare cases, you might find it useful to leave the Active Directory location unchanged but doing so might make it more difficult
to locate the zone object at a later time.
Restarting the agent after moving a zone
If you change the location for a zone in Active Directory, you must restart the Centrify Agent for *NIX on the computers in that zone so that they recognize the
new zone location.
After you move the ZoneName object to a new parent container or organizational unit, run the following command to restart the Centrify Agent for *NIX on the
computers in the zone:
/usr/share/centrifydc/bin/centrifydc restart
To move a zone to a new parent by changing properties
4. For the Parent zone field, click Browse to find and select the zone to use as the parent, then click O K.
5. Click O K to save the new zone properties.
6. In the Move Zone dialog, verify the location selected for the Yes, move to option to accept the default location, then click O K.
In rare cases, you might want to click Browse to select a different Active Directory location for the zone you are moving, or select N o, then click O K to
keep the zone in its original location.
Setting the master domain controller for a zone
In most cases, computers connect to the first available Active Directory domain controller and it is not necessary to specify the master domain controller to
use for a zone. In some cases, however, you might want to identify a specific domain controller to use for a zone to prevent connections from other domain
controllers from adding or removing users and groups in that zone.
To prevent connections from other domain controllers, you can set the Master domain controller field to the fully-qualified name of the domain controller you
want to use. After you identify a master domain controller, administrators who connect to the zone using any other domain controller will not be able to make
changes to the zone.
If you have multiple administrators managing any zones, you should notify them before setting or changing the master domain controller. You should also
make this change while all other administrators are logged off. Depending how long it takes for replication to complete for all of the domain controllers in the
Active Directory forest, you might want to schedule this change for a time when no administrators need access to zone information.
To change the master domain controller
2. Expand Zones and the individual parent or child zones, as required, to locate and select the zone name for which you want to change the master domain
controller.
You can use Shift-Click or Ctrl-Click to select multiple zone names.
3. Right-click, then click Change Master Domain Controller.
4. Type the fully-qualified domain name for the new domain controller, then click O K.
5. Click Yes to confirm that you want to change the master domain controller for the zone.
You should avoid changing from one master domain controller to another, if possible. Changing the master domain controller requires you to wait for
replication to complete to see up-to-date zone information or modify information in the selected zone. In some cases, however, changing the master domain
controller might be unavoidable. For example, if there are zones connecting to a master domain controller that has a hardware failure or must be taken offline
for maintenance, you will need to configure a new master domain controller for the zones to use.
If you change the master domain controller, you should run the Analyze command afterwards to check the Active Directory forest and verify that no duplicate
UIDs or GIDs have been introduced.
Selecting a license container for a zone
By default, zones are configured to use any available license container in the forest. In most cases, the container used is the default Licenses container you
created the first time you started Access Manager. If you have more than one Licenses container, you might want to select a specific license container for a
set of computers in the one zone and a different license container for a set of computers in another zone. For example, you might want to select separate
Licenses containers for the zones associated with two different business units.
To use a specific license container for a zone, you can type the path to a new container object in the License container field.
To use a specific license container for a zone
4. Select a specific license container from the list of available License container, then click O K.
For more information about licenses keys and using multiple license containers, see the License Management Administrator’s Guide.
Adding support for agentless clients
If you are using the Centrify Network Information Service (adnisd) on a managed computer to respond to NIS client requests from computers where the
Centrify Agent cannot be installed, you can configure one or more zones to act as the NIS domain for those client requests.
To add support for agentless NIS clients in a zone
4. Select the Support agentless client option.
5. Select the Active Directory attribute you want to use to store the password hash and verify the zone name is the NIS domain name you want to use or
type a new name, then click O K.
For more information about installing and using the Centrify Network Information Service (adnisd) to respond to NIS client requests and configuring
agentless clients, see the Network Information Service Administrator’s Guide.
Setting custom permissions for a zone
For convenience, you can access Permissions for a zone directly from the zone properties General tab. You can then allow or deny basic permissions—such as
Read and Write permissions—to specific users and groups or click Advanced to set more granular permissions on a zone.
Selecting a identity platform instance for a zone
In most cases, the identity platform instance property is set automatically when you register a connector for Privileged Access Service. If you have access to
more than one identity platform instance—for example, if you have more than one customer identifier, you can select the URL for a specific instance from the
zone properties.
To select a identity platform instance for a zone
4. Click the Platform tab.
5. Verify the identity platform instance URL is the customer-specific URL you want to use, or click Browse to select the URL for a different customer-
specific identity platform instance.
Child zones inherit the identity platform instance property from their parent zone. If you are viewing properties for a child zone, you can select Override
trusted identity platform instance then click Browse to select a different identity platform instance for the child zone.
For details about installing and configuring a connector, see "Preparing to use multi-factor authentication."
6. Click O K to confirm the identity platform instance selected.
Configuring default values for a zone
You can configure default settings for user and group profiles that are added to the zone. The user and group defaults you configure can include predefined
variables that populate the user or group profile by using Active Directory attributes or settings configured on individual managed computers.
By specifying user default and group default settings, you can simplify the process of adding user and group profiles to child zones. For example, you can
define a default user profile that uses the sAMAccountName attribute for a user’s UNIX login name. All users who are added to the zone are then
automatically assigned a UNIX login name based on their sAMAccountName. If you define the default attributes in a parent zone, they can also be inherited in
all of the child zones under that parent and only overridden where other values are explicitly required.
Setting user defaults
When you create a zone, it includes a default set of user profile attributes. In most cases, there’s no need to modify any of the default settings unless you
want to define partial profiles in a parent zone that will be manually completed in child zones. For example, the default setting for the numeric user identifier
(UID) is an automatically generated UID based on the user’s globally unique security identifier (SID). This setting ensures all users who are added to the zone
are assigned a unique UID for the entire forest.
If you define a default value for any user profile attribute, that value is used to populate the user profile displayed when you add users to the selected zone.
When you add a user to the zone, you can accept the default profile attributes or override any of the default attributes displayed.
To view or modify the default user profile in a zone
4. Click the User Defaults tab.
5. Review the default settings and modify any of the defaults, if needed.
For most organizations, the default settings are appropriate. For example, the Active Directory sAMAccountName attribute most closely resembles the
most common format for the UNIX login name and an automatically generated UID ensures that all new users have a unique UID in the forest. For more
information about the attribute fields or the default values, press F1 to view the context-sensitive help.
6. Click O K.
For more information about using default values, see Creating user profiles for Active Directory users. For more information about using predefined or custom
variables in user profiles, see Setting runtime variables in user profiles.
Setting group defaults
When you create a zone, it includes a default set of group profile attributes. In most cases, there’s no need to modify the default settings for groups unless
you are manually assigning numeric group identifiers (GID) or using the Apple algorithm for generating the GID.
If you define a default value for a group attribute, that value is used to populate the group profile displayed when you add groups to the selected zone. When
you add a group to the zone, you can accept the default profile attributes or override any of the default attributes displayed.
To view or modify the default group profile in a zone
4. Click the Group Defaults tab.
5. Review the default settings and modify any of the defaults, if needed.
For most organizations, the default settings are appropriate. For example, the Active Directory sAMAccountName attribute most closely resembles the
most common format for the group name and an automatically generated GID ensures that all new group have a unique GID in the forest. For more
information about the attribute fields or the default values, press F1 to view the context-sensitive help.
6. Click O K.
For more information about using default values, see Creating group profiles for Active Directory groups. For more information about using predefined or
custom variables in user profiles, see Setting runtime variables in user profiles.
Configuring variables for a zone
Predefined and custom variables enable you to generate user profiles and group profiles using Active Directory properties or properties defined on managed
computers.
You can add custom runtime variables, or override the definition for predefined variables, in a zone by modifying the zone properties. Runtime variables are
resolved by the agent when a computer joins a zone. The default user profile settings use predefined runtime variables in place of specific values for the
GECOS, Home directory, and Shell attributes.
Zone variables and their definitions are inherited down the zone hierarchy, and can be overridden in a child zone or on individual computers. You can also use
configuration parameters to control the value for any variables locally on particular computers. If a value is set in the configuration file, it overrides any values
that you set for the zone.
Adding custom runtime variable
In most cases, you don’t need to add custom variables to a zone. However, if you have modified the Active Directory schema or want to use custom attributes
in user or group profiles, you can add custom variables to the zone to accommodate your changes.
To add a custom variable to a zone
4. Click the Variables tab.
5. Click A d d.
6. Type a variable name and a value, then click O K.
For example, you might want to define a custom variable named gecos and set its value to a static string, such as Engineering-Nova Scotia-Q22, for a
zone.
Similarly, you might want to add custom variables for different operating systems you support, such as mac-home or aix-shell for a zone that includes
computers with different operating systems. For example, if a zone includes Linux, AIX, and Mac OS X computers, you might have a default profile that
uses the predefined variables, but a subset of accounts that use the mac-home or aix-shell custom variables.
7. Click O K to save the properties.
Modifying predefined variable values
In most cases, you don’t need to override predefined variable values for a zone. However, if you have created different zones for different operating systems,
you might find it useful to modify predefined variable values for those zones to address different operating system requirements.
To modify a predefined variable value in a zone
4. Click the Variables tab.
5. Click A d d.
6. Type the name of a predefined variable and a value, then click O K.
For example, you might want to change the predefined variable named home and set its value to an appropriate home directory for the zone, such as
/export/home for a zone where all of the computers are Solaris computers, or /Users for a zone with only Mac OS X computers. Similarly, you might want
to change the predefined variable shell to set its value to /usr/bin/ksh for a zone with IBM AIX computers.
7. Click O K to save the properties.
Editing or removing variables
After you have added custom variables or modified predefined variable values in a zone, you can later select those variables to edit or remove them.
Configuring automated provisioning
The Centrify Zone Provisioning Agent is a separate service that enables automated provisioning and de-provisioning of user and group accounts on a zone-
by-zone basis. You can configure the Zone Provisioning Agent to monitor specific Active Directory groups for a zone. If you add or remove Active Directory
users or groups in the monitored groups, the Zone Provisioning Agent automatically adds or removes the corresponding user or group profiles in the zone. If
you have the Centrify Zone Provisioning Agent installed, you can use the zone properties Provisioning tab to do the following:
Enable provisioning for users, groups, or both.
Specify the Active Directory group to base provisioning on.
Select the method for automatically generating profile attributes for users, groups, or both.
For more detailed information about automated provisioning and using the Zone Provisioning Agent, see the Planning and Deployment Guide. For more
information about the attribute fields or the options for generating profile attributes, press F1 to view the contextsensitive help.
Renaming a Zone
You can rename a zone at any time. For example, if your organization changes how business units are aligned, moves to a new location, or merges with
another organization, you might want to update zone names and descriptions to reflect these changes. You might also want to rename zones if your initial
deployment did not use a naming convention for new zones, and you want to implement one after you have agents deployed.
What to do before renaming a zone
Before you rename zones, you might want to define and document a naming convention to use for future zones or the reasons for changing the zone name.
You should also identify the computers in the zone to be renamed. You must restart the agent on those computers for the new zone name to be recognized.
There are no other prerequisites for performing this task.
Parent container for an individual Write Description Write name Write Name These are the minimum permissions required to rename a zone and not
zone For example, a ZoneName allow a user or group to modify any other zone properties. You can set permissions manually, or automatically grant
container object, such as: these and other permissions to specific users or groups by selecting the Change zone properties task in the Zone
domain/Zones/arcade Delegation Wizard.
After you are deployed, you rename zones only when you need to address organizational changes or to implement or improve the naming conventions you
use.
The following instructions illustrate how to rename a zone using Access Manager.
To rename a zone using Access Manager:
2. Expand Zones to display the list of zones, then expand any child zones in the zone hierarchy until you see the specific zone you want to modify.
3. Select the zone to change, right-click, then click Rename.
4. Type the new name and, if needed, any changes to the zone description.
5. Restart all of the Centrify UNIX agents on the computers in the zone you have renamed.
You do not have to leave and rejoin after changing a zone name. However, you must restart the agent for the name change to take effect on a managed
computer.centrifydc In a terminal window on each managed computer, run the following command:
/usr/share/centrifydc/bin/centrifydc restart
6. You can verify the updated zone name on a local computer by using the adinfo command, which includes the joined zone name in its output.
Adding Computers to a Zone
You can only join a domain by creating a computer account that is either a “zone computer” profile or a “workstation” account that uses Auto Zone. Depending
on the tool and operating system you prefer to use, there are several ways you can add a computer account to a zone. For example, if you prefer to create the
“zone computer” account from a Linux or UNIX computer:
You can run the adjoin command interactively or in a script and specify the zone as a command line option while joining the Active Directory domain.
You can use ADEdit commands interactively or in a script to add a computer account to a zone before joining the domain.
If you prefer to create the “zone computer” account from a Windows computer:
You can prepare a computer account in Access Manager before joining the domain.
You can use the Centrify Access Module for PowerShell cmdlets interactively or in a script to add a computer account to a zone.
Precreating computer accounts using ADEdit or the Centrify Access Module for PowerShell cmdlets is particularly useful if you want to join multiple
computers with minimal command line options and if you want to allow the computer account to be used to perform a “self-service” join. For more
information about preparing a computer account before joining a domain, see Preparing computer accounts before joining.
For more information about specifying the zone, joining the domain, and modifying computer properties, see Working with managed computers. For
information about using Auto Zone, see Using workstation mode and Auto Zone.
Managing Licenses
The first time you start Access Manager, you are prompted to create a Licenses container and add or import license keys. You can also add and remove
license containers and keys after the initial configuration.
To modify license information
1. Open Access Manager
2. Select Access Manager, right-click, then select Manage Licenses.
3. Click Add to add a new license container or license key.
4. Select an existing license container or license key, then click Remove to remove that container or key.
For details about licensing, including how to request new license keys after deployment, check license usage and compliance, and how license counts are
determined, see the License Management Administrator’s Guide.
Reporting Zone Information
You can access legacy reports from within Access Manager by selecting Access Manager, right-clicking, then selecting Report Center. You can also use
command-line programs, PowerShell scripts, or ADEdit scripts to report zone information. In most cases, however, you should install and configure Report
Services to generate and access reports about the Active Directory domain and your zones.
For details about installing and configuring Report Services, and how to customize and access the reports that generated, see the Report Administrator’s
Guide.
Migrating from Classic to Hierarchical Zones
Classic zones are primarily intended for backward compatibility with older versions of the Centrify Agent. If you upgrade the agent to version 5.x or later, you
can migrate any or all of your classic zone information into one or more hierarchical zones.
Migrating a classic zone to a hierarchical zone is a multi-step process that requires some initial planning. For example, the first step in the migration changes
the zone type but does not change any existing zone information, including the computer accounts that are joined to the zone. To take full advantage of the
hierarchical zone after migration, however, it is likely that you will need to modify some of your existing zone information and move computer accounts into
different zones.
Preparing for migration
To prepare for the migration of any classic zones, you should first review the existing zone information for “dominant” user and group profiles—that is, profiles
with attributes that are common to multiple classic zones. Dominant profiles will help you to identify one or more classic zones that you can use as potential
parent zones. A parent zone provides a baseline for the user and group profiles that can be inherited in child zones. The parent zone also enables you to
manage rights and role definitions that can be inherited in the child zones you create. If you are able to identify dominant profiles, most of your classic zones
will become child zones that inherit information from the parent zone, with specific attribute overrides on a zone-by-zone or computer-by-computer basis,
as necessary.
To illustrate how you should analyze your existing environment, assume you have several classic zones to address different profile requirements on different
computers, but only two administrative groups that have different policies and procedures for adding users or granting privileges. In this scenario, you might
create two parent zones—one for each administrative team—and use child zones or computer overrides to address specific profile attribute differences. If
your organization has a single account fulfillment desk that handles all provisioning and access privileges, you might create a single parent zone for
managing all or most user and group profiles, then use child zones to manage more granular account privileges.
If you have a “master” classic zone where the most commonly-used profile attributes for most of your users and groups are defined, that zone is a likely
candidate to become a hierarchical parent zone. If none of your existing classic zones is suitable to become a parent zone, you should create a new parent
zone as described in Creating a new parent zone. The parent zone must exist before you can use the migration utility.
Verifying you have upgraded Access Manager
You can use Access Manager to view and manage any combination of zones. However, the console must be version5.x or later to work with hierarchical zones.
You can check the version of the console you have installed by opening Access Manager, clicking Help, then selecting About Access Manager.
Verifying you have upgraded UNIX agents
The migration utility is a command-line program installed with the Centrify Agent for *NIX. You must upgrade the agent to version 5.1, or later, on at least one
UNIX computer to do any migration. You can verify the agent version by running the adinfo command with the --version (-v) option.
What the migration utility does
After you have identified at least one classic zone as potential parent zones, you can use the migration utility to convert the classic zone into a hierarchical
parent zone. After you make the classic zone a hierarchical zone, you can run the migration utility to make other classic zones into child zones of the parent
zone.
During the migration, all of the user and group profiles in the source zone are copied to the specified parent zone. If identical profiles exist in multiple classic
zones, the identical profiles become a single profile in the parent zone. If there are user or group profiles in multiple zones with different attribute values—for
example, a UID of 10001 in one classic zone, but 10003 in another classic zone, the migration utility creates a single profile for the user in the parent zone, and
creates a profile override with the distinct attribute values in each target child zone. Each child zone inherits the base profile from the parent zone but applies
the overrides for any attributes that are different in different zones.
The migration utility copies everything else—including rights, roles, role assignments, groups, and NIS maps—into the new child zone for each classic zone
being migrated.
Using the migration utility
Centrify provides the command-line program admigrate to simplify the process of migrating profiles, rights, roles, role assignments, and NIS maps from a
classic zone to a hierarchical zone.
The admigrate program is installed by default in the following directory:
/usr/share/centrifydc/adedit/admigrate
Note that the first zone you migrate becomes the primary source of profile information for the other zones you migrate. You should start with the zone that it
contains the most consistent profile attributes.
Note: Admigrate does not migrate classic SFU zones (Ref: CS-28289a) nor
zone delegation rights (Ref: IN-90002).
To migrate zone information from a classic to hierarchical zone:
1. Log on to a Linux or UNIX computer running adclient and open a terminal window.
2. Open a text editor to create a file with bind information for each domain to which admigrate must connect.
Specify the Active Directory credentials for an account with permission to create child zones, rights, roles, user profiles, and group profiles in the parent
zone with one line per domain in the format:
bind domain_account_password
For example, create a file named migrate.conf with information similar to the following:
bind finance.acme.com administrator {1234abcepassword}

bind eng.acme.com engadmin {1234abcepassword}
4. Run the admigrate command.
admigrate -in classicZone -z targetZone -hz parentZone -config configFile
For this
Specify this information
variable
classicZone The distinguished name of the classic zone to migrate. For example: “cn=finance,cn=zones,ou=unix,dc=acme,dc=com”
The distinguished name of the new zone. It can be the same as the existing classic zone name, however the new zone will be a child zone of
targetZone the specified parent zone, so the distinguished name is different. For example:
“cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com”
The parent zone for the migration. The specified zone must be an existing zone. The target zone becomes a child zone of this zone. You can
parentZone run admigrate multiple times and specify the same parent zone and different source and target zones each time to migrate multiple zones to
different child zones of this parent. For example: “cn=global,cn=zones,ou=unix,dc=acme,dc=com”
The configuration file to use with the migration. The configuration file is primarily useful to specify bind information if you are migrating
configFile
zones from domains that are different from the target zone’s domain. The file is a simple text file, for example: -config admigrate.txt
For more information about other options you can use when running admigrate, see the man page for admigrate.
The first time you run admigrate, the command copies all of the user profiles from the source zone to the parent zone. Everything else defined in the source
zone—including groups, rights, role definitions, role assignments, and NIS maps—is copied from the source zone to a new target child zone.
1. Repeat Step 4 for each classic zone you want to migrate as a child of the parent zone.
Sample migration
To illustrate how to use the admigrate command, assume you are migrating two classic zones—finance and engineering—into a new empty parent zone
named global. For this example, the distinguished name of the classic finance zone (the source zone) is this:
“cn=finance,cn=zones,ou=unix,dc=test,dc=org”
After migration, the distinguished name of the finance child zone (the target zone) is this:
“cn=finance,cn=global,cn=zones,ou=unix,dc=test,dc=org”
To migrate the classic finance zone, you would run a command similar to the following:
/usr/share/centrifydc/adedit/admigrate \
-in “cn=finance,cn=zones,ou=unix,dc=test,dc=org” \
-z “cn=finance,cn=global,cn=zones,ou=unix,dc=test,dc=org” \
-hz “cn=global,cn=zones,ou=unix,dc=test,dc=org” \
-config ~/migrate.conf \
-v > migrate_finance.txt
In this example, the target zone name is the same as that of the input classic zone, except its distinguished name is different because it is a child zone of the
global zone. The -config parameter specifies the file that contains bind information, in this cases ~/migrate.conf. The -v option directs verbose output to a
text file.
You would then run admigrate for the next zone to migrate. For example:
/usr/share/centrifydc/adedit/admigrate \
-in “cn=engineering,cn=zones,ou=unix,dc=test,dc=org” \
-z “cn=engineering,cn=global,cn=zones,ou=unix,dc=test,dc=org” \
-hz “cn=global,cn=zones,ou=unix,dc=test,dc=org” \
-config ~/admigrate.txt \
-f -v > migrate_eng.txt
To simplify the migration process for multiple zones, you could put admigrate in a shell script and specify the source zone as an input variable or read it from a
file with a listing of all your zones.
Inheritance and overrides
Each time you run admigrate with the same parent zone and a different source and target zone, the admigrate utility does the following:
If a user profile from the source zone does not exist in the parent zone, the utility creates a profile for the user in the parent zone.
If a user profile exists in the parent zone and matches the user profile from the source zone, the new child zone will inherit the user profile attributes as
they are defined in the parent zone.
If a user profile already exists in the parent zone and has attribute values that differ from those for the user from the source zone, the utility creates a
user profile in the child zone with overrides for the differing attribute values. For example, if a user profile exists for oscar.romero in the parent zone, but
has a different numeric identifier (UID) in the engineering zone, the UID attribute value would be different in the engineering child zones. The other
attributes would be inherited from the parent zone.
Copies the groups, rights, role definitions, role assignments, and NIS maps from the source zone to the target child zone.
The admigrate utility does not copy delegated permissions from the existing classic zones to the new child zones. In addition, delegated permissions are not
automatically inherited from parent zones to the child zones. After migrating classic zones, you must explicitly delegate administrative permissions on a
zone-by-zone basis.
Roles and rights for migrated users
The admigrate utility adds the following role definitions for migrated users:
login_at_roles assigns the UNIX system rights Password login... and Nonpassword login. It does not assign Login with non-Restricted
Shell because the user may be assigned to a restricted shell.
login_all_apps assigns the login-all PAM right, which grants access to all PAM applications. It does not assign any UNIX system rights.
By default, all users are added to the login_all_apps role so that if they are granted login rights, they have access to all PAM applications, which is the
default for users in classic zones. If PAM access rights are restricted by another role assignment, the restricted role assignment will override the rights
granted by login_all_apps.
Access uses the following role-assignment rules when migrating roles and rights from a classic zone to a hierarchical zone:
Enabled
Classic
or Role assignment in hierarchical child zone
zone
disabled
User
Assign to the following roles: login_at_roles, which grants Password login and Nonpassword login UNIX system rights.
assigned to Enabled
login_all_apps, which grants access to all PAM applications. Corresponding user-created roles, which are migrated.
role
User
Assign to corresponding user-created roles, which are migrated. No login roles are assigned because the user is disabled in the
assigned to Disabled
classic zone.
role
User not
assigned to Enabled Assign to the default UNIX Login role, which grants all UNIX system login rights and access to all PAM applications.
role
User not
Assign to the default listed role, which makes the user visible in the zone but does not assign any UNIX system rights or PAM
assigned to Disabled
access rights.
role
In classic zones, users who are added to a zone are enabled for login access by default. As an administrator, you can leave a user profile defined in a zone but
disable login access.
All the roles and rights you defined in the source zone, as well as any role assignments to user-created roles, are added, as-is, to the child zone each time you
run admigrate. For example, if you defined a privileged mount command in 20 classic zones, admigrate will copy that mount command to 20 new hierarchical
zones. Therefore, after migration you should analyze your role definitions and access right definitions to see if some of them can be moved up to the parent
zone to take advantage of inheritance.
Assigning the audit level when migrating
In hierarchical zones, role definition can be assigned an auditing level. This setting is not applicable in classic zones.During migration from classic zones to
hierarchical zone, the default “Audit if possible” auditing level, is assigned to all migrated role definitions. After you have migrated, you can change the
auditing level in any role definition. For more information about changing the auditing level for a role definition, see Changing the audit level for role
definitions.
Moving joined computers to hierarchical zones
After you have migrated data from classic zones to new hierarchical zones, you can move the computers to the new zones using the adchzone command-line
program.
When you use adchzone to change the zone for a computer, the command copies the UNIX profile from the old zone to the new zone, deletes computer profile
from the old zone, then stops and restarts adclient to flush the cache and update the zone information. The advantage of this approach over leaving the old
zone (adleave) and then joining (adjoin) the new zone is that it is very quick and preserves all the join information without you having to specify join options.
For example, run a command similar to the following to move a computer joined to the classic finance zone to the new child finance zone:
/usr/share/centrifydc/adedit/adchzone \
-z “cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com”
-u finance-adm
You will be prompted to supply a password for the specified user.
After changing the zone, you can open Access Manager to see the computer in the Computers node of the new zone, or you can run adinfo on the computer to
verify the new zone information.
What to do after the migration
The admigrate utility migrates most zone information automatically. After using the utility, however, you might want to perform the following tasks to
complete the migration:
Delete unnecessary copies of right and role definitions.
You should analyze the right and role definitions to see how many of them have been copied into multiple zones. Rights and roles that are defined in the
parent zone are available for use in all child zones. By moving role and right definitions to the parent zone you simplify your zone structure making it
easier to understand the rights and roles that are available for your organization.
Review provisioning rules.
In many cases, hierarchical zones simplify automated provisioning by enabling you to define a baseline profile in a parent zone and only override specific
attributes when necessary. If you are using automated provisioning, you should check whether you are defining the provisioning rules in parent zones or
in child zones.
Delegate permissions on a zone-by-zone basis.
Use the Zone Delegation Wizard to delegate administrative tasks and the assign the corresponding permissions to the appropriate users and groups in
your new child zones.
Managing Account Profiles and Identity Attributes
This chapter describes how to create user and group profiles that grant access to Centrify managed Linux and UNIX computers and how to manage identity
attributes using Access Manager. No matter what type of zone your environment uses—classic, hierarchical, or auto zone—you can use Access Manager to
create and maintain profiles for Active Directory users and groups.
If your environment uses hierarchical zones, you can also use Access Manager to create and maintain profiles for local Linux and UNIX users and groups.
For Active Directory users and groups, you can also perform the tasks described here using ADEdit or Windows PowerShell commands and scripts or other
tools, such as Active Directory Users and Computers.
For local users and groups, you can also perform the tasks described here using adedit and other command line utilities. See Using Centrify commands for
administrative tasks for details about using commands to configure local users and groups.
For additional information about planning the migration of an existing user population, see the Planning and Deployment Guide.
Creating Group Profiles
You can create group profiles for Active Directory groups and—in hierarchical zone environments—local groups. A group profile consists of two attributes and
a list of group members. The attributes that must be defined for the group profile to be complete are the following:
A unique numeric identifier (GID).
A group name.
A group must have a complete profile with all of these attributes defined to be recognized as a valid group in a zone or on a specific computer. These are the
same attributes you define locally for Linux and UNIX groups in the /etc/group file.
For details about creating profiles for Active Directory groups, see Creating group profiles for Active Directory groups. For details about creating profiles for
local Linux and UNIX groups, see Creating, modifying, and deleting group profiles for local groups.
Creating group profiles for Active Directory groups
You can create a group profile for any domain local, global, or universal security groups you have defined in the Active Directory forest. Associating a group
profile with an Active Directory group also enables you to take advantage of any nested group membership you have defined and any group policies you have
applied to a domain or organizational unit.
Although associating a group profile with an Active Directory group can be convenient, there is no predetermined requirement to create group profiles for
Active Directory groups. Creating a group profile does not create profiles for any members of the group. User accounts must be explicitly given their own
profiles.
Note: You can automate the provisioning of account profiles through the
use of Active Directory groups. For information about configuring your
environment for automated provisioning, see the *Planning and Deployment Guide*.
What to do before creating a new Active Directory group profile
Before you can create Active Directory group profiles, you must have created one or more Active Directory security groups, installed Access Manager, and
run the Setup Wizard. You should also identify the specific Active Directory groups for which a group profile is required. In most organizations, only a limited
number of Active Directory groups require a zone profile. There are no other prerequisites for performing this task.
You must have permission to add groups to a zone. Zone administrators can grant this permission through the Zone Delegation Wizard. If the Active Directory
administrator manually sets the permissions, your user account must be a domain user with the following permissions to create group profiles in a zone:
On the Object tab, select Allow to apply the following permission to this object only: Create
Parent container object for the group profile within the
serviceConnectionPoint objects Click the Properties tab and select Allow to apply the following
zone
properties to this object only: Read objectClass
Group account object in Active Directory For example: Click the Properties tab and select Allow to apply the following properties to this object only:
domain/Users/group_name Read groupType Read objectCategory Read objectClass Read objectGUID Read objectSid
Parent container object for the individual zone For

Click the Properties tab and select Allow to apply the following properties to this object only:
example, if you are adding a group to the Finance zone:
Read objectGUID Write Description
A Windows domain administrator performs this task, depending on your organization’s policies. In most organizations, this task is delegated to a specific user
or group with administrative authority in the selected zone.
In most cases, you only create new group profiles infrequently to address changes to your organization.
If you choose to create group profiles for Active Directory groups, you can use Access Manager, Active Directory Users and Computers, the Access Module
for Windows PowerShell, ADEdit, or the Centrify Windows API.
The following instructions illustrate how to create a new group profile using Access Manager. Examples of scripts that use ADEdit, Windows PowerShell, or
the Windows API are available in other guides, the Centrify Software Developer’s Kit, or in community forums on the Centrify website.
To create a group profile for an Active Directory group using Access Manager:
2. Expand Zones and any parent or child zones required to select the zone name to which you want to add the Active Directory group.
3. Expand UNIX Data and select Groups, right-click, then click Create UNIX Group.
4. Type a search string to locate the Active Directory group for which you want to create a profile, then click Find Now.
For example, type “fin” to display the Finance Users and Finance Admins groups.
5. Select one or more groups in the results, then click O K.
6. Review the default zone profile settings for the group and make changes if needed, then click O K.
You can deselect an attribute to change the default value or to create a partial group profile in the current zone. You can complete the profile by
providing a value for an attribute in a child zone of the current zone. For example, if you use the same group name but different numeric identifiers on
two set of computers, you can inherit the group name from a parent zone and set the different numeric identifiers in the child zones.
In the AIX Extended Attributes tab, you can view and set AIX attributes for the group's zone profile. Click A d d to add an attribute and a value, click
Edit to change an attribute, or click Remove to remove an attribute from the group's zone profile.
If you selected more than one group, review the profile settings for the each group and modify the default settings, if necessary, then click O K.
If you are adding groups with similar names, you might want to modify the default group name to distinguish the groups. For example, if you are adding
both the Finance Admins and Finance Users groups to the same zone, you can change the default group name to finadmin and finuser to make it easier
to tell the groups apart. Keep in mind that in some operating environments group names cannot be more than 8 characters and special characters might
not be supported.
Creating, modifying, and deleting group profiles for local groups
When you create a local group profile in Access Manager, it is saved in /etc/group on each computer in each zone where the profile is defined. You can create
local profiles at the zone level (for example, under Zones > Zonename > UNIX Data) and at the computer level (for example, under Zones > Zonename >
Computers > Computername > UNIX Data). Local group profiles that you create at the zone level are available for local and Active Directory users in the
zone and child zones to join.
What to do before creating a new local group profile
You should perform the following tasks before creating local group profiles:
Ensure that local account management is enabled and configured through configuration parameters or group policies. See Enabling and configuring
local account management for more information.
It is suggested that you review the existing group names in etc/group on the computers where the local group profile will be implemented so that you do
not attempt to create a group profile with a name that is already used. Access Manager performs a name validation check against etc/group in the
current zone when you create a new local group. If the group name already exists in etc/group somewhere in the current zone, you are prompted to
provide a different name for the group that you are creating.
The rights required to create local group profiles are the same as the rights required to create Active Directory group profiles. See Rights required for this
task for details about those rights.
Using partial profiles and child zones to fine tune group attributes
Access Manager allows you to create a partial profile by leaving any of the attributes blank. Partial profiles can be useful for defining a common set of
attributes that are used in multiple zones, then defining specific attributes that vary from one child zone to another or that require different settings on
specific computers. For example, you could define the Members attribute in a parent zone, and then override the parent zone attribute settings by defining
the Members attribute differently in different child zones.
If you intend to leave an attribute blank, deselect the attribute check box. However, you must provide a value for at least one attribute to create the group
profile.
Groups can have an incomplete profile in a parent zone as long as any missing attributes are defined in a child zone. If a group profile is still partial at the
computer level, the profile is ignored by the agent, and it is not added to /etc/group on the local computer. Group profiles must contain the attributes listed in
Creating group profiles to be complete.
Specifying profile states
The profile state lets you control whether a local group account is in place in etc/group and is enabled for use locally. When you create a local group account,
you specify the initial profile state. You can change the profile state afterwards to control availability of the local group account. A local group account can
have one of the following states:
Enable: If the local group profile is complete, it will be installed or updated in /etc/group at the next local account refresh interval.
Remove from /etc/group: The group profile will be removed from etc/group at the next local account refresh interval.
You can also choose not to define the profile state by deselecting the State check box in the Set Local Group Profile dialog. Deselecting the State check box
results in one of the following scenarios:
If a local group profile with the same name exists in the parent zone, the state from the parent group profile is inherited.
If the parent zone does not contain a group profile with the same name, or if a parent group profile exists but does not define the state, the group profile
that you are currently defining is considered incomplete.
Roles and local group account visibility
You use role assignments to control whether local users are visible in a zone. A predefined role definition, local listed, is available for use with local user and
local group profiles. As with the listed predefined role, the local listed role does not grant any system rights, PAM rights, or command rights. It is a specialized
role that can be used when a local user or local group profile must exist for computers in a zone, but no local user or local group access should be granted.
You can optionally define other roles in the zone to grant visibility to local users and local groups.
By default, all local groups having a complete profile are visible in a zone. You do not have to assign a role to a local group to make the local group visible.
However, it is often useful to assign a role (such as local listed) to a local group so that all local users in the local group inherit the role assignment, and are
visible in the zone.
See Creating, modifying, and deleting user profiles for local users for more information about how roles are used to control visibility of local user accounts.
How often Access Manager and local group accounts are synchronized
The /etc/group file on local computers is updated periodically based on the information that you define for local group profiles in Access Manager. The
/etc/group update interval is controlled by the following group policy and configuration parameter:
Group Policy: Set refresh interval for access control cache, located in Computer Configuration > Centrify Settings > DirectControl Settings >
Network and Cache Settings.
Configuration parameter: adclient.refresh.interval.dz, located in the /etc/centrifydc/centrifydc.conf configuration file.
The same group policy and parameter control how often the authorization store cache is updated. Local account information is updated immediately after
authorization store information is refreshed in the authorization cache.
For more information, see the Group Policy Guide, the Configuration and Tuning Reference Guide, and Enabling and configuring local account management.
To create a group profile for a local group using Access Manager
2. Expand Zones and any parent zones, child zones, or computers required to select the zone or computer to which you want to add the local group.
3. Expand UNIX Data and select Local Groups.
You can create a new local group in these ways:
By dragging and dropping an existing local group from another location. Expand zones or computers to the location of the original
local group, and drag it to the location of the new local group. The local group is moved to the new location. To copy (instead of move) the original
group, press <Ctrl> while you drag the group.
By cutting or copying an existing local group from another location, and then pasting it into the current location. Expand
zones or computers to the zone where the original local group exists, right-click a local group and select C u t or C o p y, return to the zone where
you are creating the new local group, right-click, and select Paste.
By creating an entirely new local group. Perform Step 4 through Step 8 of this procedure.
4. In Local Groups, right-click, then click Create UNIX Group.
5. Type a name for the new local group and click O K.
6. In the Set UNIX Group Profile dialog, select or deselect check boxes to specify which attributes to set. You must specify at least one attribute to be able
to save the profile.
GID: Type a numeric group ID of your choice.
Members: Click A d d to launch the Add Members dialog. In a comma-separated list, type the UNIX names of the users who will be in the group.
Access Manager does not check the validity of the user names that you provide. You should ensure that all of the names that you provide are UNIX
names that currently exist.
Note that the group profile is considered complete even if this attribute has an empty value.
State: Specify whether the group account is added to, and enabled in, etc/group. Possible values are:
Enable: The group profile will be installed or updated in /etc/group at the next local account refresh interval.
Remove from /etc/group: The group profile will be removed from etc/group at the next local account refresh interval.
Note: To modify permissions for a local group, you must first

create and save the local group as described in this procedure, and then
modify permissions as described in Step 4 in the section(To modify group
profile attributes and permissions for a local group](https://docs.centrify.com/Content/auth-admin-unix/ProfilesGroupLocal.htm#modify_permissions_local_group).
For the profile to be complete, it must contain settings for group name (specified in Step 5 of the procedure To create a group profile for a local
group using Access Manager), GID, and state. You can save the profile now even if it is partial, although it will not be implemented in /etc/group
until you update it in the current zone, or with settings in child zones, so that it is complete, and you set the state to Enable. For example, if you use
the same group name but different numeric identifiers on two set of computers, you can inherit the group name from a parent zone and set the
different numeric identifiers in the child zones.
In the AIX Extended Attributes tab, you can view and set AIX attributes for the local group's zone profile. Click A d d to add an attribute and a
value, click Edit to change an attribute, or click Remove to remove an attribute from the group's zone profile.
7. Review your local group profile settings and click O K.
If the profile is complete, it is added to /etc/group at the next local account refresh interval.
8. To optionally assign the local listed role to the local group, so that all local users in the local group are visible in the zone:
1. At the level where you created the local group, right-click Role Assignments, and then select Assign Role.
2. In the Select Role dialog, select local listed and click O K.
3. In the Assign Role dialog, ensure that Accounts below is selected, and click Add Local Account.
4. In the Add Local Account dialog, select Local UNIX Group in the Type field, type the local group name in the Account field, and click O K.
5. In the Assign Role dialog Accounts below area, highlight the local group account and click O K. The local group is now listed as an assignee of the
local listed role.
To modify group profile attributes and permissions for a local group:
1. In Access Manager, expand UNIX Data for the zone or computer containing the local group that you want to modify.
2. In the Local Groups details pane, right-click the local group to modify and select Zone Profile.
The Properties dialog for the profile is displayed.
3. Modify attribute selections and settings as described in Step 6 in the procedure To create a group profile for a local group using Access Manager. Keep
in mind the following considerations when you change attributes.
If there is no parent profile for the same local group name:
You can edit profile fields to customize the value.
You can deselect profile fields to define a partial profile.
If a parent profile for the same local group name already exists in a parent zone:
You can deselect profile fields to inherit attribute values from the parent profile.
4. To optionally modify group permissions (such as read, write, create or delete child object, and so on), click Permissions. Refer to the “Active Directory
permissions required for administrative tasks” chapter in thePlanning and Deployment Guide for details about using the Permissions dialog to modify
zone-level user and group permissions.
5. Review your changes to the local group profile and click O K.
Your changes are applied to the local group profile in /etc/group at the next local account refresh interval.
To delete a group profile for a local group from a zone or computer:
Note: This procedure does not remove a local group profile from
/etc/group. To remove a local group profile from /etc/group, perform the
procedure described in [To remove a group profile for a local group from
/etc/group](https://docs.centrify.com/Content/auth-admin-unix/ProfilesGroupLocal.htm#remove_group_profile).
1. In Access Manager, expand UNIX Data for the zone or computer containing the local group that you want to delete.
2. In the Local Groups details pane, right-click the local group to modify and select Delete.
3. At the warning prompt, select Yes.
The local group is deleted from Access Manager. The group profile still exists in /etc/group, but it is ignored.
To remove a group profile for a local group from /etc/group
1. In Access Manager, expand UNIX Data for the zone or computer containing the local group that you want to remove from /etc/group.
2. Perform one of the following procedures:
Right-click a local group, select Change Profile State, then select Remove from /etc/group.
Right-click a local group, select Zone Profile, change the value of the State field to Remove from /etc/group, and click OK.
At the next local account refresh interval, the local group’s profile is removed from /etc/group.
Delegating control of local group management tasks
You can use the Zone Delegation Wizard and Computer Delegation Wizard as described in the Planning and Deployment Guide to delegate control of local
group management tasks.
Migrating Local Group Profiles to Active Directory
In most cases, you get more operational benefits by using Active Directory groups to manage UNIX and Linux user accounts than you would get from
migrating your local group profiles into Active Directory. For example, by using Active Directory groups to manage both Windows and UNIX users, you can use
your existing provisioning and access control policies across multiple platforms and automate the provisioning and de-provisioning of accounts and access
rules.
In some cases, however, you might find it useful to migrate some or all of your existing local groups to Active Directory. If you want to move local group
profiles into Active Directory, you have the option to import local groups on a zone-by-zone basis. As part of the import process, you can choose to how each
local group should be handled. For example, you can:
Create a new Active Directory group for each imported group.
Extend an existing Active Directory group to include an imported group.
Merge an imported group into an existing UNIX group profile.
Making Group Membership a Requirement
On most Linux and UNIX computers, users can only be members of a limited number of groups at once. Because of this limitation, it is useful to be able to
change a user’s effective group membership to add and remove groups when necessary. You can use the adsetgroups command to dynamically manage the
set of Active Directory groups that are available to a user account. You also have the option to specify that membership in a specific group is required in a
zone. If you specify that a group is required, users who are members of the group cannot remove the required group profile from their currently active set of
groups.
To make membership in a specific group profile required:
2. Expand Zones and any parent or child zones required to select the zone name for which you want to add a required group.
3. Expand Groups, then select the group name you want to make required.
4. Right-click, then select Zone Profile to display the Centrify UNIX Profile for the group.
5. Select the Users are required to be members of this group option.
6. Click Permissions to set specific permissions for this group, if needed, then click O K.
For more information about using the adsetgroups command, see the adsetgroups man page.
Creating User Profiles
You can create user profiles for Active Directory users and—in hierarchical zone environments—local users. A user profile consists of the attributes required
by the name service switch (NSS) facility on Linux and UNIX computers. User attributes that must be defined for the user profile to be complete are the
following:
A user name (the UNIX login name).
A unique numeric user identifier (UID).
The user's primary group profile numeric identifier (GID).
The default home directory for the user.
The default login shell for the user.
General information about the user account (GECOS). (This attribute is required for Active Directory user profiles, but not for local user profiles.)
A user must have a complete profile with all of these attributes defined to be recognized as a valid user in a zone or on a specific computer. You can optionally
define other attributes that are not required for the user profile to be complete.
These are the same attributes you define locally for Linux and UNIX users in the /etc/passwd file.
For details about creating profiles for Active Directory users, see Creating user profiles for Active Directory users. For details about creating profiles for local
Linux and UNIX groups, see Creating, modifying, and deleting user profiles for local users.
Creating user profiles for Active Directory users
You can create a user profile for any domain user you have defined in the Active Directory forest by adding the user to a zone, or by adding the user to a
specific computer in a zone. Associating a user profile with an Active Directory user determines how the Active Directory user is identified on Linux and UNIX
computers.
Note: You can automate the provisioning of user profiles through the use
of Active Directory groups. For information about configuring your environment
for automated provisioning, see the *Planning and Deployment Guide*.
What to do before creating a new Active Directory user profile
Before you can create Active Directory user profiles, you must have created one or more Active Directory users, installed Access Manager, and run the Setup
Wizard. You should also identify the computers where Active Directory users might require different profile attributes. For example, you might have some
Active Directory users that require the default home directory attribute to be set the to /home for access to most computers, but require the attribute to be
set to /Users when they log on to Mac OS X computers.
In most organizations, Active Directory users have one “dominant” profile with consistent attributes across multiple computers, but require “override”
settings to some profile attributes on specific computers or groups of computers. Therefore, most user profiles are only added to parent zones and inherited
in child zones.
You must have permission to add users to a zone. Zone administrators can grant this permission through the Zone Delegation Wizard. If the Active Directory
administrator manually sets the permissions, your user account must be a domain user with the following permissions to create user profiles in a zone:
On the Object tab, select Allow to apply the following permission to this object only: Create serviceConnectionPoint
Parent container object for the Objects This permission is required for both standard zones and RFC 2307compliant zones. For standard zones, you need
user profile to apply additional permissions. Click the Properties tab and select serviceConnectionPoint objects from the
object list, then select Allow to apply the following properties to this object: Read Name Read name Read displayName
User account object in Active

Click the Properties tab and select Allow to apply the following properties to this object only: Read objectCategory
Directory For example:
Read objectClass Read objectGUID Read objectSid Read userAccountControl
domain/Users/user_name
Parent container object for the

individual zone For example, if
Click the Properties tab and select Allow to apply the following properties to this object only: Read objectGUID Write
you are adding a user to the
Description
Finance zone:
A Windows domain administrator performs this task, depending on your organization's policies. In most organizations, this task is delegated to a specific user
or group with administrative authority in the selected zone.
In most cases, you create and remove user profiles frequently to address changes to your user population.
The following instructions illustrate one way to create a new user profile using Access Manager. You can also add a user profile and assign a role to an Active
Directory user with the Add User wizard. Examples of scripts that use ADEdit, Windows PowerShell, or the Windows API are available in other guides, the
Centrify Software Developer's Kit, or in community forums on the Centrify website.
To create a user profile for an Active Directory user using Access Manager:
2. Expand Zones and any parent or child zones required to select the zone name to which you want to add the Active Directory group.
In most cases, you should add user profiles to a parent zone.
3. Expand UNIX Data and select Users, right-click, then click Add User to Zone.
4. Type a search string to locate the user account, then click Find Now.
For example, type “qa” to display the qa-lab, qa-hk and qaVenice1x users.
5. Select one or more users in the results, then click O K.
6. Review the default zone profile settings for the user and make any changes if needed, then click O K.
You can deselect an attribute to change the default value or to create a partial user profile in the current zone. You can then complete the profile by
providing a value for an attribute in a child zone of the current zone. For example, if you use the same login name but different numeric identifiers on two
set of computers, you can inherit the login name from a parent zone and set the different numeric identifiers in the child zones.
In the AIX Extended Attributes tab, you can view and set AIX attributes for the user's zone profile. Click A d d to add an attribute and a value, click
Edit to change an attribute, or click Remove to remove an attribute from the user's zone profile.
If you selected more than one user, review the profile settings for the each user and modify the default settings, if necessary, then click O K.
Changing the default profile attributes
When you add Active Directory users to a zone, Access Manager displays a default new user profile. You can accept or change the default values for any of
the profile attributes, as needed. The default attribute values are automatically generated based on a few simple rules and, in most cases, you can accept
them as-is. The following table describes how the default values are populated.
This
Has the following default value
attribute
Login name The Active Directory user logon name associated with the Active Directory account.
This
Has the following default value
attribute
UID A unique number automatically generated by an algorithm based on the security identifier (SID) for the Active Directory user.
Primary A unique numeric identifier that represents a private primary group and is the same as the user's default UID. Private groups are not stored or
group managed in Active Directory.
GECOS A runtime variable that resolves to the Active Directory displayName attribute associated with the Active Directory account.
Home
A runtime variable that specifies the default home directory when resolved locally on a computer.
directory
A runtime variable that specifies the default login shell when resolved locally on a computer. To set the user's shell to the default shell
Shell
defined for this computer in this zone.
Defining partial UNIX profiles
Access Manager allows you to create a partial profile by leaving any of the attributes blank. Partial profiles can be useful for defining a common set of
specific computers. For example, you could leave the Shell attribute blank in a parent zone, define it as /bin/bash in a child zone, but override it with
/usr/bin/ksh in a grandchild zone that only contains AIX computers. You could also leave the Home directory attribute blank in a parent zone, then set it to
/home in one child zone and to /Users on an individual Mac OS X computer that joins the child zone.
If you intend to leave an attribute blank, deselect the attribute check box. However, you must provide a value for at least one attribute to add the user profile.
Users must have a complete profile in a zone for any role assignments to be effective. Keep in mind, however, that users can have an incomplete profile in a
parent zone as long as any missing attributes are defined in a child zone to allow role assignments in the child zone.
Defining valid login names
User profile login names can consist of letters, numbers, hyphens, underscores, periods and dashes. Some operating environments may have additional
restrictions. For example, some operating environments do not support user names that are longer than 8 characters or require that the first character of the
user name be alphabetic. Because UNIX user names typically use only lowercase characters, the default user profile name displayed follows this convention.
If you modify the default profile name and include uppercase characters, keep in mind that the proper case must be used when entering the user name. For
compatibility with Samba, the dollar sign ($) can also be used at the end of the user name. In general, other special characters, such as ! and &, are not
supported.
If the Windows logon name includes unsupported special characters, Access Manager replaces them with underscores for the UNIX login name. For example,
Access Manager converts a Windows logon name with special characters, such as qa:user2 into a valid UNIX login name of qa_user2.
Identifying a primary group
In most UNIX environments, a user's primary group identifier (GID) is a “private” group that exists solely for that user. The user is not included as a “member”
of the private primary group. You can follow this convention by using a UNIX-only “private” group that is not linked to an Active Directory group, which is the
default when you create a new user profile.
If you keep the default private primary group, the primary group identifier (GID) setting in the user profile does not affect the user's actual Active Directory
group membership in any way, and there's no need to manage primary groups for UNIX users through Active Directory.
In some cases, however, you might want to assign an Active Directory group that has a corresponding group profile as a user's primary group. If you specify an
Active Directory group as a user's primary group, keep in mind that you must manage the membership of that group using Active Directory Users and
Computers and that if you identify a group with a large number of members—such as Domain Users—it is likely to affect performance.
For more information about defining primary groups for users, see the Planning and Deployment Guide.
Creating, modifying, and deleting user profiles for local users
When you create a local user profile in Access Manager, it is saved in /etc/passwd on each computer in each zone where the profile is defined. You can create
local profiles at the zone level (for example, under Zones > Zonename > UNIX Data) and at the computer level (for example, under Zones > Zonename >
Computers > Computername > UNIX Data).
After you create local user profiles, you perform a separate set of tasks to create and manage local user passwords. For detailed information about local user
passwords, see Creating and managing local user passwords.
What to do before creating a new local user profile
You should perform the following tasks before creating local user profiles:
Ensure that local account management is enabled and configured through configuration parameters or group policies. See Enabling and configuring
local account management for more information.
It is suggested that you review the existing user names in etc/passwd on the computers where the local user profile will be implemented so that you do
not attempt to create a user profile with a name that is already used. Access Manager performs a name validation check against etc/passwd in the
current zone when you create a new local user. If the user name already exists in etc/passwd somewhere in the current zone, you are prompted to
provide a different name for the user that you are creating.
The rights required to create local user profiles are the same as the rights required to create Active Directory user profiles. See Rights required for this task
for details about those rights.
Using partial profiles and child zones to fine tune user attributes
Access Manager allows you to create a partial profile by leaving some user attributes blank. Partial profiles can be useful for defining a common set of
specific computers. For example, you could leave the Shell attribute blank in a parent zone, define it as /bin/bash in a child zone, but override it with
/usr/bin/ksh in a grandchild zone that only contains AIX computers.
If you intend to leave an attribute blank, deselect the attribute check box. However, you must provide a value for at least one attribute to create the user
profile.
Users can have an incomplete profile in a parent zone as long as any missing attributes are defined in a child zone. If a user profile is still partial at the
computer level, the profile is ignored by the agent, and it is not added to /etc/passwd on the local computer. User profiles must contain the attributes listed in
Creating user profiles to be complete.
Specifying profile states
The profile state lets you control whether a local user account is in place in etc/passwd and is enabled for use locally. When you create a local user account,
you specify the initial profile state. You can change the profile state afterwards to control availability of the local user account. A local user account can have
one of the following states:
Enable: If the user profile is complete, it will be installed or updated in /etc/passwd at the next local account refresh interval. The user can log into the
local computer, and is visible in Access Manager if a role with the visible right (such as local listed) is granted to the user. See Roles and local user
account visibility for more information about how roles affect local user visibility.
Disable: If the user profile is complete, it will be installed or updated in /etc/passwd at the next local account refresh interval. However, the user will not
be able to log into the local computer. This state results in what is typically called a “locked account.” UNIX and Linux service accounts and system
accounts are typically set up as locked accounts.
Remove from /etc/passwd: The user profile will be removed from etc/passwd at the next local account refresh interval.
You can also choose not to define the profile state by deselecting the State check box in the Set Local User Profile dialog. Deselecting the State check box
results in one of the following scenarios:
If a local user profile with the same name exists in the parent zone, the state from the parent user profile is inherited.
If the parent zone does not contain a user profile with the same name, or if a parent user profile exists but does not define the state, the user profile that
you are currently defining is considered incomplete.
Roles and local user account visibility
You use role assignments to control whether local users are visible in a zone. A predefined role definition, local listed, is available for use with local user and
local group profiles. As with the listed predefined role, the local listed role does not grant any system rights, PAM rights, or command rights. It is a specialized
role that can be used when a local user profile must exist for computers in a zone, but no local user access should be granted.
You can optionally define other roles in the zone to grant visibility to local users.
As with role assignments for Active Directory users, local user role assignments can be made at the zone level, computer level, or computer role level. Use the
following guidelines to establish where local users are visible in Access Manager:
To make a local user visible to all computers in a zone, assign the local listed role to the local user account (or to all local UNIX accounts) in the zone (for
example, assign local listed to users located in Zones > Zonename > UNIX Data > Local Users).
To make a local user visible only to a specific computer, assign the local listed role to the local user account (or to all local UNIX accounts) located in the
computer zone (for example, assign local listed to users located in Zones > Zonename > Computers > Computername > UNIX Data > Local
Users).
To make a local user visible only to a group of computers, create a computer role and assign the local listed role to the local user account (or to all local
UNIX accounts) in the computer role.
How often Access Manager and local user accounts are synchronized
The /etc/passwd file on local computers is updated periodically based on the information that you define for local user profiles in Access Manager. The
/etc/passwd update interval is controlled by the following group policy and configuration parameter:
Group Policy: Set refresh interval for access control cache, located in Computer Configuration > Centrify Settings > DirectControl Settings >
Network and Cache Settings.
Configuration parameter: adclient.refresh.interval.dz, located in the /etc/centrifydc/centrifydc.conf configuration file.
These are the same group policy and parameter that control how often the authorization store cache is updated. Local account information is updated
immediately after authorization store information is refreshed in the authorization cache.
For more information, see Enabling and configuring local account management of this guide. For additional group policy and configuration parameter
information, see the Group Policy Guide, and the Configuration and Tuning Reference Guide.
To create a user profile for a local user using Access Manager, Method 1
Note: This method begins from the Local Users node, and allows you to
assign just one role, local listed, to the local user. To use the Add User to
Zone wizard, which lets you assign other roles to the local user, see [To create
a user profile for a local user using Access Manager, Method 2](https://docs.centrify.com/Content/auth-admin-unix/ProfilesCreatingLocal.htm#user_profile_method_2).
2. Expand Zones and any parent zones, child zones, or computers required to select the zone or computer to which you want to add the local user.
3. Expand UNIX Data and select Local Users.
You can create a new local user in these ways:
By dragging and dropping an existing local user from another location. Expand zones or computers to the location of the original
local user, and drag it to the location of the new local user. The local user is moved to the new location, and no longer exists in the original location.
To copy the original user to the new location and also retain it in the original location, press <Ctrl> while you drag the user.
By cutting or copying an existing local user from another location, and then pasting it into the current location. Expand
zones or computers to the zone where the original local user exists, right-click a local user and select C u t or C o p y, return to the zone where you
are creating the new local user, right-click, and select Paste.
By creating an entirely new local user. Perform Step 4 through Step 8 of this procedure.
4. In Local Users, right-click, then click Add User to Zone.
5. Type a name for the new local user and click O K.
6. In the Set UNIX User Profile dialog, select or deselect check boxes to specify which attributes to set. You must specify at least one attribute to be able to
save the profile.
If a parent profile for the same local user name already exists in a parent zone, some attribute fields will be filled in already with inherited values. You can
edit profile fields to customize inherited values, and you can deselect other profile fields to inherit attribute values from the parent profile.
UID: Type a numeric user ID of your choice.
Primary group: From the drop-down list, select an existing group, or select <Not defined> to leave the PGID attribute undefined, or select
<...> to see additional group choices or to create a new local group.
To create a new local group after clicking <...>, click A d d in the Select a Group dialog, and follow the procedure for creating a new local group
starting with Step 5 in the section To create a group profile for a local group using Access Manager.
GECOS: Optionally type general information of your choice about the local user account. This attribute is not required for the profile to be
complete.
Home directory: Type the default local computer home directory for the local user.
Shell: Select the default shell for the local user. Choices are /bin/bash, /bin/csh, /bin/ksh, /bin/sh, /bin/tcsh, %.
State: Specify whether the local user account is added and enabled in /etc/passwd. Choices are as follows.
Enable: If the user profile is complete, it will be installed or updated in /etc/passwd at the next local account refresh interval. The user will
be able to log into the local computer, and the user is visible in Access Manager.
Disable: If the user profile is complete, it will be installed or updated in /etc/passwd at the next local account refresh interval. However, the
password field in /etc/passwd will be set to !!, and the user will not be able to log into the local computer. This state results in what is typically
called a “locked account.” The user is still visible in the zone as long as the local listed role is assigned to the user.
Remove from /etc/passwd: The user profile will be removed from etc/passwd at the next local account refresh interval.
For the profile to be complete, it must contain the attributes listed in Creating user profiles. You can save the profile even if it is partial,
although it will not be implemented in /etc/passwd until you update it in the current zone, or with settings in child zones, so that it is
complete, and you set the state to enabled. For example, if you use the same user name but different numeric identifiers on two set of
computers, you can inherit the user name from a parent zone and set the different numeric identifiers in the child zones.
In the AIX Extended Attributes tab, you can view and set AIX attributes for the local user's zone profile. Click A d d to add an attribute and
a value, click Edit to change an attribute, or click Remove to remove an attribute from the user's zone profile.
Note: To modify permissions for a local user, you must first

create and save the local user as described in this procedure, and
then modify permissions as described in [To modify user profile
attributes and permissions for a local user](https://docs.centrify.com/Content/auth-admin-unix/ProfilesCreatingLocal.htm#modify_profile_attributes).
7. By default, new local users are assigned the local listed role so that local users are visible in Access Manager. This assignment is specified in the Assign
local listed role to make this user visible check box. To keep this default assignment, ensure that the check box remains selected.
To give the local user a different role assignment, deselect the check box. If you deselect the check box, you will need to manually assign a role with
visible rights to the local user after completing this procedure.
8. Review your attribute selections and settings, and click O K. If the user profile is complete, it is added to /etc/passwd at the next local account refresh
interval.
To create a user profile for a local user using Access Manager, Method 2
Note: This method describes how to create a local user profile using the
Add User to Zone wizard, which lets you assign roles other than just local
listed to the local user.
2. Expand Zones and any parent zones, child zones, or computers required to select the zone to which you want to add the local user.
3. Right-click the zone, and select Add User.
The Add User to Zone wizard launches.
4. In the Select User Type dialog, select Local UNIX user, and click Next.
5. In the Specify Local UNIX User dialog, type a name for the local user, and click Next.
6. In the Add User to Zone dialog, select the Define user UNIX profile and Assign roles check boxes. Click Next.
7. Fill in the local users profile attribute settings in the Define User UNIX Profile dialog as described in Step 6 in the section To create a user profile for a
local user using Access Manager, Method 1, and click Next.
8. In the Assign Roles dialog, the local listed role is included by default. To optionally add different roles as choices, click A d d and select one or more roles
to add to the list.
9. In The Assign Roles dialog, select one or more roles, and click Next.
10. In the Confirm Your Selections dialog, review your choices and click Next.
11. In the final wizard screen, click Finish.
12. Confirm that the new local user was created by expanding UNIX Data in the zone and clicking Local Users. The new local user should be listed in the
user details pane.
To modify user profile attributes and permissions for a local user:
1. In Access Manager, expand UNIX Data for the zone or computer containing the local user that you want to modify.
2. In the Local User details pane, right-click the local user to modify and select Zone Profile.
The Properties dialog for the profile is displayed.
3. Modify attribute selections and settings as described in Step 6 in the section To create a user profile for a local user using Access Manager, Method 1.
Keep in mind the following considerations when you change attributes.
If there is no parent profile for the same local user name:
You can deselect profile fields to define a partial profile.
If a parent profile for the same local user name already exists in a parent zone:
You can deselect profile fields to inherit attribute values from the parent profile.
4. To optionally modify user permissions (such as read, write, create or delete child object, and so on), click Permissions. Refer to the “Active Directory
permissions required for administrative tasks” chapter in the Planning and Deployment Guide for details about using the Permissions dialog to modify
zone-level user and group permissions.
5. Review your changes to the local user profile and click O K.
Your changes are applied to the local user profile in /etc/passwd at the next local account refresh interval.
To disable a user profile for a local user:
Note: This procedure does not remove a local user profile from /etc/passwd. To remove a local user profile from /etc/passwd, perform the procedure
described in To remove a user profile for a local user from /etc/passwd.
1. In Access Manager, expand UNIX Data for the zone or computer containing the local user that you want to disable.
2. In the Local Users details pane, right-click the local user and select Change Profile State.
3. Select Disable.
The local user remains visible in Access Manager. At the next local account refresh interval, the local user's profile in /etc/passwd is modified so that
the password field contains !!, and the user cannot log into the local computer.
To delete a local user from a zone
Note: This procedure does not remove a local user profile from /etc/passwd. To remove a local user profile from /etc/passwd, perform the procedure
described in “To remove a user profile for a local user from /etc/passwd before you delete the local user from the zone.
1. In Access Manager, expand UNIX Data for the zone or computer containing the local user that you want to delete from the zone.
2. In the Local Users details pane, right-click the local user and select Delete.
3. In the confirmation dialog, select Yes to delete the user from the zone. To prevent the confirmation dialog from displaying in the future, select Do not
warn me again.
4. In the next confirmation dialog, select Yes.
The user is removed from zone, and is no longer controlled through Access Manager. However, the user profile remains in /etc/passwd on local
computers.
To remove a user profile for a local user from /etc/passwd
1. In Access Manager, expand UNIX Data for the zone or computer containing the local user that you want to remove.
2. In the Local Users details pane, right-click the local user and select Change Profile State.
3. Perform one of the following procedures:
Right-click the local user, select Change Profile State, then select Remove from /etc/passwd.
Right-click the local user, select Zone Profile, change the value of the State field to Remove from /etc/passwd, and click OK.
At the next local account refresh interval, the local user's profile is removed from /etc/passwd.
Delegating control of local user management tasks
You can use the Zone Delegation Wizard and Computer Delegation Wizard as described in the Planning and Deployment Guide to delegate control of local
user management tasks.
Creating and managing local user passwords
After you create local user profiles as described in the preceding sections, you still need to assign a password to each user. You can create local user
passwords in one of these ways:
By creating a shell script to execute the passwd command on each local computer, giving each local user the password that you specify in the script.
The shell script can be executed manually, or by enabling adclient.local.account.notification.cli to run the script automatically when local accounts are
refreshed. This is the least secure way to assign passwords to local users, because the same password is assigned to each user when the script runs.
After the script runs, you must change passwords locally so that each password is unique.
This guide does not include detailed instructions for implementing this method of creating local user passwords.
If your environment contains a third-party password management product, you can create a shell script that executes on each local computer, giving
each local user a random password. The shell script can include a section that submits the passwords to the password management product for
storage and maintenance. The shell script can be executed manually, or by enabling adclient.local.account.notification.cli to run the script
automatically when local accounts are refreshed.
A sample shell script, handle_local_accts.sh, is provided in /usr/share/centrifydc/samples/localacctmgmt for you to use as a reference when you
create your own shell script. Typically, the shell script that you create should perform the following tasks:
Assign a random password to newly provisioned local users, and to local users whose accounts were recently unlocked (that is, re-enabled after
having been disabled).
Optionally create a home directory for each new local user.
Provide the user account information, including the generated passwords, to a third-party password management solution.
For syntax details about the notification CLI, execute the sample script with the -h option:
handle_local_accts.sh -h
If your environment does not contain a third-party password management product and you want to create and maintain unique passwords for each
local user, you can use Server Suite to manage local user passwords.
Using Server Suite to manage local user passwords involves these tasks:
Register for Server Suite.
Download the Centrify Agent for Linux software package.
On each UNIX and Linux computer where you will assign passwords to local users, execute the cenroll command to register the computer as a
managed resource.
Create a shell script that executes on each local computer, giving each local user a random password. The shell script should include commands
to manage generated passwords. The agent package includes a sample shell script that you can use as a reference when you create your own
shell script.
Enable the adclient.local.account.notification.cli configuration parameter to run the shell script automatically when local accounts are refreshed.
Setting Runtime Variables in User Profiles
Access Manager maintains a set of predefined runtime variables that you can use in place of specific values in Active Directory user profiles and local user
profiles. Using the variables simplifies the process of defining profile attributes. The Centrify Agent for *NIX resolves the runtime variables defined in a profile
with appropriate values when a computer joins a domain and zone.
The predefined runtime variables you can use in profiles are:
Use this
To specify this
variable
% The domain to which the computer is joined.
The root home directory. By default, this directory is /home on most Linux and UNIX computers. For Mac OS X computers, the default home
%
directory is /Users. On Solaris computers, the default home directory is /export/home).
% The host name of the joined computer.
The default login shell for the user. By default, the shell is /bin/bash on most Linux and UNIX computers. On Solaris and HP computers, the
%
default shell is /bin/sh. On AIX computers, the default shell is /usr/bin/ksh.
% The Active Directory site of the joined computer.
% The user’s UNIX login name. Note: This variable is supported only for Active Directory users. It is not supported for local users.
% The zone to which the computer is joined.
You can use these predefined runtime variables or custom variables at any point in the zone hierarchy, including a parent zone, a child zone, or on individual
computers. At runtime, the adclient process resolves the variables based on how the following configuration parameters are set and where the variables are
defined in the zone hierarchy:
nss.runtime.defaultvalue.var.variableName
These parameters — one for each predefined variable — defines the default value for each parameter as shown in the table. These are the values are
used if the variable is not explicitly defined in the zone or by the nss.runtime.var.variableName parameter in the configuration file. For example:
nss.runtime.defaultvalue.var.home: /home
nss.runtime.defaultvalue.var.shell: /bin/bash
nss.runtime.var.variableName
These parameters allow you to specify a specific value for any of the predefined variables in the configuration file. The value in the configuration file is
essentially a computerspecific override because it applies only to the computer on which it is defined and overrides any other setting for the variable,
including the default value, or a specific value in a zone Properties page. For example:
nss.runtime.var.home: /Users
nss.runtime.var.shell: /bin/sh
To override the default definition for any predefined variable in a zone, you can simply add a variable with the same name to the zone by using the zone
Properties page or by using ADEdit. Zone variables and zone variable definitions are inherited down the profile tree, which means that a variable could have
one definition at the top of the tree and a different definition at the bottom. The value that is applied depends at which level of the zone hierarchy a computer
joins the domain.
To define values for predefined variables in a parent or child zone:
2. Expand Zones and any parent or child zones required to select the zone name in which you want to override a profile attribute.
For example, if you want to override the default login shell in the child zone that only AIX computers join, you might expand Child Zones to view and
select the IBM AIX Only zone.
3. Select the zone, right-click, then click Properties.
4. Click the Variables tab, then click A d d.
5. Type the name of the predefined variable and the custom value you want to use, then click O K to save the variable definition.
For example, type shell and set the value to /usr/bin/ksh to modify the default shell definition.
6. Click O K to close the zone properties.
Using Active Directory attributes as variables
You can also use any Active Directory user attributes as variables by specifying the attribute name in the following format:
For example, if you want to populate the GECOS field of a user’s zone profile with the information from the user’s department attribute, you could specify the
variable as follows:
By default, only a subset of common user object attributes can be retrieved and resolved by the adclient process. The default set of attributes you can use in
a user profile are:
mail
department
description
mobile
title
telephoneNumber
The most common format for the GECOS field in a user profile contains the user's full name, building number, and office phone number separated by
commas. Depending on the operating system and desktop manager you are using, the information from the GECOS field might also be used to display the
user name when logging on. If you specify an attribute for the GECOS field that includes a comma, you might see the first part of the attribute treated as the
user's full name and displayed in the login screen. For example, if you are using the department attribute in the GECOS field and the attribute is defined as
“Cendura, San Francisco, Engineering, 25th floor, office 202”, you might see Cendura listed as a user on the login screen.
Using other attributes in a profile
The default user attributes are recognized by adclient without requiring any modification to the managed computer or Active Directory. If you want to use any
other attribute, whether it is a standard schema attribute like company or homePhone or a custom attribute that you have added to the Active Directory
schema such as supervisorId, you must add an entry for the attribute to the adclient.custom.attributes.user parameter in centrifydc.conf file, then restart
adclient and flush the cache.
For example, you might add the following attributes to the centrifydc.conf file:
adclient.custom.attributes.user: company supervisorId
After modifying the file, you would run the following commands to restart the agent and clear the cache:
/usr/share/centrifydc/bin/centrifydcrestart
adflush -f
For more information about defining custom attributes, see the Configuration and Tuning Reference Guide.
Attributes for users in a forest with a one-way trust
Keep in mind when using attribute variables that if you add users to a zone from a oneway trusted forest, the Centrify Agent will only be able to retrieve values
for the userPrincipalName and samAccountName attributes. Therefore, at runtime, when the adclient process resolves variable definitions, fields that
contain any other variables will be blank for a user from a one-way trusted forest.
Adding custom variables to a zone
You can also create your own variables at any point in the zone hierarchy, including a parent zone, a child zone, or on individual computers. You can add
custom variable names and values in exactly the same way you define new values for the predefined runtime variables, except that you type a custom
variable name and value.
Importing Local Account Profiles
Most organizations have at least some local user and group profiles that must be migrated to Active Directory. Access Manager provides an Import from UNIX
wizard that enables you to import user and group profiles from local /etc/passwd and /etc/group files or from NIS servers and domains.
If you are not migrating any local account profiles, you can skip this section. However, if you have a large or complex user population to migrate, you should
use the information in this section along with the Planning and Deployment Guide for a more complete view of the migration process and analysis
requirement.
Collecting account information
Before using the Import from UNIX wizard, you should do the following to prepare:
Identify each source of user information and analyze the information to determine your zone requirements.
Run appropriate commands—such as getent passwd, getent group, or niscat—to export user and group information and save it in properly-formatted
text files.
Copy the text files to a location that is accessible from the Windows network. If you want to import information directly from NIS maps instead of text
files, you should verify that you can access NIS servers and domains from the Windows network.
Review the text files entries to remove account entries that don’t need to be mapped to Active Directory accounts.
You can automatically exclude system accounts with UID or GID values from 0 to 99 during the import process, but you might want to remove other
accounts prior to the import. As part of the review process, determine which entries should map to existing Active Directory accounts or which entries
require new Active Directory objects.
Using variables when importing UNIX users
When you import UNIX user accounts, you can use a variable in the GECOS field so that Active Directory will automatically populate that information. The
variable you can use is as follows:
For example: In your /etc/passwd file, you have the following information for a user:
ron:x:10061:10061:%:/home/ron:/bin/bash
After you import the user with the UNIX import user wizard, the following user is in the pending import area:
UID: 10061
Login name: ron
Shell: /bin/bash
Home directory: /home/ron
Primary Group: 10061
GECOS: %
After you map this pending user to a user account in Active Directory, the % text is converted to the user's display name at runtime by adclient. When you view
the user profile in Active Directory or Access Manager, you'll see the % text in the GECOS field; when you query the user from a UNIX computer using
something such as adquery or getpwent, you'll see the actual user display name in the GECOS field.
Using the Import from UNIX wizard
After you have created text files with user and group information or verified access to a NIS server and domain, you are ready to perform the first step in the
migration process using the Import from UNIX wizard.
To import user and group information:
2. Expand Zones and any parent or child zones required to select the zone name into which you want to import users and groups.
3. Select UNIX Data, right-click, then click Import from UNIX.
4. Select the import source, then click Next.
If you select Network Information Service (NIS), type the name of the NIS domain and the host name of the NIS server. The NIS domain and server
must be accessible from the Windows network for information to be imported successfully.
If you select UNIX configuration files, click Browse to locate the text files to import.
If you selected Network Information Service or UNIX configuration files in Step 4, go to Step 5.
5. Select the import options you want to use, then click Next.
The import options displayed depend on the import source. For example, if you selected UNIX configuration files and specified a text file containing user
accounts and a text file containing group accounts, the import options are:
Include system accounts to include accounts with UID or GID values from 0 to 99.
On most computers, accounts with UID or GID values from 0 to 99 are reserved for accounts, such as root, tty, and ftp that you don’t need to
import or manage using Active Directory. Select the Include system accounts option to include these accounts. This option is only displayed if
importing from UNIX configuration files.
Automatically shorten the UNIX name to 8 characters to limit UNIX user and group names to a maximum of 8 characters.
On some computers, user and group names cannot be longer than 8 characters. If you are importing users and groups that might need access to
computers that do not support names longer than 8 characters, you can select Automatically shorten the Unix name to 8 characters to
automatically truncate the names imported.
If you are importing from NIS, you can choose to import users, groups, or both.
6. Select a location for storing pending import data, then click Next.
For example, to store pending data for the current zone in an XML file, select Store in XML file and specify the location for the file. If the file does not
already exist in the default location, you are prompted to create it. To select another location for the XML file, click Browse.
7. Review the summary of information to be imported, and select the Check data conflicts while importing option if you want to check for conflicts
and potential matching candidates during the import process, then click Finish.
If you are importing a large number of users or groups, selecting Check data conflicts while importing can cause the import process to take some
time to complete. If you don’t select this option, you must check the status of users or groups after importing.
After you close the Import from UNIX wizard, users and groups are placed in Active Directory or in an XML file with the status of Pending Import. You must then
decide how each user and group should be mapped to accounts in Active Directory.
Checking for conflicts and matching candidates
To move a user or group from Pending Import to a UNIX profile attached to an Active Directory user or group, you must first check for potential conflicts and
for potential matching user or group candidates in Active Directory. If you selected the Check data conflicts while importing option in the Import from
UNIX wizard, you have already completed this step and can continue to Mapping UNIX profiles to Active Directory accounts.
To check the status of pending information:
2. Expand Zones and any parent or child zones required to select the zone name into which you imported users and groups.
3. Expand UNIX Data, then expand Groups and Users to see the Pending Import nodes.
For example, if you imported information for the “Finance” zone, open that zone, expand UNIX Data, then expand Groups and Users.
4. Select Pending Import to display the list of users or groups to be imported.
For example:
Pending import
5. Select all or a subset of pending import users or groups, right-click, then click Check status.
For pending import groups, a potential match is an Active Directory group with a common name or sAMAccountName that is the same as the
pending import group name.
For pending import users, a potential match is an Active Directory user with a common name that is the same as the pending import user’s GECOS
field, or sAMAccountName that is the same as the UNIX user name.
If there is a match, Access Manager displays that group or user as the default Active Directory candidate and the status as Ready to import.
If Access Manager can’t identify a potential match in Active Directory or there are other issues, the status for the pending import group or user
describes the issue encountered.
Mapping UNIX profiles to Active Directory accounts
After you check the status of pending import groups or users, you can map the pending import group or user to an Active Directory group or user. The actions
you can take depend on the object you select and its current state. For example, if you select a pending group, you can choose to:
Accept the default Active Directory candidate for the selected group if a candidate is identified.
Create a new Active Directory group and attach the selected UNIX group profile to it.
Extend an existing Active Directory group to include the selected UNIX group profile.
Merge the members of the selected UNIX group with an existing UNIX group in Active Directory.
Delete the selected UNIX group.
View and modify the properties of the selected UNIX group.
Accepting the Active Directory candidate
If Access Manager finds a potential match for the pending import group or user in Active Directory, it displays the matching candidate in the details pane. You
can accept the suggested candidate by right-clicking the pending import group or user, then selecting Accept. After you accept the Active Directory
candidate for a pending group or user, the group or user is removed from the Pending Import list.
If all of the pending import group members have an Active Directory candidate associated with them, they are added as members of the Active Directory
group. However, the group will remain in the Pending Import list until all of its members are successfully mapped to Active Directory users or removed as
members.
Creating a new Active Directory account
If Access Manager did not find a potential match in Active Directory, you must determine whether the pending import group or user should be mapped to an
existing Active Directory account or requires a new Active Directory account. If the pending group or user requires a new Active Directory account, right-click
the pending group or user, then select the Create new option to open the wizard for creating a new Active Directory group or a new Active Directory user.
Follow the prompts displayed in the wizard to provide the additional information needed to create the group or user account.
Adding a profile to an existing Active Directory account
If Access Manager did not find a potential match in Active Directory but an appropriate Active Directory account exists, you must map the pending import
group or user to the appropriate Active Directory group or user. If the pending import profile should be added to an existing Active Directory group or user,
right-click the pending group or user, then select the Extend existing option to open the wizard for adding a UNIX profile to an existing Active Directory
group or existing Active Directory user.
Merging pending group members into an existing group
If Access Manager did not find a potential match for a Pending Import group in Active Directory, you might want to merge the members of the Pending Import
group into a group that already has a UNIX profile in the zone. If you want to add the members of a selected pending import group to an existing group profile,
right-click the pending import group, then select the Merge into existing Unix group option to open the wizard for merging the membership of a pending
import group with the membership of an existing UNIX group.
Deleting a UNIX profile for a pending group or user
If there are no suitable candidates to map a pending import group or user, you might want to remove a pending group or user from the Pending Import list. If
you want to delete a pending import group or user, you can do so by right-clicking the pending import group or user, then selecting the Delete option.
Viewing or modifying properties for a pending group or user
If there are conflicts between a pending import profile and information in Active Directory, you might need to modify the properties associated with the
pending import profile before you can take any other action. If you want to view or modify the properties for a pending import group or user, right-click the
pending import group or user, then select Properties.
If you select a pending group, the properties include the UNIX profile, the time of the import, the file location the information was imported from, the members
of the group, and the status of the group.
If you select a pending user, the properties include the UNIX profile, the time of the import, the file location the information was imported from, and the status
of the user.
Resolving errors and conflicts
In some cases, you might encounter errors ( Error ) that must be resolved before a pending import user or group can be migrated into Active Directory. For
example, pending import groups cannot be imported if the group profile has any of the following problems:
The group’s GID is negative.
There is another UNIX group with the same GID already defined in the zone.
There is a UNIX group with the same group name already defined in the zone.
The matching Active Directory candidate already has a UNIX profile in the zone.
Similarly, pending import users cannot be imported if the user profile has any of the following problems:
The user’s UID is negative.
The user’s primary group GID is negative.
There is a UNIX user with the same user name already defined in the zone.
In most cases, you must resolve these issues by modifying the properties for the pending import profile. For example, assume you are importing a passwd file
that includes the UNIX user account pierre with the UID 1001, but there is already an UNIX profile in the zone with the UNIX name pierre and UID of 500. After
you check the status, the Pending Import list of users will indicate there is an error.
To resolve a conflict like this, you might select the pending import user, right-click, then select Properties to change the UNIX user name from pierre to
another name, such as pierre2. You should keep in mind, however, that conflicts like this might require investigation to determine the appropriate course of
action. For example, if you are attempting to import the UNIX profile for the user pierre and there’s a conflict, you need to determine whether pierre with the
UID of 1001 is the same person as pierre with a UID of 500 and where each UID is applicable. If both profiles are for one person accessing different computers,
you might simply need to define a computer-level override on the specific computer where the UID of 1001 is required. If the pending import user actually
refers to a different person, you might have to map the profile to a different Active Directory account or move the computer to a different zone.
Resolving warnings
Warning
In addition to the errors that prevent users or groups from being imported, there are several conditions that generate a warning ( ). Warnings indicate
potential problems that you should try to resolve. After you check the status for pending import groups and users, the most common warning is “No matching
Active Directory candidate is found.” To continue, you must identify or create an Active Directory account for the pending import profile.
If you make changes to a pending import user or group to correct problems, you should click Check status after the change to check for any additional
issues that might need to be resolved.
Overriding and modifying user properties
If you are using hierarchical zones, user profile information is inherited from parent zones into any child zones you define. You can override the inherited
profile attributes at any time to create a new user profile in a specific child zone or on individual computers, if needed. Overriding profile attributes enables
you to migrate legacy local accounts without modifying any existing account information or file and directory ownership.
You can also modify either the user profile or the Active Directory user account properties for any user at any time using the tool of your choice. For example,
you can use Access Manager, the Access Module for Windows PowerShell, ADEdit, Active Directory Users and Computers, or the Centrify Windows API to
modify the zone profile or Active Directory properties for a selected user.
To override a profile attribute in a user profile:
2. Expand Zones and any parent or child zones required to select the zone name in which you want to override a profile attribute.
For example, if you want to override the default login shell in the child zone that only AIX computers join, you might expand Child Zones to view and
select the IBM AIX Only zone.
If you want to override a profile attribute for a specific computer, expand Computers to select the computer name on which you want to override the
profile attribute. For example, if you want to override the default numeric identifier for a user on the AIX computer aix6v0.ajax.org, you might expand the
IBM AIX Only child zone and the Computers node to view and select the aix6v0.ajax.org computer.
3. Expand UNIX Data for the zone or computer, then select Users.
4. Select the user, right-click, then select Zone Profile.
The profile displays the attributes inherited from the parent zone or currently set.
5. Select an attribute and provide the override value.
For example, select Shell and type /usr/bin/ksh to give the selected user profilea different default login shell—one appropriate for an AIX computer—in
the selected zone or on the selected computer.
6. Click O K to save the profile change.
Overriding and Modifying Group Properties
If you are using hierarchical zones, group profile information is inherited from parent zones into any child zones you define. You can override the inherited
profile attributes at any time to create a new group profile in a specific child zone or on individual computers, if needed.
You can also modify either the group profile or the Active Directory group properties for any group at any time using the tool of your choice. For example, you
can use Access Manager, the Access Module for Windows PowerShell, ADEdit, Active Directory Users and Computers, or the Centrify Windows API to modify
the zone profile or Active Directory properties for a selected group.
Adding Users or Groups from a Trusted Forest
In most cases, when you create a profile for a user or group in a zone, the Active Directory account already exists in the local Active Directory forest. You can,
however, also add profiles for remote users and groups to a zone without adding them to the local forest. If you have established a one-way or two-way trust
relationship with a remote or external Active Directory forest, you can add users and groups from that forest to a selected Centrify zone.
You add remote or external users and groups to the zone in the same way you add profiles for local Active Directory users and groups except that you must
select the remote forest or domain before searching for the user or group account. For example, at Step 4 of the procedure To create a group profile for an
Active Directory group using Access Manager, click Browse to select a trusted external forest or a specific domain in the trusted forest.
If you have defined a one-way or two-way trust between a local forest (wonder.land) and a remote forest (w2k3r2.dev), you can select the remote forest in
the Browse for container dialog box to add groups from that forest (w2k3r2.dev) to the currently selected zone.
Add groups from the forest
If you use attribute variables to define any part of the user profile, keep in mind that the Centrify Agent cannot directly read any of the attributes for a user
from a one-way trusted forest. The agent can retrieve the userPrincipalName and sAMAccountName from the zone profile for the user. However, the agent
cannot retrieve other user attributes. If the agent cannot resolve a variable in the user profile, the agent leaves the attribute value undefined. For example, if
you use the displayName variable to define the GECOS attribute, that attribute will be undefined for all users from an external forest with a one-way trust.
Identifying users from remote forests
You can identify the Active Directory users who have been added from a remote or external forest by checking the icon displayed in the Access Manager
console. If a user is added from a remote or external forest, the user name displays the following icon:
Remote or external forest
Valid login names for users from a remote forest
If you add users from an external forest to a zone, you should be aware that those users can only log on or be identified using the following information:
A valid UNIX profile name that has a complete set of profile attributes.
The full Active Directory user name including the user’s external forest domain name.
When users are defined in a local forest, they can be located in Active Directory by their UNIX profile name, their userPrincipalName, or their
sAMAccountName in the form of their user logon name alone or in the format of domainname\username, so any of these login name formats can be used to
access user information or to log on to a Centrify-managed computer.
To identify a user from a trusted external forest, however, you must use either the user’s UNIX profile name for the zone or the user’s sAMAccountName
followed by the user’s external domain name in the form of sAMAccountName@domainname. Using the UNIX profile name or the
sAMAccountName@domainname ensures the name is unique when there are cross-forest trust relationships. For example, if an Active Directory user from a
trusted external forest (sierra.org) has the Active Directory logon name of sofia.perez and a UNIX profile name of sofiapz, the user can be identified using:
sofia.perez@sierra.org
sofiapz
You cannot use sierra\sofia.perez or sofia.perez without the domain to retrieve information or authenticate from a remote forest. In addition, the
userPrincipalName (username@domainname) for any user might be different from the sAMAccountName@domainname. For example, if you use alternate
UPN suffixes, the domain name used in the userPrincipalName might be different from the domain name that uniquely identifies the user. Similarly, a user’s
logon name (sAMAccountName) might be different from the user name used in the userPrincipalName. For example, if the Active Directory user
sofia.perez@sierra.org has a user logon name of SIERRA\perez.s, that user would be found as perez.s@sierra.org.
Adding Multiple Profiles for a User to a Zone
It is possible for a single Active Directory user to have more than one UNIX profile defined in a zone. If you attempt to add a new UNIX profile for an Active
Directory account that already has a UNIX profile in the current zone, Access Manager displays a warning but allows you to continue.
If an Active Directory user has more than one UNIX profile in a zone, however, the user should log on to computers in the zone with the UNIX profile name he
wants to use. Logging on with the Active Directory user login name—the user’s sAMAccountName attribute—might prevent the user from accessing some
files because the account has multiple UNIX profiles and UIDs associated with it. ln most cases, users can log on with their Active Directory account name if
you have created parent and child hierarchical zones that address conflicting profile attributes. However, if you are using classic zones or hierarchical zones
that don’t address the need for multiple UNIX profiles, users might encounter file ownership issues.
Enabling and Disabling Users in Classic Zones
If you have added user profiles to classic zones, you can enable or disable their UNIX profiles in those zones at any time. Enabling and disabling a UNIX profile
is not applicable in hierarchical zones.
To enable or disable the UNIX profile for multiple users in a classic zone, select all of the user names to enable or disable using the CTRL or SHIFT keys, right-
click, then click Enable UNIX Account or Disable UNIX Account.
Forcing Replication for Read-Only Domain Controllers
If the Active Directory forest includes read-only domain controllers, you should force replications when adding or modifying users and groups in a zone.
Forcing replication ensures that the new information is available right away.
To force replication after updating a zone:
1. Click Start > Administrative Tools > Active Directory Sites and Services.
2. Expand Sites, then select the Active Directory site that contains the connection over which you want to replicate directory information.
For example, select Default-First-Site-Name.
3. Expand Servers, then select the read-only domain controller for which you want to force replication.
4. Click NTDS Settings.
5. In the details pane, right-click the connection over which you want to replicate directory information, then click Replicate Now.
If you choose not to force replication, the changes made to the zone will not take effect until replication is complete for the forest.
Using Configuration Parameters and Group Policies
You can use local configuration parameters or applied group policies to manage many operations for users and groups on Linux and UNIX computers. For
example, you can use configuration parameters or group policies to bypass Active Directory authentication for specific users or to allow some users or
groups to be approved for prevalidation. For more information about working with group policies, see the Group Policy Guide. For more information about
setting parameters in the Centrify configuration file, see the Configuration and Tuning Reference Guide.
Enabling and configuring local account management
The local account management features described earlier in this guide require that local account management be enabled and configured.
Several configuration parameters and group policies let you control whether local account management is enabled in your environment, and how local
account management is configured after it is enabled.
Local account management is disabled by default unless you are upgrading from a release in which local account management was enabled.
Follow these guidelines to determine whether you need to enable local account management:
If you perform a fresh installation of Server Suite, the Enable Local Account Management Feature group policy is set to Disabled, and the
adclient.local.account.manage configuration parameter on each local (agent-managed) computer is set to false. To use the local account
management features described in this guide, you must manually enable local account management by setting the Enable Local Account
Management Feature group policy to Enabled, or by setting the adclient.local.account.manage configuration parameter to true.
See the following sections, “Group Policies” and “Configuration Parameters,” for more information.
If you are upgrading from a previous release, you can check the Enable Local Account Management Feature group policy setting to enable or
disable local account management.
The following information is a summary of how various parameters and group policies affect local account management enablement and configuration. For
more details about these parameters and group policies, see the Configuration and Tuning Reference Guide and the Group Policy Guide.
Group Policies
Enable Local Account Management Feature: Use this group policy to control whether local accounts are managed by the UNIX agent and Access
Manager. This group policy is disabled by default, unless you are upgrading from a previous release in which local account management was enabled.
This group policy is located in Computer Configuration > Centrify Settings > DirectControl Settings > Local Account Management.
This group policy controls the adclient.local.account.manage configuration parameter.
Notification Command Line: Use this group policy to define a command to process changes to local account profiles after the agent synchronizes
local user and group profiles with profiles defined in Access Manager.
This group policy is located in Computer Configuration > Centrify Settings > DirectControl Settings > Local Account Management.
This group policy controls the adclient.local.account.notification.cli configuration parameter.
Set refresh interval for access control cache: Use this group policy to specify how often etc/group and etc/passwd are updated on UNIX and
Linux computers, based on the local group and local user settings that you configure in Access Manager. This group policy also controls how often the
authorization store cache is updated.
This group policy is located in Computer Configuration > Centrify Settings > DirectControl Settings > Network and Cache Settings.
This group policy controls the adclient.refresh.interval.dz configuration parameter.
Configuration Parameters
The following configuration parameters are located in the /etc/centrifydc/centrifydc.conf configuration file.
adclient.local.account.manage: Use this parameter to control whether local account management is enabled on an individual computer. This
parameter has a value of false by default, unless you are upgrading from a previous release in which local account management was enabled.
adclient.local.account.notification.cli: Use this parameter to define a command to process changes to local account profiles after the agent
synchronizes local user and group profiles with profiles defined in Access Manager.
adclient.local.account.notification.cli.arg.length.max: Use this parameter to specify the maximum argument length for the command that
you define in the adclient.local.account.notification.cli parameter.
adclient.refresh.interval.dz: Use this parameter to specify how often etc/group and etc/passwd are updated on an individual computer based on
the local group and local user settings that you configure in Access Manager. This parameter also controls how often the authorization store cache is
updated.
Authorizing Basic Access
This chapter describes the basic principles of authorization and how to grant access to Centrify-managed computers using the default predefined rights and
role definitions for Linux and UNIX computers. You should review the information in this chapter before creating custom role-based access rights and role
definitions.
Basic concepts of Access Rights and Roles
To log on and use Centrify-managed computers, Active Directory users must have a complete UNIX profile and be assigned to at least one role that grants
them access. Both the profile and the role assignment can be explicitly defined for the zone or for an individual computer, or inherited from a parent zone.
You can use Access Manager to centrally manage what users can do on computers that have the Centrify Agent installed. For example, you can control who
can log on or connect remotely for each computer in a zone through the definition of rights and the assignment of roles. A right represents a specific
operation that a user is allowed to perform. A role is a collection of rights that can be defined in a parent or child zone and assigned to Active Directory users
and groups.
The most basic rights are the predefined system rights that determine whether a user can log on locally with a password, log on remotely without a
password, and run commands in a standard shell or in a restricted shell. The most common settings for these system rights are defined by default in the UNIX
Login role so that you can grant users access to Centrifymanaged computers by simply assigning the predefined UNIX Login role and without defining any
custom roles or creating any additional access rights.
System Rights Authorize Access in Role Definitions
System rights are always associated with a role definition, whether it is a predefined role such as the UNIX Login role or a custom role you create. You can
enable or disable specific system rights in any role definition, but you cannot add, modify, or delete the rights themselves. For Linux and UNIX computers, you
can select the following system rights for any role:
Password login and non password (SSO) login are allowed: Specifies that a user is allowed to log on interactively using a password or without
a password using a single sign-on token.
Non password (SSO) login is allowed: Specifies that a user is allowed to log on using a single sign-on token.
Account disabled in AD can be used by sudo, cron, etc.: Specifies that an account that is disabled in Active Directory is allowed to access the
computer. This right is intended to allow service accounts that run without a password to perform operations.
Login with non-Restricted Shell: Controls whether a user gets a standard shell or is forced into a restricted shell. Users must be assigned at least
one role with this right to have access to a standard shell environment. A restricted shell only allows a user to execute explicitly defined commands.
In addition to the platform-specific system rights, there is a system right that allows users to bypass auditing or role restrictions to log on when there are
problems on a computer. By selecting the Rescue rights option you can allow users in a particular role to log on in situations when all users would normally
be locked out. For example, if authentication, authorization information, or auditing is required but not available, most users are prevented from logging on.
You can use the rescue rights option to allow selected administrators to access the computer and fix the issues that are preventing other users from logging
on.
Note: If you do not explicitly set the Allow users assigned to this role to log on if problems with authentication, authorization or auditing
services prevent logon access rescue right option for any users, only the local root account will have rescue rights. The root account is always allowed to
log on by default.
Access Rights Defined in the UNIX Login Role
The predefined UNIX Login role is configured by default to allow users to log on locally with a password, connect remotely to a computer without being
prompted for a password, and access the standard shell environment. The UNIX Login role is also configured to allow users to access all PAM-enabled
applications in their environment. The UNIX Login role grants access to PAM-enabled applications through a predefined loginall PAM access right.
For most users and organizations, the default settings in the UNIX Login role make the user experience consistent before and after deploying the Centrify
Agent and joining an Active Directory domain. Users can log on and use the shell environment and applications in the same way they did before the
deployment of the Centrify Agent.
The predefined UNIX Login role and predefined loginall PAM access right are available by default in every zone. Depending on your requirements and policies,
you can assign the UNIX Login role to all Active Directory users or to specific Active Directory users and groups. You can also choose whether to assign the
UNIX Login role in parent or child zones to control where different groups of users can log on to Linux and UNIX computers.
Users must have both a complete identity profile and at least one role assignment that grants access before they can log on to any Centrify-managed
computer. If you don’t use the UNIX Login role, you must create at least one custom role definition that provides similar functionality.
Default Access Rights and Roles
In addition to the predefined UNIX Login role that grants basic access to Centrify-managed computers during deployment, there are other predefined access
rights and role definitions that are available by default in every zone. These other predefined rights and role definitions provide specialized access rights for
specific scenarios that are common in Linux and UNIX environments.
Default PAM access rights
For Linux and UNIX computers, the following predefined PAM access rights are available:
login-all grants access to all PAM-enabled applications by specifying the asterisk (*) wild card for the application name. This right is included in the
predefined UNIX Login role. You can add this right to any custom role to grant access to all PAM applications, such as login, ftp, ssh, telnet, and many
others, without specifying them individually.
ssh grants access to secure shell sessions on Debian and Ubuntu 6 and 7 computers. By default, this access right grants users access to all secure shell
applications and operations.
sshd grants access to secure shell sessions on all Linux and UNIX computers except Debian and Ubuntu 6 and 7 computers. By default, this access right
grants users access to all secure shell applications and operations.
Default secure shell (SSH) access rights
Secure shell (SSH) access rights enable you to limit what users who are granted the PAM ssh or sshd right can do. These rights have no effect without the
PAM ssh or sshd right. In addition, the default secure shell rights are only applicable for the Centrify-compiled version of OpenSSH.
For Linux and UNIX computers, the following predefined secure shell access rights are available:
dzssh-all grants access to all secure shell services.
dzssh-direct-tcpip allows local and dynamic port forwarding (ssh-L, ssh -D).
dzssh-exec allows command execution.
dzssh-scp allows secure copy (scp) operations.
dzssh-sftp allows secure file transfer (sftp) operations.
dzssh-shell allows secure terminal (tty/pty) connections.
dzssh-Subsystem allows an external subsystem except sftp subsystem which has its own right.
dzssh-tcpip-forward allows remote port forwarding (ssh -R).
dzssh-tunnel allows tunnel device forwarding.
dzssh-X11-forwarding allows X11 forwarding.
Predefined role definitions
In addition to the predefined UNIX Login role, there are several predefined role definitions that are available by default in every zone. For Linux and UNIX
computers, the following predefined role definitions are available:
listed makes a user profile visible in a zone but does not grant any type of access rights, PAM rights, or command rights. This is a specialized role that
can be used when a user profile must exist for computers in a zone, but no local or remote access should be granted. For example, if a user owning files
on a computer in a zone should no longer have access to the computers in the zone, you can assign the listed role so that the files continue to have an
owner, but the user has no effective logon rights in the zone.
local listed makes a local user profile visible in a zone but does not grant any type of access rights. This is a specialized role that can be used when a user
profile must exist for computers in a zone, but no user access should be granted. For example, if a user owning files on a computer in a zone should no
longer have access to the computers in the zone, you can assign the listed role so that the files continue to have an owner, but the user still has no
effective rights in the zone.
require MFA for login forces two-step authentication for access. This role does not grant access to any PAM applications but can be used in
combination with the UNIX Login role to require users who are assigned to both roles to provide more than one form of authentication. You can also use
this role with custom roles that grant access to specific applications if you want to require multi-factor authentication for those applications. You
should note that using this predefined role definition requires additional configuration outside of Access Manager. For more information about what is
required to support multi-factor authentication, see Requiring multi-factor authentication to log on.
Rescue - always permit login enables users to log on to computers if there are problems with the authentication, authorization, or auditing service that
are preventing other users from logging on. For example, if auditing is required on a computer and the auditing service is not available, only users
assigned to a role with the “rescue” system right will be able to log on.
scp grants secure copy (scp) access rights.
sftp grants secure file transfer (sftp) access rights.
Identifying the Scope for Role Definitions
The rights from multiple role assignments accumulate, which provides great flexibility and granularity in how you define and assign rights and roles. For
example, you can use the UNIX Login role to control basic access, and define a second role that grants the rights to execute a set of privileged commands, so
that a user assigned to both roles could log on, but only execute a few specific commands with elevated privileged. By separating rights into separate role
definitions, not every role requires PAM applications or system rights, as long as a user is assigned a role that has those rights.
Because access rights are additive, however, it is important to consider where you define and assign roles to control who has administrative privileges on
which computers. For example, it might seem reasonable to assign the predefined UNIX Login role to all Active Directory users. Doing so, however, could grant
broad permission to log on to Linux or UNIX computers to which you want to restrict access. If you assign that role in a parent zone, it is inherited along with
any additional rights granted in child zones.
In most cases, it is appropriate to define roles in parent zones, but assign roles carefully in child zones to avoid granting access rights on computers that host
administrative applications or sensitive information.
Assigning the UNIX Login Role
The predefined UNIX Login role allows Active Directory users to log on to Centrify managed computers using any PAMenabled application—such as login, ssh,
or ftp—with a default shell and permission to execute the same set of commands available to any standard UNIX user account. By default, the UNIX Login role
is configured to take effect immediately and never expire. By default, the UNIX Login role is also configured to audit user activity if the auditing service is
running on a computer users access.
The default settings are appropriate for most Linux and UNIX users in most organizations. However, you can change any of the default settings in either a
parent or a child zone, if needed.
What to do before assigning the UNIX Login role
You can assign the UNIX Login role to all Active Directory users, to specific Active Directory users, or to specific Active Directory groups. Because the UNIX
Login role is a predefined role, you cannot assign any local users to the role.
Before you assign the role, you should decide whether you want to assign and inherit the role from a parent zone or make the assignment in a specific child
zone. You should also decide whether you want to specify optional start and end times for some role assignments.
The following table describes the minimum rights that must be granted for users to successfully manage role assignments in a zone:
On the Object tab, select Allow for the following: List contents Read all properties Create all child
Authorization objects Delete all child objects On the Properties tab, select Allow for the following: Write msDS- This object only
AzApplicationData
On the Properties tab, select Allow for the following: Write displayName Write msDS- The msDS-AzRole
AzApplicationData Write msDS-TasksForAzRole Write msDS-MembersForAzRole object
The msDS-
On the Object tab, select Allow for the following: List contents Read all properties Create msDS-
AzRoleObjectContainer AzApplication object
AzRole objects Delete msDS-AzRole objects
and all child objects
On the Properties tab, select Allow for the following: Write displayName Write msDS- The msDS-AzRole
The msDS-
On the Properties tab, select Allow for the following: Write msDS-AzApplicationData AzAdminManager
object
On the Object tab, select Allow for the following: Read all properties Create msDS-AzOperation
AzOpObjectContainer This object only
objects Delete msDS-AzOperation objects Create msDS-AzRole objects Delete msDS-AzRole objects
On the Properties tab, select Allow for the following properties: Write displayName Write msDS- The msDS-AzRole
On the Properties tab, select Allow for the following: Read name Read Name Write msDS- The msDS-AzOperation
AzApplicationData Write name Write description object
A UNIX administrator who manages one or more zones most often performs this task, depending on your organization’s policies.
In most organizations, you assign the UNIX Login role to target groups of users at a time during deployment and as needed, thereafter.
The following instructions illustrate how to assign the UNIX Login role using Access Manager. Examples of scripts that use the Access Module for Windows
website.
To assign users and groups to the UNIX Login role in a zone
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to make role assignments.
5. Select the UNIX Login role definition from the list of roles, then click O K.
By default, the role is set to start immediately and never expire. You can set a Start time, End time, or both start and end times for the role
assignment. For example, if the role assignment applies to a contractor who will be hired for a specific period of time and you want to automatically
disable the role after they finish the job and leave the organization, you can specify the start and end times when you assign the role.
6. Select whether the role assignment applies to all Active Directory accounts or specific accounts.
If you want to automatically assign the role to every user added to the Active Directory forest or trusted forests, you can select All Active Directory
accounts for convenience. This option is similar to selecting the “Authenticated Users” or “Everyone” system groups. For example, if you want to
assign all Active Directory users the UNIX Login role by default, you can select this option. Only users who also have a complete UNIX profile will be able
to log on to the UNIX computers joined to the domain.
If you are assigning the role to specific accounts, click Add AD Account to search for and select the Active Directory groups or users to assign to the
role, then click O K.
7. Click O K to complete the role assignment.
What to do next
Verify Active Directory users or group members assigned the UNIX Login role can log on to Centrify-managed computers in the zone where you have made
the role assignment.
If you want to learn more about working with rights, roles, and role assignments, see the following topics for additional information:
Defining rights to use commands
Defining rights to use PAM applications
Using secure shell session-based rights
Creating and assigning custom role definitions
Performing Role Assignment on Multiple Computers
To simplify the process of assigning Active Directory users or groups to a role, you can perform a bulk role assignment. With a bulk role assignment, you can
assign a role to multiple Active Directory users and groups on multiple computers at the same time. For example, if you have two groups of Oracle
administrators and three computers where the members of those groups need access to their OracleAdmin role, you can select those two groups and those
three computers to be assigned the OracleAdmin role in the same process. You can also specify optional start and end times for the role assignment and have
those settings apply for all of the users, groups, and computers you have selected for bulk assignment.
To assign a role to multiple users and groups on multiple computers
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to make a bulk role assignment.
3. Right-click, then select Assign Roles to Computers.
4. Type the user and group names you want to be included in the role assignment, then click O K.
You can specify multiple names separated by a semi-colon (;). You can also search for user and group names by typing part of the name and clicking
Check Names or by clicking Advanced and entering search criteria. If multiple users or groups match the search criteria, select the appropriate users
and groups, then click O K.
5. Type the computer names you want to be included in the role assignment, then click O K.
You can specify multiple names separated by a semi-colon (;). You can also search for the computer names by typing part of the name and clicking
Check Names or by clicking Advanced and entering search criteria. If multiple computers match the search criteria, select the appropriate computers,
then click O K.
6. Select a role for the list of roles available, then click O K.
7. Review the role assignment start and end time and the user and group accounts that are being assigned the role, then click O K.
You can make changes to the start and end times if you want those changes applied for all of the users, groups, and computers that are part of this bulk
role assignment.
After you click OK, the selected users and groups are then automatically assigned the selected role on the selected computers.
Viewing Rights and Roles
Access Manager allows you to view the status and effective rights for any Active Directory user or local user in a zone, whether they have been assigned a role
or not. You can view detailed information about the rights and role assignments for users by using Show Effective UNIX User Rights. If a user is not
assigned a role or does not have a complete user profile, be certain to select the Show omitted users option, otherwise, information will not be shown for
the user.
Note: Local users are defined in Access Manager in the zone and are saved in /etc/passwd on each computer in each zone where the profile is
defined. Local users that you define in the zone do not need to be Active Directory users. For more information about local users, including
information that is required for a user profile to be complete, see Creating user profiles.
To view rights for an individual user in Access Manager
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to view rights and other account details.
3. Right-click, then select Show Effective UNIX User Rights.
4. Select a computer or click Browse if you want to limit the information included to a specific computer.
5. Select Show AD users and Show local users as necessary, depending on which users you want to view. One or both of these choices might already
be selected, depending on the location from which you originally selected Show Effective UNIX User rights.
6. Select Show omitted users to include users who have an incomplete profile or do not have a role assignment in the list of UNIX users.
User information is displayed as shown in the following example. Key points about the information displayed are as follows:
Users with incomplete profiles are displayed in red (if Show omitted users is selected).
Local users are not required to have an AD name, resulting in a displayed AD Name value of N/A.
AD users are not required to have a UNIX profile, resulting in a displayed Profile State value of N/A.
For more information about the differences between AD users and local users, as well as details about profile states for local users, see Creating,
modifying, and deleting user profiles for local users.
Creating, modifying, and deleting user profiles
7. Select a user to see more detailed information about the user’s profile, role assignments, and rights in the selected zone or on a specific computer:
Click Zone Profile to review the UNIX profile defined for a user and where the profile attributes are defined. If a user has an incomplete profile,
you can click the Zone Profile tab to see which profile attributes are missing.
Click Role Assignments to review a user’s role assignments. The Object Assigned column indicates whether the role is explicitly assigned to the
user (user@domain) or to a group the user is a member of (group@domain). The Location of Assignment column indicates the zone or computer
role in which the assignment was made. Information for the Start Time, End Time, or both columns is only displayed if a role assignment has time
constraints.
Click PAM Accesses to review the PAM application access rights for the user in the selected zone or on a specific computer, including the role to
which the right belongs.
Click Commands to review the command access rights for the user in the selected zone or on a specific computer, including the role to which the
right belongs.
Click SSH Rights to review the secure shell rights for the user in the selected zone or on a specific computer, including the role to which the right
belongs.
8. Click Close when you are finished reviewing user rights in a zone or on particular computers.
Checking rights and roles with the dzinfo program
You can also view rights and roles for specific users or the current user by running the dzinfo command-line program on Centrifymanaged computers. If you
want to use the dzinfo program to view roles and rights for other users, however, you must have root permission.
You can run dzinfo without any arguments to see your own rights and role assignments. The command displays detailed information about the your role
assignments, the availability for each role assignments, your effective rights, the current audit level, and the specific PAM access, command, and secure
shell rights you have been granted.
To see more detailed information, such as the days and times a role is available, you can use the --verbose option. For example, to see detailed information,
you could type the following command:
dzinfo --verbose
To view roles and rights for a specific user:
1. Log on or switch to root on a managed computer.
2. Run the dzinfo command for a specific user with the username in the command line.
dzinfo username
For example, to see details about the rights and roles assigned to the user sonya, you could type the following command:
dzinfo sonya
If rights and role assignments have been configured for the specified user, the command displays detailed information about the user’s role assignments, the
availability of those role assignments, the user’s effective rights, the audit level in effect, and the specific rights that have been granted.
You can also use the dzinfo program to test whether a user has the right to run specific commands. For more information about using dzinfo and the dzinfo
command line options, see the dzinfo man page.
Changing the Audit Level for Role Definitions
By default, all role definitions—including predefined role definitions—are set to “Audit if possible” as the audit level. With this setting, user activity is audited if
the auditing service is installed and enabled on a managed computer. If the auditing service is not installed or not running on a given computer, this setting
has no effect. Users can log on and use the access rights that are defined for their role assignment without having their activity audited.
In most cases, the default “Audit if possible” setting is appropriate because it doesn’t block user access if you are not deploying the auditing infrastructure
but will automatically capture user activity if you are deploying auditing. In some cases, however, you might want to change the audit level. You can modify
the audit level for any role definition to specify whether users must be audited in order to log on.
To change the audit level for a role definition:
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to change the audit level.
3. Expand Authorization and Role Definitions.
4. Select a role definition, right-click, then select Properties.
5. Click the Audit tab.
6. Select the appropriate audit level to use for the role definition.
Select Audit not requested/required if you are not interested in auditing session activity for users in the role.
Select Audit if possible if you want to audit user activity on computers running the Centrify auditing service. If you select this option and the
auditing service is not installed or not currently available, users assigned to the role are allowed to log on without having their activity audited. This
option is selected by default for new roles.
Select Audit required if you want to audit all session activity for users assigned to the role. If you select this option and the auditing service is not
installed or not currently available, users assigned to this role are not allowed to log on.
If auditing is required for users in a role, you should also define a role with rescue rights to allow selected administrators to log on and correct
problems when other users are locked out. For more information about creating a role with rescue rights, see Creating a role definition with rescue
rights.
Requiring Multi-Factor Authentication to Log On
You can configure multi-factor authentication for users logging on to Centrify-managed computers to improve the security of physical or virtual data
centers. You can assign the predefined require MFA for login role in combination with the UNIX Login role to require users who are assigned to both roles to
provide more than one form of authentication. You can also create custom role definitions with the Require multifactor authentication for login
system right. Before setting this system right, however, you should be aware the multifactor authentication for Centrify-managed computers relies on the
infrastructure provided by the Centrify Identity Platform.
As a preview, here are the steps involved to enable multi-factor authentication for Centrifymanaged computers in hierarchical zones:
Register for Privileged Access Service.
Install and configure at least one connector for communication with Privileged Access Service.
Verify the users who are required to provide more than one form of authentication have valid Active Directory accounts that are active in Privileged
Access Service.
Add or select the authentication profiles that specify the types of authentication challenges to support.
Create a role with the appropriate computer members and administrative rights for multifactor authentication.
Verify the identity platform instance URL you want to use if you have access to more than one instance.
After you have completed the preliminary steps, you can assign users the predefined require MFA for login role or a custom role with the Require multi-
factor authentication for login system right to require two-step authentication when logging on using PAM applications. These preliminary steps are
also required if you want to create command rights that require two-step authentication when executing commands using elevated privileges (dzdo) or in
restricted shell (dzsh) environments.
The preliminary steps are also required to support multi-factor authentication in classic zone and Auto Zone. However, the implementation is slightly
different than in hierarchical zones, so some of the steps differ depending on the type of zone where you want to use multi-factor authentication.
For more information, see the Preparing to use multi-factor authentication
Defining Rights to Use Commands
As discussed in Basic concepts of access rights and roles, access rights allow users to perform specific operations. You define the most basic rights—such as
the right to log on or connect remotely—when you define roles. However, you can use more granular command access rights to tightly control who has access
to individual command-line programs. This chapter describes how to define access rights that allow users to execute command-line programs on Centrify-
managed computers.
Controlling Access to Commands
In a standard UNIX shell environment, an ordinary user account can execute a large number of common command-line programs without any special
privileges, and one or more administrative accounts, such as root, are required to execute commands that perform privileged operations. If ordinary users
need to execute any of the commands requiring administrative privileges, they might have to switch to an administrative account that requires them to know
the password for a privileged users or been granted access by configuration settings in a sudoers file.
For Centrify-managed Linux and UNIX computers, however, you can define command access rights to tightly control the specific commands users can
execute. You can also refine those rights to only allow specific arguments to be used or to require an executable to be located in a specific directory.
There are no predefined rights for commands. Therefore, only the specific command access rights you define will be available for you to add to roles. You
should keep in mind that any command rights you define are specific to the zone where you configure them, but can be used in any child zones of that zone.
What Command Rights Provide
Command access rights identify the specific commands that can be executed on a Linux or UNIX computer by a user assigned the role to which the rights are
added. Command rights also specify whether the commands defined in the right are executed under the user’s own account or using another user account.
There are two primary reasons for defining command rights:
To grant access to specific commands that must be executed with elevated privileges
To restrict access to only allow specific commands to be executed.
Granting access using command rights
The most common reason for defining a command right is to grant access to commands that perform privileged operations. For example, you might want to
grant users additional privileges to execute specific commands in a standard shell environment that they are not otherwise allowed to execute with the
default rights associated with their account.
With this type of command right, most commands are executed in the default shell environment with ordinary user privileges. When users assigned to a role
with this type of command right want to use their elevated privileges, they invoke the command they have been granted access to using the dzdo command.
This type of command right is similar to configuring privileges in a sudoers file, then invoking a command using sudo.
This type of command right is appropriate for UNIX users who have a standard shell environment and only need elevated rights to perform specific tasks.
Restricting access using command rights
It is less common, but also possible to define a command right to restrict access. For example, you might want to create a role that provides strictly controlled
access to an explicitly defined subset of shell commands. This type of command right creates a customized restricted environment shell (dzsh) where only
explicitly defined commands can be executed. This type of command right is similar to configuring a “whitelist” of allowed command and is appropriate for
users who only need access to a limited set of commands to perform their job.
Controlling the Shell Environment for Commands
You can define command rights to control who has permission to run specific commands in a zone. When you define individual command rights, you can also
specify whether the commands can be executed in a non-restricted shell environment, a restricted shell environment, or both. After you define the command
right, you can then add it to an appropriate role definition. It is then the role definition to which you add the command right that controls whether users can
use the command in a standard, unrestricted shell environment or in a restricted shell environment.
If the role definition allows a non-restricted shell environment—like the UNIX Login role—the command right provides functionality similar to the UNIX sudo
command except that it uses the role settings and the zone authorization store rather than through a sudoers configuration file.
If the role definition does not allow access to a non-restricted shell environment, the command right can only be used in a restricted shell environment and
users assigned to the role can only execute the specific commands explicitly defined in command right.
Defining Rights to Run Privileged Commands
The most common reason for creating a command right is to allow users to execute commands that require privileges not granted to a standard UNIX user
account. For example, you might want to grant some users permission to run Centrify command-line programs that require root privileges to better manage
their own computers.
Defining command rights that grant elevated privileges is similar to granting access to privileged commands using the sudoers configuration file and the
sudo program.
The following instructions illustrate how to define a command right to execute a command with elevated privileges. Examples of scripts that use the Access
Module for Windows PowerShell, ADEdit, or the Centrify Windows API are available in other guides, the Centrify Software Developer’s Kit, or in community
forums on the Centrify website.
To define a command right for privileged access
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to define a command right.
3. Expand Authorization and UNIX Right Definitions, then select Commands.
4. Right-click, then click New Command.
5. On the General tab, type a short descriptive name for the command right, and optionally, a more detailed description for the command right.
The privileged command name is required and must not be more than 63 characters in length or contain any special characters, such as asterisks (*),
slashes (\ /), question marks (?), or quotation marks (“).
6. Type the command you want to add.
The Command field is required and should include any parameters or options, if needed. You can also use wild cards or a regular expression to specify
commands matching a particular pattern.
7. Select the type of pattern matching to use for the “Command” and “Specific path” fields.
Select Glob expressions to use glob pattern matching syntax for wild cards.
Select Regular expressions to use extended regular expression pattern matching.
For more information about pattern matching, see Selecting the pattern matching syntax.
8. Select an appropriate path for matching the command on the different operating environments you support.
Select Standard user path to use the local operating system’s common set of user directories to find the command.
Select Standard system path to use the directories the root user would normally get on the local operating environment to find the command.
Select System search path if you want to search for the command in a predefined set of locations. The search locations are defined using the
dzdo.search_path configuration parameter. If you select System search path and the dzdo.search_path parameter is not defined, the current
user’s path is used to search for the command.
Select Specific path if you want to define a custom set of locations for finding the command specified. If you select this option, you can specify
one or more paths, separated by a colon.
If you are specifying a path, the path must start with a forward slash (/) unless you are matching all paths (*). For example, if the command you
specify is ls and you set the path to *, the ls command from any path is allowed.
If you set both the “Command” field and the “Specific path” field to match all strings (*), any command from any path is allowed.
9. Specify an integer that determines the priority of the command — the lower the number, the higher the priority.
If there are multiple commands that match the pattern you specified for the “Command” field, the priority determines which command has higher
priority.
10. Click the Run As tab, then select Can be used by dzdo to allow the command to be added to a role for privileged execution.
11. Select the user or group accounts that can be used to execute the command.
Select Any User if any standard user account can be used to execute the command with dzdo.
Select One of the following users, uids, groups or gids if you want to specify one or more user or groups that can be used to execute the
command with dzdo.
In most cases, the local root account is the appropriate account to use because it allows ordinary users to execute the specified command using
root account privileges. However, you can click A d d to add other users, groups, or service accounts that can be used to execute the command.
Use the format #UID for UID values, %group for group names, or %#GID for GID values.
The account used to execute commands can be an Active Directory user with a UNIX profile in the zone or a local UNIX user account. However, the
account used to log on and invokes the command using dzdo must be associated with an Active Directory account.
Optionally, you can specify the primary groups can be used when executing the command using dzdo:
Select Any Group if any group can be used as the primary group when executing the command with dzdo.
Select One of the following groups, then click A d d if you want to specify the groups that can be used as the primary group when executing
this command with dzdo.
You can also configure commands to be executed using dzdo in a restricted shell environment. For this example, however, the command right is
only used in a nonrestricted shell environment.
12. Click O K to save the new command right.
In most cases, you can use the default settings for environment variables and execution attributes.
If you want to keep, remove, or add environment variables for command execution, see Customizing environment variables for command
execution.
If you want customize any of the execution attributes, see Customizing command execution attributes.
Creating a role to run commands with elevated privileges
On most Linux and UNIX computers, you can identify commands that require elevated permissions, who can run those commands, and where different users
or groups can run the commands using a sudoers configuration file. Users who have been granted the appropriate permissions can run privileged commands
by invoking the sudo command.
Centrify provides similar functionality, but the commands are configured by defining command rights, adding the rights to the appropriate roles, and
assigning the roles to different users and groups. Users who have been assigned the appropriate roles can then run privileged commands by invoking the dzdo
command.
If users are assigned the predefined UNIX Login role, they have access to all of the standard command-line programs that are available to ordinary UNIX
users. You can create a separate role for commands that run using root or another privileged user account. Alternatively, you can combine command rights
and system rights in a custom role definition or by adding the command rights to the default UNIX Login role.
Command rights that allow users to execute commands with elevated privileges should only be added to roles with the Login with Non-Restricted Shell
system right.
Users must execute command rights that grant elevated privileges using the dzdo command. If you selected the Re-authenticate current user option as
an execution attribute when defining a command right, users must also provide the password for their own account, their own password and one or more
other forms of authentication, or the types of authentication determined by the authentication profile configured in Privileged Access Service, which might or
might not involve providing a password.
If you selected the Re-authenticate using the target user’s password option as an execution attribute when defining a command right, users must
also provide the password for the account used to execute the command.
To create a role that can execute commands with elevated privileges, do the following:
Create command rights for the privileged commands users are allowed to run.
Create a new role definition and set the System Rights for the role to allow password login, nonpassword login, or both, and select the Login with Non-
Restricted Shell option, then click O K to save the role definition.
Right-click the role, select Add Right, then select login-all or a specific PAM access right and the privileges command rights users are allowed to run,
then click O K to save the changes to the role definition.
For more information about creating, assigning, and testing custom role definitions, see Customizing command execution attributes.
Defining a Restricted Shell Command Right
You can also use command rights to strictly control which commands certain users can execute. In a restricted shell environment, users can only execute the
specific commands and command-line options that are explicitly allowed. For example, you might want to grant some users permission to run a specific
Centrify command-line program, such as adinfo, without allowing them to run any other command-line programs on some computers.
Users who are assigned to a role with the restricted shell environment are not be able to run any other commands, including informational commands such ls,
ps, and whoami, unless you explicitly include them in the command right. You are not required to explicitly add basic navigational commands, such as cd and
pwd, to the command right.
What the restricted shell provides
For Linux and UNIX computers, Centrify provides a customized Bourne shell, dzsh, to serve as the restricted shell environment. The dzsh restricted shell
supports environment variables, job control, command history, and the specific command rights you define. For example, you can use the up-arrow key in the
dzsh shell to recall previously-entered commands. You can also set a limit to the command history available by adding HISTSIZE=n to the $HOME/.dzshrc file.
For most operations, working in the dzsh shell is similar to working in an unrestricted shell except that the command set available is limited to the command
rights you add to the environment.
Limitations of the restricted shell
The restricted shell environment does not enforce rights for commands that run outside of the shell. For example, if users run a graphical desktop manager,
they can run commands and applications that are launched from menu selections in the graphical user interface.
In addition, the command rights defined for the dzsh shell do not prevent users from running built-in shell commands, accessing the file system, or seeing
process or system information. For example, even in a restricted shell environment with no rights to run any commands, users in a dzsh shell could get a
process listing using the following script:
for i in /proc/[0-9]*;
do read PROC < $i/cmdline;
echo $PROC;
done
Because the shell scripting environment allows the operations, users can effectively access information that the commands defined for the restricted shell
environment do not allow.
Securing the restricted shell environment
There are many ways sophisticated users can get around limitations placed on a restricted shell environment. For example, most text editors, such as vi and
emacs, allow shell escapes. Giving users permission to run programs that allow shell escapes in a restricted shell enables them to open a new unrestricted
shell environment with none of the restrictions placed on them in their defined environment, Similarly, giving users access to commands that set or modify
local time and date settings might allow users to avoid time constraints for running commands or the expiration date and time for specific role assignments.
In some cases, even individual command line options might provide users with the means to run commands not defined in their restricted shell environment.
For example, defining a command right that allows users to run the tar command with the usecompressprogram program_name option allows user to run the
specified program_name even though the program_name is not an allowed command in their restricted shell environment.
In choosing the commands to allow in a restricted shell, therefore, you should carefully consider ways to plug potential security holes the commands might
introduce or whether there are alternative commands that provide the same functionality more securely. For example, if you need to give a user access to an
editor, such as vi or vim, you could restrict the ability to execute nested commands to prevent users from opening a new shell from within the editor.
Alternatively, you could add the rvi command to the restricted environment instead of vi or vim because rvi doesn’t allow the user to open a new shell.
For more information about setting attributes that control command executions, see Customizing command execution attributes.
The following instructions illustrate how to define a command right for use in a restricted shell using Access Manager. For more information about any step,
see Defining rights to run privileged commands. Examples of scripts that use the Access Module for Windows PowerShell, ADEdit, or the Centrify Windows
API are available in other guides, the Centrify Software Developer’s Kit, or in community forums on the Centrify website.
To define a command right for restricted shell access
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to define a command right.
3. Expand Authorization and UNIX Right Definitions, then select Commands.
4. Right-click, then click New Command.
5. Type a short descriptive name for the command right, and optionally, a more detailed description for the command right.
6. Type the command you want to add.
7. Select the type of pattern matching to use for the “Command” and “Specific path” fields.
8. Select an appropriate path for matching the command on the different operating environments you support.
9. Specify an integer that determines the priority of the command—the lower the number, the higher the priority.
10. Click the Restricted Shell tab, then select Can be used in a restricted role to allow the command to be added to a role that runs in a restricted
shell environment.
11. Select whether commands are executed using the user’s logon account or using a specific the user name or UID.
If you want to configure commands to be executed using dzdo in a restricted shell environment, you can click the Run As tab to specify a user or group
for command execution.
12. Click O K to save the new command right.
In most cases, you can use the default settings for environment variables and execution attributes.
If you want to keep, remove, or add environment variables for command execution, see Customizing environment variables for command
execution.
If you want customize any of the execution attributes, see Customizing command execution attributes.
Creating a role to run commands in a restricted shell
For Linux and UNIX computers, Centrify provides a customized Bourne shell, dzsh, to serve as a restricted shell environment. The dzsh restricted shell
supports environment variables, job control, command history, and the command access rights you define.
To create a role that runs a restricted shell, do the following:
Create command rights for the restricted shell commands users are allowed to run.
Create a new role definition and set the System Rights for the role to allow password login, nonpassword login, or both, and verify that the Login with
Non-Restricted Shell option is not selected, then click O K to save the role definition.
Right-click the role, select Add Right, then select login-all or a specific PAM access right and the restricted shell command rights users are allowed to
run, then click O K to save the changes to the role definition.
For more information about creating, assigning, and testing custom role definitions, see Customizing command execution attributes.
Selecting the Pattern Matching Syntax
When you define a command right, you can specify whether you want to use glob pattern matching syntax or extended regular expression syntax to match
the strings specified for the “Command” and “Specific path” fields.
Customizing Environment Variables for Command Execution
You can customize the environment variables used during command execution in both the non-restricted and restricted shell environments. For example, if a
command is executed using a specific user or service account that requires environment variables that are not defined for the user invoking a command, you
can define those environment variables as part of the command right definition.
If you want to configure the environment variables to use for a command right, click the Environment tab. You can then select one of the following options:
Reset environment variables
Remove unsafe environment variables
Add environment variables
Resetting environment variables
Select Reset environment variables if you want to define the list of environment variables to set when the user runs the command. Note that only the
environment variables you explicitly specify are retained and those environment variables will replace the default set of environment variables, rather than
append the default set of environment variables. You can use Access Manager or dzdo.env_* configuration parameters in the centrifydc.conf file to control
the list of environment variables to use when executing commands. For example, you can set the dzdo.env_keep configuration parameter in the
centrifydc.conf file to keep a specific set of environment variables like this:
dzdo.env_keep: VAR
With this setting, only the VAR environment variable is defined for the list of environment variables to keep. All other environment variables, including the
default list of user environment variables—such as PATH and KRB5CCNAME—are removed.
If you select this option, click Edit to specify the environment variables to retain from the user’s environment in a comma-separated list. Click A d d, type the
environment variable name, then click O K for each environment variable you want to retain.
Removing environment variables
Select Remove unsafe environment variables if you want to remove a specific set of unsafe environment variables when the user runs the command.
The list of unsafe environment variables is defined by the dzdo.env_delete configuration parameter in the centrifydc.conf file. Note that only the
environment variables you explicitly specify are removed.
If you select this option, click Edit to specify the environment variables to remove from the user’s environment in a comma-separated list. Click A d d, type
the environment variable name, then click O K for each environment variable you want to remove.
Adding environment variables
Select Add environment variables to define new environment variables to add when the user runs the command. Enter variables in a comma-separated
list in the form name=value, or click Edit then A d d to add new variables and values. You can add new variables regardless of which of the other options you
select.
Customizing Command Execution Attributes
You can modify the default command execution attributes that are used when commands run in either the non-restricted shell or in a restricted shell
environment. In most cases, changes are rarely required for commands that run in a non-restricted shell. It is more common to change the execution
attributes for commands that run in restricted shell environments. For example, you can use the execution attributes to control whether an allowed command
can invoke a nested command. In a restricted shell environment, you might want to prevent a command from invoking nested commands to reduce the
chance that users can run commands not explicitly defined for their environment.
If you want to set any execution attributes for a command right, click the Attributes tab. You can then select different options to control different aspects of
command execution.
Requiring re-authentication to run commands
After successful authentication during the login process, you can control whether running a command in a restricted shell or using elevated privileges
requires re-authentication or not. If you want to require re-authentication, select the authentication rules to apply. When defining the rights for executing
commands, you can select from the following authentication options:
No re-authentication required
Select this option to allow users to run the command without any additional authentication.
Re-authenticate current user
Select this option to require the user to be re-authenticated before running the command using their own credentials. If you select this option, you can
also specify whether reauthentication requires the user to provide their password, requires their password and another form of authentication, or
requires multi-factor authentication as determined by the authentication profile configured in Privileged Access Service, which might or might not
involve providing a password.
If you select both Use password and Require multi-factor authentication for login, users are prompted to type their password and provide
another form of authentication before the command is executed. If you have configured the authentication profile to accept more than one type of
authentication challenge, users are prompted to select the authentication method to continue.
Re-authenticate using the target user’s password.
Select this option to require the user to be re-authenticated before running the command using the target run-as user’s credentials.
Preserving group membership
When defining command rights, you should consider whether keeping a user’s existing group membership would provide benefits for command execution or
could be exploited to perform unauthorized operations.Select Preserve group membership if you want to retain the logged-on user’s group membership
while executing commands.
Allowing nested commands
When defining command rights, you should consider whether allowing the execution of nested commands could be exploited to perform unauthorized
operations. Select Allow nested command execution if you want to allow a command to invoke another program or open a new shell. To enhance the
security of a restricted shell environment, you should deselect this option to prevent an allowed command to be used to run another program or open an
unrestricted shell.
Preventing unsafe path navigation
When defining command rights, you should consider whether the command or any of the allowed command arguments could be exploited to perform
unauthorized operations. One way command arguments can be exploited is to allow navigation up the path hierarchy. To prevent command arguments from
allowing unsafe navigation up a path hierarchy, you can select the Prevent navigation up a path hierarchy. For example, if a command right allows a
user to execute a command such as vi /etc/httpd/conf/* without this option, the right could be exploited by specifying a command argument that navigates
up a path hierarchy to perform an unauthorized operation. In this case, the right might be used to edit any file as the root user by specifying a relative path as a
command-line argument.
vi /etc/httpd/conf/../../shadowpass
You can avoid this potential security risk by disabling upward path navigation for command arguments, if needed. Note that this setting is only supported in
hierarchical zones and is only applicable for glob command rights.
Setting the umask value
Set the Umask value by selecting the read (R), write (W), and execute (X) permissions for the owner, group, and other users if you want to change the
permission settings for executing a command.
Setting SELinux role-based access control
Configure the SELinux Setting for dzdo Security Enhanced Linux (SELinux) role-based access control (RBAC). By enabling the SELinux role and SELinux
type fields, privileged commands can be specified with the default role and type for creating SELinux context in execution. These settings can be overridden
using the '-r'/'-t' command-line options respectively. To enable this setting, click the SELinux Setting button and enable SELinux role and SELinux type,
then enter string values in the corresponding text fields. Settings are saved in the attribute of the msDS-AzOperation command object.
Note: These settings are currently supported only on the RHEL systems and effective only on system with SELinux enabled and joined to a hierarchical zone.
Setting the command digest
You can use Digest Settings to specify SHA-2 digests so that sudo can verify the binary's checksum (SHA-2) before sudo executes the binary. The supported
digest (hash) types are as follows:
SHA224
SHA256
SHA384
SHA512
Select a digest type, and then enter a checksum. You can specify multiple digests for a command.
Note that setting a command digest is only supported in the explicit path matches against the command right, and only supported in the hierarchical zone.
Testing Command Rights
After command rights have been defined, added to role definitions, and assigned, you can use dzinfo --test “command” to check whether you have
permission to execute a specific command. You can use the dzinfo username --test “command” command to check whether a specified user has permission
to run a specified command. If you want to use the dzinfo program to view command rights for other users, however, you must have root permission.
To check for command rights, you must enter the complete path to the command and enclose the command in single or double quotes. For example, to test
whether the user, qa1 has a command right that allows execution of the id command as root, you could run the following command on a Linux or UNIX
computer:
[user1@rh5]# dzinfo qa1 --test “/bin/id”
Depending on the role definition and the user’s role assignment, the command might display information similar to this:
Testing: User = qa1 command = /bin/id
User qa1 can run the command as 'root' via dzdo, authentication will not be required, noexec mode is off
Using Command Rights in a Standard Shell
After command rights have been defined, added to role definitions, and assigned, users can execute privileged commands in a standard shell environment by
invoking the dzdo command then typing the command to execute, including any command-line options they are allowed to use.
For example, assume you have defines a command right for shutdown -r that enables users to execute the command as the root user. If you add that right to a
role definition—such as the UNIX Login role—that allows users to log on using a standard shell environment, users assigned to that role can execute the
command by typing the following:
dzdo shutdown -r
Using Command Rights in a Restricted Shell Environment
After command rights have been defined, added to role definitions, and assigned, users can execute commands in a restricted shell environment by typing
the command, including any command-line options they are allowed to use.
For example, assume you have defines a command right for shutdown -r that enables users to execute the command as the root user. If you add that right to a
role definition that forces users into a restricted shell environment, users assigned to that role can execute the command by typing the following:
shutdown -r
Users can only execute the specific command rights that have been added to the role within the restricted shell environment.
Running unauthorized commands
When users are assigned to roles that require a restricted shell environment, the dzsh shell provides the subset of commands the user is allowed to run and
automatically runs each allowed command as the user the command is configured to run as. If the user attempts to run a command he is not authorized to
use in his current role, the shell displays a warning. For example, if the user is not authorized to run the uname command in the dzsh shell, the following
message is displayed:
$ uname
uname: command not allowed
Setting or changing the active role
Users who are only assigned to one or more restricted shell environments roles are only allowed to run commands within the dzsh shell. Within the restricted
shell, a user can only be in one active role at a time to prevent ambiguity about the commands the user can run or the user account that should be used to
execute those commands.
For example, if the user carol is assigned to the lab_staff restricted shell environment role that specifies the tar command should run as root and to the
temps restricted shell environment role that specifies the tar command should run as tmp_admin, she needs to specify which role she is using to run the tar
commands under the proper account.
Within the restricted shell, users can switch between available roles, as needed, using the built-in role command. If a user has been assigned to the
backup_ops role and the dev_managers role, he can run the role command to specify which role should be active so that only commands from that role apply.
For example, to switch from the backup_ops role to the dev_managers role:
$ role dev_managers
Role changed to: dev_managers
For more information about using the role option in a restricted shell, see the man page for dzsh.
Viewing available roles
The dzinfo command enables users to view information about the roles they have available and what they are allowed to do within their different roles. You
may want to add this command to all of your restricted environment roles to allow users to check their definitions and availability within the authentication
and privilege elevation restricted environment shell.
For more information about using the dzinfo command, see the man page for dzinfo.
Using a graphical desktop manager in a restricted environment
In some operating environments, users who are placed into a restricted environment may not be able to log on using a graphical user interface desktop
manager unless they are explicitly given permission to run the desktop manager or related commands within the dzsh restricted environment. For example,
on Red Hat Linux, users must be allowed to run /usr/bin/dbus-launch to log on using KDE or Gnome desktop manager.
To allow restricted environment users to log on using KDE or Gnome on Red Hat, you must add dbus-launch to the list of allowed commands for the restricted
environment user’s role. If you want to prevent restricted environment users from logging on using the graphical user interface, you can restrict their access
to specific PAM-enabled applications such as ssh.
Defining rights to use PAM applications
As discussed in Basic concepts of access rights and roles, access rights allow users to perform specific operations. You define the most basic rights—such as
the right to log on or connect remotely—when you define roles. To use the rights associated with a role, however, you must be able to authenticate your
identity through a pluggable authentication module (PAM) application, such as login or ssh. This chapter describes how to define PAM application rights that
authorize users to log on or access services on Centrify-managed computers.
How applications determine access rights
Most of the programs you run on Linux and UNIX computers are configured to use a pluggable authentication module (PAM) to control access. For example,
the login, secure shell (ssh), and file transfer (ftp) services are all PAM-enabled programs. These programs check the local PAM configuration to determine
whether a user is allowed to use the requested service.
When you install the Centrify Agent and join a domain, you replace the default PAM authentication service with a PAM service that looks for the users and
groups to allow or deny access to in Active Directory. Because the PAM service is the first “gatekeeper” to access on most computers, users must have at
least one PAM access right to log on at all.
Default PAM access rights
By default, Access Manager creates three predefined PAM access rights in every parent and child zone:
This
PAM Grants access to
right
All PAM applications on a computer joined to the domain. Adding the login_all PAM access right allows users to log on and use any PAM-enabled
login-
application. The right uses the wild card (*) character to match all PAM application names and is included by default in the predefined UNIX Login
all
role.
Secure shell sessions on Debian and Ubuntu 6 and 7. Adding the ssh PAM access right allows users to log on remotely using secure shell
ssh
connections on Debian and Ubuntu computers joined to the domain.
Secure shell sessions on all Linux and UNIX computers except Debian and Ubuntu 6 and 7. Adding the sshd PAM access right allows users to log on
sshd
remotely using secure shell connections on all other distributions of Linux and UNIX computers joined to the domain.
Adding Specific PAM Access Rights
PAM access rights control who can access specific PAM-enabled applications in the zone where they are created and any child zones of that zone. You can
add as many PAM Access rights as you need to identify the specific PAM-enabled applications users can access. For example, you can add PAM access
rights to control who can use file transfer protocol (ftp) services on specific computers.
If you want to grant rights to specific PAM applications, however, you must know the appropriate application name on the specific computers you support. For
example, if you want to allow Active Directory users to log on and use a default shell, you might create a PAM access right for the login program and for a
graphical desktop manager such as gdm.
What to do before creating a new access right
Before creating a new PAM access right, you should review the operating system of the computers in the zone where you plan to create the new right. The
application name might be different on computers with different operating systems. If you are creating separate rights for individual PAM applications, keep
in mind that users must have at least one PAM access right or they will not be able to log on to any computers.
You can create new PAM access rights if you have been delegated the “Manage roles and rights” administrative task in the Zone Delegation Wizard. If you
have not been delegated this task, your user account must be a domain user with the following permissions:
Authorization
AzApplicationData
msDS-OpObjectContainer This object is listed under a On the Object tab, select Allow to apply the following permissions to this object: Create msDS-
globally unique identifier (GUID) for the Authorization AzOperation objects Click the Properties tab, then select Allow for the following properties:
object. Read objectClass
In most cases, a UNIX administrator or a delegated zone administrator familiar with PAM applications and the operating system of the managed computers
performs this task, depending on your organization’s policies.
It is common to add new PAM access rights over time as the need arises and as you develop more granular control over the specific rights different users
should be granted.
The following instructions illustrate how to add a PAM access right using Access Manager. Examples of scripts that use the Access Module for Windows
website.
To define a PAM access right using Access Manager:
2. Expand Zones and the individual parent or child zones required to select the zone name that will contain the new PAM access right.
3. Expand Authorization, then expand UNIX Right Definitions.
5. Type a name for the access right.
The name of the access right can be the same as the PAM application name, or any name that is easily identifiable.
6. Type the name of the PAM-enabled application for which you want to create an access right.
You can use wildcards to perform pattern matching for the application name. For example, you can specify *ftp* to match all PAM-enabled applications
containing the string ftp, such as vsftpd, ftpd, and ftp.
The Application Name field supports glob pattern matching syntax. For example, the name can contain a question mark (?) to represent any single
character, an asterisk (*) to represent any string, including an empty string, or an expression enclosed by brackets ([. . .]). For more detailed information
about using wildcard patterns and glob syntax, see the glob man page.
You should note that application names vary depending on the local operating system where the application is accessed. For example, the following
table lists several common PAM-enabled applications and the appropriate application name to use on different platforms.
For this application On Use this name
telnet Common Linux platforms, such as Red Hat, Debian, SuSE, Centos, and Ubuntu, HP-UX, and Irix login
Sun Solaris telnet
VMware ESX, Oracle Linux, Scientific Linux remote
ftp Common Linux platforms, such as Red Hat, Oracle Linux, and Scientific Linux, and VMware ESX vsftpd
Some Linux platforms, such as Debian, Centos, and Ubuntu, Sun Solaris, HP-UX, Irix ftp
graphical desktop Common Linux platforms, such as Red Hat, Debian, Oracle Linux, Centos, Scientific Linux, and Ubuntu gdm
Sun Solaris and HP-UX dtlogin
SuSE and Irix xdm
ssh Most platforms sshd
Debain and Ubuntu ssh
1. Type an optional description of the access right.
2. Click O K to save the PAM access right.
What to do next
After you define a new PAM access right, you might want to create a new role definition and add this right to it in the current zone or in a child zone. You must
add the right to a role to test its operation.
Modifying an existing PAM access right
After you have created and tested a new PAM access right, you might want to modify the right name and description, or the pattern used to match the
application name. For example, if you add computers with a different operating system to the zone where the PAM access right is defined, you might have to
modify the application name to use wild card characters.
To modify a PAM access right using Access Manager:
2. Expand Zones and the individual parent or child zones required to select the zone name that contains the PAM access right.
3. Expand Authorization, UNIX Right Definitions, and PAM Access.
4. Select the PAM access right to modify, right-click, then click Properties.
5. Change the right name, application name, or description for the access right, then click O K.
Copying a PAM access right
You should keep in mind that PAM access rights are specific to the zone where you create them. They can be added to any roles you define for the zone or to
roles defined in any child zone of the zone. After you define PAM access rights in a zone, however, you can also copy and paste or drag and drop the rights
from one zone to another, as needed.
To copy a PAM access right using Access Manager:
4. Select the PAM access right to copy, right-click, then click C o p y.
5. Navigate to the PAM Access node in the new zone, right-click, then click Paste.
Deleting a PAM access right
If you are no longer using a specific PAM access right in any roles, you might want to delete the right. For example, if you create new rights for testing
purposes and found some of them were not appropriate or failed to work as expected, you might want to delete the rights you aren’t going to use.
To delete a PAM access right using Access Manager:
4. Select the PAM access right to delete, right-click, then click Delete.
Renaming a PAM access right
If you only need to change the name of a PAM access right, you can rename the right at any time without modifying the description or the pattern used to
match the application name.
To rename a PAM access right using Access Manager:
4. Select the PAM access right to rename, right-click, then click Rename and type a new name for the access right.
Using PAM-enabled applications
The default UNIX Login role includes the predefined login-all PAM access right to enable users to log on and access any PAM-enabled application. If you
define specific PAM access rights, users who are assigned a role with that right can only access the specifically authorized PAM-enabled applications. For
example, users who are assigned to a role that includes the right to access FTP (ftpd) can connect to the FTP server by typing a command similar to the
following:
ftp ginger.ajax.org
Requiring multi-factor authentication for PAM applications
If you select the “Multi-factor authentication required” system right in a role definition, the PAM applications you add to the role will require users to select a
secondary form of authentication to log on successfully. You define the forms of authentication available and presented to the user in the authentication
profile you have configured using the administrative portal for the Centrify Platform. For example, you might configure an authentication profile that require
users to answer a phone call, click a link in an email message, or respond to a text message.
Note that some applications do not support multi-factor authentication and users might be denied access to applications that they would otherwise be able
to use. For example, if a specific version of an application that you want to use only supports a single layer of authentication—such as a password challenge—
users would be prevented from logging on and using the service even if they are assigned to a role with the predefined login-all PAM application right.
If you want to grant access to applications that only support one layer of authentication in roles where you are generally using the “Multi-factor
authentication required” system right, you must add those applications to the list of applications for which you want to skip multifactor authentication. You
can update the list of applications for which to skip multifactor authentication by enabling and modifying the “Specify programs for which multi-factor
authentication is ignored” group policy or setting the pam.mfa.program.ignore configuration parameter in the centrifydc.conf file.
Before assigning roles with multi-factor authentication required to users, you should test access to all of the applications you expect users to access to verify
they won’t be unexpectedly denied access simply because multi-factor authentication isn’t supported. Because the applications that don’t support multi-
factor authentication will depend on the platforms and the versions of the applications you plan to support, testing in your own environment is the only way to
determine which applications to add to the pam.mfa.program.ignore configuration parameter.
The most common applications that are known to only support a single password challenge and response for authentication are ignored for multi-factor
authentication by default. For example, some versions of java and vsftpd do not support multi-factor authentication and are ignored by default.
Additionally, while some platforms support multi-factor authentication for all PAM applications, they may not allow you to require multi-factor authentication
for GUI log in. For example, for users running AIX, Solaris, and HP-UX, multi-factor authentication for GUI login is not supported.
Options applied to the Centrify PAM module
The authentication service applies some options to the Centrify PAM module pam_centrifydc module. For example, in a RHEL system, you would see the
following in the /etc/pam.d/system-auth file:
auth sufficient pam_centrifydc.so
auth requisite pam_centrifydc.so deny
account sufficient pam_centrifydc.so
account requisite pam_centrifydc.so deny
session required pam_centrifydc.so homedir
password sufficient pam_centrifydc.so try_first_pass
password requisite pam_centrifydc.so deny
In addition, you could see the following in the /etc/pam.d/su file:
auth sufficient pam_centrifydc.so enable_dzpamgate
For each management group, a set or stack of modules can be defined and used in turn. When an application calls the PAM library function (for example to
authenticate), the PAM runtime will call each authentication function in each module— one at a time like cards from a stack. The order of calling is
determined by the order in the configuration (service) file.
Be careful when changing the order in the stack; changing the order might have impact on the functionality considerably.
There are four types of PAM services:
Authentication service modules
Account management modules
Session management modules
Password management modules
There are four control flags:
Requisite: The requisite flag is probably the strongest of the flags. If a module is flagged as requisite, and it fails (returns not-OK), PAM will return to
the calling application instantly and report the failure.
Required: The return code for a required module is stored. In the case of failure, execution is not stopped but continues to the next module. When the
stack of modules has been executed, and at least one required module has failed, PAM will return failure to the calling application. Moreover, the failure
is associated with the first failing module) The required control flag is useful in keeping unauthorized persons out of your computer, particularly since
the other modules in the stack are applied as well.
Sufficient: A sufficient module can actually be quite strong. The processing of the stack is stopped if a sufficient module returns OK, if no previous
required module has failed. If there are required modules after the sufficient modules, these modules are not called.
Optional: When a module is flagged as optional, a failure does not alter the execution of the stack as in the case of the requisite flag. Moreover, the
return code is ignored, and neither failure nor success is taken into account.
The list of options that are applied to pam_centrifydc are as follows:
Deny: When it gets to this line, it will just deny the request
Try_first_pass, use_first_pass, get_first_pass: All three follow PAM standards.
Try_first_pass: Use the password from the previous stacked authentication module, and prompt for a new password if the retrieved password is blank
or incorrect.
Use_first_pass: The default is to use the old password saved by a previous module, or if none, to ask for it. With use_first_pass it fails if there is no old
password.
Requisite: This is an HP platform only option. The effect is the same as HP "pam requisite"
Unix_cred: This is Solaris only option to provide Solaris's pam_unix_cred
Homedir: Create user home directory
Enable_dzpamgate: This is a Centrify option to seal a potential pam security hole. In some systems, pam account module does not always gets called so
the authorization checking in auth module is inserted with the enable_dzpamdate option.
In /etc/centrifydc/centrifydc.conf, the parameter equivalents are provided as:
pam_mkhomedir.so [umask=mode] [skel=skeldir]
pam.homeskel.dir: /etc/skel
To update the parameters, remove the # sign and change values as desired.
Using secure shell session-based rights
As discussed in Default secure shell (SSH) access rights, Access Manager includes predefined secure shell rights that enable you to identify
the specific secure shell services that a user who has the PAM SSH access right can run. This chapter describes how to use the secure shell (ssh) session-
based rights that control the operations specific users or groups can perform on Centrifymanaged computers.
Secure shell rights require Centrify OpenSSH
SSH has become the defacto standard for administrators and users to securely access remote UNIX systems. The combination of the latest versions of
OpenSSH supporting Kerberized connections, along with the DirectControl Agent directly integrating the UNIX computer with Active Directory's Kerberos
infrastructure, provides the administrator with the ideal environment for secured single sign-on. Users logging in from Windows computers can securely
access remote UNIX computers using their Active Directory credentials to automatically log in to the UNIX computer.
While many UNIX systems might have an sshd server installed, most are older implementations of the sshd server that do not support Kerberos and newer
versions might not have been compiled with support for Kerberos. The Centrify package contains OpenSSH compiled with support for Kerberos by
dynamically linking to the Centrify Kerberos libraries to ensure that single sign-on works seamlessly as expected in an Active Directory environment.
This provides several advantages, including:
The OpenSSH client and server are preconfigured to automatically support PAM and Kerberos.
There is no need for DNS-to-realm mapping because DirectControl knows the relationship between hosts and their SPNs.
There is no need for a .k5login file in the user's home directory since DirectControl can automatically map the UPN (User Principal Name) in the
Kerberos ticket to the UNIX profile for the Active Directory username presented in the ticket.
OpenSSH in combination with DirectControl accepts connections to any of the computer's valid hostnames, either fully qualified or not, because all
combinations are registered with Active Directory. This further reduces the dependency on accurate DNS entries to enable Kerberos to operate
properly.
The installation process automatically updates the $PATH.
The Centrify version of OpenSSH is a separate package that can be installed with the Centrify Agent. Before you configure any specific secure shell rights to
include in roles, verify that you have the Centrify OpenSSH package installed on your managed computers. The default secure shell rights are only applicable
for the Centrify-compiled version of OpenSSH. If you did not select the OpenSSH package as part of a custom installation when you installed the agent, re-
run the installation script to install the package before attempting to use secure shell rights.
Secure shell rights require PAM access rights
Before you configure any specific secure shell rights, you should also identify the PAM access right to use. The predefined PAM access right sshd—or ssh for
Ubuntu computers—grants users permission to log on and use all secure shell services on Centrify-managed computers. You must grant the sshd, ssh, login-
all, or a custom PAM access right before you can use any secure shell (SSH) rights to restrict access to specific services.
The SSH access rights only work in conjunction with the PAM access right that allows a user to log on using a secure shell session. If a user is not assigned to a
role that grants the PAM access right to log on using a secure shell, SSH rights are ignored.
When a user attempts to log on using a secure shell session, adclient first verifies that at least one role in effect for the user has the PAM access right that
allows him too log on using SSH. If a PAM access right is in effect, adclient checks to see which specific SSH rights the user has before allowing or denying the
action the user is attempting.
Combining secure shell rights
You can add predefined SSH rights to any role that can be assigned to Active Directory users and can combine different rights for fine-grain control over the
specific secure shell operations users are allowed to perform. For Linux and UNIX computers, only the following predefined secure shell session-based rights
are available:
dzssh-all grants access to all secure shell services.
dzssh-direct-tcpip allows local and dynamic port forwarding (ssh-L, ssh -D).
dzssh-exec allows command execution.
dzssh-scp allows secure copy (scp) operations.
dzssh-sftp allows secure file transfer (sftp) operations.
dzssh-shell allows secure terminal (tty/pty) connections.
dzssh-Subsystem allows an external subsystem except sftp subsystem which has its own right.
dzssh-tcpip-forward allows remote port forwarding (ssh -R).
dzssh-tunnel allows tunnel device forwarding.
dzssh-X11-forwarding allows X11 forwarding.
When combining rights into role definitions, you should keep in mind that some secure shell operations require you to explicitly include the dzssh-exec right.
For example, if you include the dzssh-scp right in a role definition, a user might attempt to execute an arbitrary program with a command line similar to
following:
ssh troll@localhost scp -S/home/troll/script " -f "
Because this command line presents a potential security risk, the operation is not allowed. To prevent the dzssh-scp right from being used on its own to
execute an arbitrary program on a remote computer, the -S command line option is only supported if you also include the dzssh-exec right in the role
definition. Similarly, you must explicitly include the dzsshexec right in a role definition if you want to support using the dzssh-sftp right with the -S command
line option. For security reasons, only the dzsshexec right allows the remote execution of a program on a target computer.
If the dzssh-exec right is not included in the role definition when it is required, users will see an “access denied” message.
You should note that you cannot add any secure shell rights to role definitions that allow local users. You can only include them in role definitions for Active
Directory users.
Configuring secure shell settings
You can use Centrify group policies to manage several aspects of secure shell (ssh) authentication and operation. The Centrify group policies for secure shell
are located in the SSH Settings folder after you add the centrify_unix_settings.xml administrative template to a Group Policy Object. When you enable and
configure secure shell group policies, the changes are recorded in the secure shell configuration file, /etc/centrifydc/ssh/sshd_config, at the next group
policy update interval. To have your changes take effect immediately, run the adgpupdate command.
Centrify puts all of the configuration files for secure shell operations in the /etc/centrifydc/ssh directory. Depending on your operating system, you might also
have other ssh configuration files stored in the other locations. When users start a secure shell session and use their secure shell rights, the Centrify Agent
first checks the /etc/centrifydc/ssh directory for configuration files, then looks for configuration file in the /usr/local/etc directory on AIX computers, and in
/etc/ssh directory on most other Linux and UNIX computers.
At a minimum, you should enable the Enable application rights group policy in a Group Policy Object that applies to the site, domain, or organizational unit
that contains Centrify-managed Linux and UNIX computers.
To configure the secure shell group policy for application rights
1. On a Windows computer, open the Group Policy Management console.
2. Select an appropriate Group Policy Object, right-click, then select Edit.
You can select any Group Policy Object that applies to the site, domain, or organizational unit that contains Centrify-managed Linux and UNIX
computers.
3. Expand Computer Configuration > Policies > Centrify Settings > SSH Settings and double-click Enable application rights.
4. Click Enable, then click OK.
This setting adds the following parameter to the /etc/centrifydc/ssh/sshd_config file:
This parameter sets the path to the dzsshchk command. The dzsshchk command verifies the access rights for users when they log in with SSH for all
computers to which the group policy object applies.
You can also use secure shell group policies to control other configuration settings, such as the allowed and denied groups and users and authentication
processing. For example, you can use the following group policies to configure operations for Centrify OpenSSH connections:
Add sshd_config properties enables you configure secure shell properties defined in the sshd_config file by group policy. If you enable this group
policy, you can add and edit properties as name-value pairs.
Allow challenge-response authentication enables you use multi-factor authentication if you are using the secure shell package installed with
the operating system. This group policy is not required if you are using the Centrify OpenSSH package for the agent.
Allow groups specifies the list of groups whose members are allowed to log on through sshd.
Allow GSSAPI authentication enables authentication either as the result of a successful key exchange, or through GSSAPI user authentication.
Allow GSSAPI key exchange enables authentication using a key exchange based on GSSAPI.
Allow users specifies the list of users who are allowed to log on through sshd.
Deny groups specifies the list of groups whose members are not allowed to log on through sshd.
Deny users specifies the list of users who are not allowed to log on through sshd.
Enable application rights allows secure shell applications to grant secure shell rights.
Enable PAM authentication to use PAM account and session handling.
Permit root login specifies whether the root account can be used to log in using ssh.
Set banner path specifies the path to a local file that is sent to a remote user requesting authentication.
Specify authorized keyfile specifies the file that contains the public keys that can be used for user authentication.
Specify ciphers allowed for protocol version 2 enables you to add or delete ciphers allowed for single sign-on connections.
Specify client alive interval specifies a timeout interval, in seconds, for requesting a response to client alive messages.
Specify log level specifies the level of detail to record in the log file for messages from sshd.
Specify login grace period specifies the time, in seconds, after which the server disconnects if a user has failed to log in.
Specify maximum client alive count specifies the maximum number of client alive messages that may be sent by the secure shell daemon (sshd)
without receiving a response from the client.
For more information about adding administrative templates for group policies to a Group Policy Object and how to configure and apply the group policies for
secure shell, see theGroup Policy Guide.
Configuring secure shell parameters
The following parameters apply to specific usage for SSH.
ServiceAuthLocation
Uncomment this line in sshd_config to enable the SSH application right feature. Refer to the pre-defined scp, sftp, and winscp for how to utilize this feature.
Default is disable.
AuditSshCommandline
Set this parameter in sshd_config to yes if the command line options are displayed in the audit trail message. Default is no.
krb5ccUnique
Set this parameter to yes to specify when storing the Kerberos credentials cache. Centrify sshd generates a unique credential cache name for it. If this
parameter is set to no, the old style credential cache name, krb5cc_<uid> or KCM:<uid>, is used.
SSOMFA
Set this parameter is yes to support Single Sign-On (SSO) with Multi- Factor Authentication (MFA). The MFA order is determined by the
AuthenticationMethods keyword in sshd_config. This keyword works only when UsePAM is enabled and the Centrify keyword ServiceAuthLocation is set.
Default is no.
Note: MFA is not supported for authentication using public key.
Access rights and role definitions are intended to give you maximum flexibility to grant or restrict access for the users and groups in your organization. This
chapter describes how you can configure role-based access controls for Centrify-managed computers by adding custom access rights to custom role
definitions and assigning those custom role definitions to users and groups. This chapter provides examples to illustrate how you can create and assign
custom role definitions. The authorization scenarios you can support might be far more complex than the examples described in this guide.
Combining rights into role definitions
Rights can be combined in a variety of ways to accomplish different goals. In general, however, role definitions fall into one of these broad categories:
Roles that grant access to one or more PAM applications and a standard UNIX shell.
With this type of role, Active Directory users can log on using all or a specified PAM application, such as login or ftp, and execute commands that are
commonly available to non-administrative users. This type of role can only be assigned to Active Directory users or groups.
Roles that grant users additional privileges to execute administrative commands and perform administrative tasks they would not be able to perform
with a standard user account.
With this type of role, users can temporarily elevated their privileges to execute administrative commands by first invoking the dzdo command, which is
similar to sudo. This type of role can be assigned to Active Directory users or to local users.
Roles that provide access to a specific subset of shell commands in a customized restricted environment shell (dzsh).
With this type of role, users can execute the commands explicitly defined for them in a restricted shell environment. This type of role can be assigned to
Active Directory users or to local users.
In preparing role definitions for different groups of users, you should keep in mind that the rights from multiple role assignments accumulate. For example,
you could use one role definition to control login rights, and another role definition to specify a set of privileged commands. By separating login rights from
privileged access rights, not every role definition requires PAM application or UNIX system rights.
Creating a root-equivalent role definition
Most organizations require at least one root user role definition that is equivalent to specifying ALL:ALL in a sudoers file or giving users access to the root
password on their computers. The purpose of this role definition is to allow selected users to execute privileged commands on a regular basis. The role
definition allows them to execute commands without being given the root password or having privileges hard-coded in individual sudoers files on multiple
computers.
Because this role definition enables system administrators to execute privileged commands without the root password, you can improve security for the
organization and reduce the chance of an audit finding for access to the root password.
You can create this role definition in a parent zone or a child zone to control its scope. In most cases, you should only assign the role in a child zone or on an
individual computers.
Define the right for running all commands
Rights and roles are defined at the zone level and inherited down the zone hierarchy. If you define a right in the top-level zone, it is available in all child zones. If
you define a right in a child zone, it can be used in that zone and any of its child zones. Similarly, you can define roles in the top-level parent or any child zone,
depending on where you want to make the role available. In this example, the right to run all commands as the root user is defined in a toplevel parent zone.
The following instructions illustrate how to define a right for running all commands using Access Manager. Examples of scripts that use the Access Module
for Windows PowerShell, ADEdit, or the Centrify Windows API are available in other guides, the Centrify Software Developer’s Kit, or in community forums on
the Centrify website.
To define a right for running all commands as root:
For this example, select the top-level parent zone so that this command right is available in all child zones.
5. On the General tab, type a name for this command right and, optionally, a description for this right, then define the right to run all commands like this:
Type an asterisk (*) in the Command field to indicate all commands are allowed.
Select Specific path and type an asterisk (*) in the field to indicate that any path is allowed.
6. Click the Restricted Shell tab and deselect the Can be used in a restricted role option if you want to prevent this command from being used in a
role that uses a restricted shell environment.
7. Click the Run As tab to verify the command can be used with dzdo and is set to run as root by default.
Create a role definition for running all commands
After you have defined the right to allow a user to run any command with root privileges, you can create a role definition for that right. You must create a role
definition somewhere in the zone hierarchy before you can assign users to the role.
To create a role definition with the right to run all commands as root:
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to create the role definition.
For example, type a name such as root_equivalent and descriptive text such as Users with this role can run any command with root privileges.
Optionally, you can select Allow local accounts to be assigned to this role if you want to assign both Active Directory users and local users to
the role. This option is only available when you first create a role definition. You can also click Available Times if you want to limit when the role is
available for use. By default, roles are available at all times.
If you using the UNIX Login role to grant access to computers in the zone and want to use the default auditing level of Audit if possible, you can click
O K then skip to Step 8.
6. If you are not assigning the UNIX Login role to grant access to computers, click the System Rights tab and select the following options:
Note that you cannot set these system rights if you selected the option to allow local users to be assigned to this role.
7. If you don’t want to use the default auditing level, click the Audit tab.
Select Audit not requested/required if you have the auditing service enabled but don’t want to audit user activity when this role is used.
Select Audit if possible to audit user activity where you have the auditing service enabled.
Select Audit required to always audit user activity. If the auditing service is not available, users in this role are not allowed to log on.
9. Select the right you defined for running all commands as root, then click O K.
Assign an Active Directory group to the role
You should associate Centrify role definitions with Active Directory security groups so that you can manage them using the processes and procedures you
have for managing Active Directory group membership. For example, create an Active Directory group named sanfrancisco_role_rootequivalent. You can
then assign the new role definition to that group.
5. Select the role definition you created for root-level access, such as root_equivalent, then click O K.
6. Click Add AD Account to search for and select the Active Directory security group you created for the role.
Click Find Now,
Creating a role definition for a shared service account
The root-equivalent role definition provides centralized management for a limited number of administrators who have permission to execute all commands
on selected computers. Another common reason for defining a role is to execute privileged commands associated with a service account. In many
organizations, service account passwords are known by multiple users, making them a security risk. For example, all of the database administrators in the
organization might know the password for an oracle service account, an account with permission to perform privileged database operations. Because the
password is shared information, it presents a security risk and a potential audit finding that might have costly consequences.
Setting up a role definition for a service account involves creating a command right for switching to the service account user and defining a PAM access right
for role.
Define the right for switching to a service account
The steps for defining a right for switching to the service account user are similar to defining the rights for the root-equivalent user, but the definition is more
restrictive.
To define a right for switching to a service account:
5. On the General tab, type a name for this command right and, optionally, a description for this right, then define the right to switch to the service
account.For example, if the service account is oracle:
Type su - oracle in the Command field.
Verify the Standard user path is selected.
6. Click the Restricted Shell tab, under Can be used in a restricted role, select Specific user or uid, then type root.
7. Click the Run As tab, deselect Can be used by dzdo.
These settings specify that this right can only be used in a restricted shell environment and users can only run the commands that are explicitly allowed
in the restricted role they are assigned. If this is the only right defined for a role, the only command users assigned to the role can run is su - oracle. For a
role definition with this right to be effective, you would add command rights for the specific database operations users should be allowed to perform
after switching to the oracle service account. For example, if the oracle service account is used to run a backup-all-dbs script, you would add a right to
allow the execution of that script.
Define a PAM access right to allow logging on
The default UNIX Login role allows users to log on using a password or without a password in an unrestricted environment. If you are creating a role for a
service account, you can use PAM access rights to control the specific commands users can use to log in. To illustrate controlling how users log on, this
example of a restricted role for the oracle service account only allows users to log on with ssh.
To define a PAM access right for a specific application:
2. Expand Zones and the individual parent or child zones required to select the zone name where you want to create the new PAM access right.
5. Type a name and, optionally, a description of the PAM application for which you are adding an access right.
For the Application field, type the platform-specific name for the PAM application as defined in the PAM configuration file or PAM directory. For
example, type ssh or sshd. You can also use wildcards in this field to perform pattern matching for the application name.
6. Click O K to save the access right for this PAM-enabled application.
Create a restricted role definition for the service account
After you have defined the rights that allow a user to log on using a PAM-enabled application and run the su - command for a service account, you can create
a role definition for these rights. You must create a role definition somewhere in the zone hierarchy before you can assign users to the role.
To create a restricted role definition for switching to a shared service account:
For example, type a name such as oracle_service and descriptive text such as Users with this role can start a secure shell session and switch to oracle.
By default, this role is available at all times. You can click Available Times if you want to specify days of the week or select times of the day for making
the role available.
6. Click the System Rights tab and select at least one option that allow users assigned to this role definition to log on, then click O K.
In this example, users open a secure shell to switch to the service account so you might select Non-password (SSO) login is allowed.
If a service account instead of a user account is used to log on, it might be mapped to a disabled Active Directory account. In this case, you might select
the Account disabled in AD can be used by sudo, cron etc system right to ignore the disabled state and allow the service account to log on.
8. Select the rights you defined for running the switch user (su -) command and logging on with the PAM application ssh, then click O K.
Assign an Active Directory group to the role
You should associate Centrify role definitions with Active Directory security groups so that you can manage them using the processes and procedures you
have for managing Active Directory group membership. For example, create an Active Directory group named sanfrancisco_role_oracle. You can then assign
the new role definition to that group.
5. Select the role definition you created for using secure shell and switching to the service account access, such as oracle_service, then click O K.
6. Click Add AD Account to search for and select the Active Directory security group you created for the role definition.
Click Find Now.
Working in a restricted shell environment
When users who are assigned to this role want to open a secure shell session and switch to the oracle service account, they will be placed in a restricted shell
environment. Within the restricted shell, they can only execute the commands you have added to the role definition until they exit the restricted shell session.
In this example, the role definition only allows users to log on using ssh and execute one command, su - oracle. If those users are also assigned the UNIX Login
role, they will have access to an unrestricted shell when they close the restricted shell session.
If you want users who access a shared service account to work exclusively within the restricted shell environment, you must remove the UNIX Login role
assignment in the zone or on the computer where they should only have restricted shell access. Before removing the UNIX Login role assignment, however,
you should consider the trade-off between improved operational security and audit compliance and reduced operational access. Depending on the rights you
add to a role that runs in a restricted shell environment, the restricted shell can dramatically limit what users can do.
Testing access in a restricted shell
If you create a role definition for a shared service account that runs in a restricted shell environment, you should test it before migrating any users to it. You
can use the dzinfo command with the --test option from a UNIX command prompt. For example, type dzinfo, the user name to test, the --test option, then the
full path to the command to test:
dzinfo raejames --test “/usr/bin/su - oracle
You can also run the dzinfo command with the --roles option to see information about the rights defined for the current user or a specified user. For example,
run the following command to check the roles and rights defined for the user raejames:
dzinfo raejames --roles
For more information about using this command, see the dzinfo man page.
What users see in a restricted shell environment
For users assigned to a role that runs in a restricted shell, logging on opens a dzsh shell. Within that shell users can only execute the commands you have
explicitly defined for them. In this example scenario for a shared service account, typing su - oracle is the only allowed command. If the user types any other
command, the shell reports that the command is not allowed.
Define a command that allows root access
The steps for defining a right for switching to the root user are similar to defining the right to run commands for the root-equivalent user, but Centrify
recommends you create a separate right definition for this case.
5. On the General tab, type a name, such as emergency_access, for this command right and, optionally, a description for this right, then define the right to
switch to the root user:
Type the command for switching to the root user. For example, type su - root in the Command field.
Create a role definition for temporarily running as root
After you have defined the right to switch to the root user, you can create a role definition for that right.
To create a role definition with the right to run the emergency_access command:
For example, type a name such as emergency_access and descriptive text such as Users with this role can temporarily run commands with root
privileges.
6. Click Available Times to specify days of the week or select times of the day for making the role definition available.
For example, you might want to allow access only on Friday, Saturday, and Sunday and deny access the rest of the week. After you have set the days and
times for the role definition to be available, click O K.
9. Select the emergency_access command you defined for switching to the root user, then click O K.
To use this role, a user must be assigned to the UNIX Login role for the zone or a role definition that has at least one UNIX system right, such as Password
login and nonpassword (SSO) login are allowed.
Assign the role as a computer-level override
In most cases, a role definition of this type is assigned to a specific computer rather than applied to all computers in a zone.
To make a role assignment on an individual computer:
2. Expand Zones and the individual parent or child zones required to select the zone name that contains the computer for which you want to define a
computer-level role assignment.
3. Expand Computers, then select the specific computer on which you want to make a role assignment.
5. Select the role definition you created for temporary root access, such as emergency_access, then click O K.
6. Click Add AD Account to search for and select the Active Directory user who should have temporary root access:
Leave User as the object to find.
Optionally, type all or part of the use name.
Click Find Now.
Select the user in the results, then click O K.
7. Deselect Start immediately and set a specific Start time for the role assignment.
8. Deselect Never expire and set a specific End time for the role assignment.
9. Click O K.
Verify the role assignment on the computer
You can run dzinfo --roles or dzinfo username --roles to see if the emergency_access role is available based on the start time for the role definition and the
local time of the Linux or UNIX computer.
At the specified start time for the role assignment on the local computer, the user you assigned to the emergency_access role can type the following
command:
dzdo su - root
The user is not prompted to provide the password and becomes the root user on the local computer until the specified role assignment end time. The one
caveat to be aware of is that the user would continue to have root access after the specified end time if the shell session remains open continuously. If a user
is still logged on after the time period has expired, you should check whether the user still requires root-level access. If the session has remained open but the
user should no longer have root access, kill the session and log the user off.
Creating a role definition with specific privileges
The previous examples of role definitions granted broad privileges. You can also use role definitions grant or deny very specific rights. For example, you might
want to deny access to a specific set of commands for a specific group of administrators who otherwise have broad access rights or to strictly limit exactly
what commands users can execute. Depending on the requirements of your organization, you might configure these types of role definitions to be used in a
restricted or unrestricted shell.
The steps for creating a role definition with specific privileges are similar to the steps for creating the other roles. In this example, rights are defined to
prevent the execution of specific commands and combined with a right to grant access to all commands not explicitly listed.
Define command rights to prevent the use of commands
The steps for defining rights that deny access to specific commands are similar to the steps defining other rights, but require different syntax. In this
example, you create a “blacklist” of commands users cannot execute.
5. On the General tab, type a name, such as No password resets, for this command right and, optionally, a description for this right, then define the right:
Type !passwd * in the Command field.
An exclamation point (!) at the start of a command disallows matching commands. Command rights that start with the exclamation point take
precedence over others that don’t.
8. Repeat Step 4 to Step 7 to create rights for the following specific commands:
!groupadd *
!useradd *
!groupdel *
!userdel *
Create a restricted shell role definition that uses the command rights
After you have defined all of the command rights that disallow specific commands, you can create one or more role definitions to use those rights. For
example, you might create one role definition to run in an unrestricted shell that requires users to invoke dzdo to execute privileged commands and another
role definition that runs in a restricted shell but does not require users to execute privileged commands using dzdo. The second role might be useful if you
have existing scripts that would have to be modified if invoking dzdo is required.
To create a role definition for specific command rights:
For example, type a name such as operators and descriptive text such as Users with this role can run privileged commands but not reset passwords, add
or delete users and groups.
6. Click System Rights if you want this role definition to be used in a restricted shell environment as a replacement for the predefined UNIX Login role.
To use this role, a user must be assigned to a role definition that has at least one login system right, such as Password login and nonpassword (SSO)
login are allowed or Nonpassword (SSO) login is allowed.
9. Select all of the command right that disallow specific operations, the command right that grants access to all remaining commands, and a PAM access
right, then click O K.
For example, you might add the following previously-defined command rights to this role definition:
No password resets
No user adds
No group adds
No user deletes
No group deletes
Root like access (* for all commands not explicitly disallowed)
PAM ssh/login allowed
This role definition allows members of the operators role to execute any command within a restricted shell environment except those explicitly
disallowed, including privileged commands, without invoking dzdo first. You can assign the role definition to the appropriate Active Directory users or
groups like the previous role definitions.
Create an unrestricted shell role definition that uses the command rights
The command rights were configured to allow execution in either a restricted shell environment or an unrestricted shell environment. In an unrestricted shell
environment—for example, the default shell environment when users are assigned the UNIX Login role—commands that require administrative privileges
must be executed by first invoking the dzdo command, which is similar to invoking commands with sudo.
You can control whether users are required to enter a password or another form of authentication when they execute privileged commands using dzdo by
setting one of the Re-authenticate options on the Attributes tab when you create a command right. By default, no password is required. If you were adding
a new command right that requires reauthentication, you would click the Attributes tab, then select Re-authenticate current user or Re-authenticate
using target user’s password. For more information about these options, see Requiring re-authentication to run commands.
In most cases, the default of no password is appropriate because the user has been previous authenticated before invoking dzdo to execute a privileged
command and the Reauthenticate using target user’s password option requires the user to know the privileged account password. For example, if
select this option and the run-as user is root, the user must know the password for the root account.
The steps for creating the role definition that includes the previously-defined command right are the same for the unrestricted shell as for the restricted shell
except that, at Step 6 in the topic Create a restricted role definition for the service account, in the System Rights tab you would also select the Login with
non-Restricted Shell option if you are not using the UNIX Login role. You could add all of the same command rights to the role definition and grant the
same privileges and exceptions.
The primary difference between the two role definitions would be how users execute their privileged commands.
In the restricted shell environment, users running the adflush command requiring administrative privileges:
dzsh $ adflush
In the unrestricted shell environment, users running the adflush command requiring administrative privileges:
[tulo@ajax]$ dzdo adflush
Creating a role definition with rescue rights
The Rescue rights option allows you to control which users should be able to log on if problems with authentication, the authorization cache, or the auditing
service are preventing all other users from logging on. For example, if you have a computer with sensitive information, such as credit card numbers or
intellectual property, you might require auditing for all users in the role with access that computer. If the auditing service is stopped or removed on that
computer, no one would be able to log on and use the computer until auditing is restored. If you create a role with the Rescue rights option selected, only the
users assigned to that role are able to log on and continue working until the problem that caused the lockout is found and fixed.
Users who are in a role granted access because they have rescue rights can still be audited through the system logging facility. However, their activity is not
recorded in the audit store database if the auditing service is not available.
Creating a role definition that allows local users
Most role definitions are only applicable to Active Directory users and groups. In some cases, however, you might want to create a role definition that can be
assigned to local users. For example, you might want to assign local users to a role that grants rescue rights to ensure a specific local account can log on if an
Active Directory user is not available.
Role definitions that allow local users to be assigned cannot include PAM access rights or SSH rights, however, and therefore do not include any of the UNIX
system rights. You can use role definitions that allow local users to assign specific command rights to local and Active Directory users. You can also set the
audit level for the role definitions that allow local users to be assigned.
If you select the option to allow local users, you can specify the local accounts when you assign the role by clicking Add Local Account, then typing the
name of local UNIX or Windows accounts to assign to the role. The Add Local Account option is not displayed when assigning a role definition that does not
allow local accounts.
Creating a role definition for secure shell rights
You can add SSH rights to any role definition as long as the role does not accept local users. Although SSH rights require the PAM ssh right, the role definition
to which you add SSH rights does not require the PAM access right. As long as a user is assigned to a role that includes the PAM ssh right, you can add SSH
rights to any other role definition to make the rights effective.
In addition to adding the rights to a role definition, you must set the ServiceAuthLocation parameter in the sshd_config configuration file to check for secure
shell rights when users log on using a secure shell. In most cases, you should use the Enable application rights group policy to set this parameter for all
Centrify-managed Linux and UNIX computers. This group policy sets the path to the dzsshchk command which verifies the specific applications rights for
users when they log on.
Alternatively, you can manually set this parameter on an individual computer by editing the configuration file to include the following:
Creating additional custom roles and role assignments
The previous sections described common role definitions that organizations implement to begin the process of migrating and removing locally defined
privileged accounts. For most organizations, locallydefined accounts with privileged access present a security risk and are often identified as a compliance
issue by auditors.
By creating role definitions similar to those described in this chapter, you can eliminate the need to share root and service account passwords while still
providing privileged access to computers where it’s needed. These additional roles are not required, however. You can choose to create them or create a
completely different set of role definitions to suit your organization. For example, you might decide to create custom roles specifically tailored to the needs of
database administrators, backup operators, and web application developers. Similarly, you might decide to create separate role definitions that are
customized with AIX command rights for AIX administrators that are different from the command rights defined for Solaris administrators.
As with the common role definitions, additional custom role definitions can be created in the top-level parent zone and available throughout the zone
hierarchy or in any child zone. They can also span all the computers in a zone or be assigned specifically to individual computers.
If you plan to create your own custom role definitions and role assignments, keep the following key points in mind:
Rights associated with roles are cumulative. Users receive all of the rights in all of the roles they are assigned.
Users must be assigned at least one role that allows an interactive login or Kerberos authentication to have any access to any computers. For existing
users, this is accomplished by assigning the default UNIX Login role during the migration to Active Directory.
Users must be given the Login with non-Restricted Shell system right to have access to a full shell. If they are in a role without this right, they can only
execute the commands explicitly defined for their role.
For users who have previously had full shell access, this limitation can be frustrating, unexpected, and unworkable. Before placing or moving users into a
restricted role, be sure those users and managers throughout the organization are well-informed and wellprepared for the change and understand the
business reasons for the change.
Adding custom attributes
You can add custom attributes to role definitions and role assignments. For example, you might want to use a custom attribute to reference a ticket number
associated with a specific type of access request, role definition, or temporary role assignment. Custom attributes are optional and you can use them to
capture any kind of information that is meaningful to your organization.
You can add custom attributes when defining or modifying a role, defining or modifying a computer role, or when modifying role assignment properties.
Exporting and importing rights and roles
You can export rights and role definitions from any zone if you want to save part or all of the information to a file. You can then import all or part of that
information into a new zone and modify it, if needed. For example, you can choose to export all the rights you have defined in one zone but create a completely
new set of role definitions for those rights in another zone. Exporting and importing provides a convenient way to copy and paste multiple rights and role
definitions at one time.
Rights, roles, and role assignments are all inherited from parent to child zones, so there is no need to import or export any authorization information within a
zone hierarchy. However, if you have multiple parent zones—for example, representing different geographical regions—you might want to use export and
import to copy authorization information from one geographical region’s zone to another.
Exporting authorization information
You can export multiple rights and role definitions to an .xml file that you can then use to import these definitions into another zone. You can also copy and
paste or drag and drop individual rights and role definitions between zones.
To export rights and role definitions:
2. Expand Zones and the individual parent or child zones required to select the zone name from which you want to export authorization information.
3. Select the Authorization node, right-click, then click Export Roles and Rights.
4. Select the information you want to export, then click Next.
For example, select All to export all of the rights and all role definitions. Selecting all or individual role definitions exports all of the rights included in
those role definitions.
5. Click Browse to specify a location and file name for the export file, then click Next.
6. Review the information to be exported, then click Finish.
Importing authorization information
You can import multiple rights and role definitions that you have previously exported from a zone and saved to an .xml file. You can also copy and paste or drag
and drop individual rights and role definitions between zones.
To import rights and role definitions
2. Expand Zones and the individual parent or child zones required to select the zone name into which you want to import authorization information.
3. Select the Authorization node, right-click, then click Import Roles and Rights.
4. Click Browse to navigate to the file that contains the authorization information you want to import, then click Next.
5. Select the information you want to import, then click Next.
6. Review the information to be imported, then click Finish.
Updating rights, roles, and role assignments
When you make changes to rights, roles, or role assignments, these changes take effect on managed computers at the next cache update interval, as set by
the adclient.cache.expires parameter or the “Set object expiration” group policy. The default update interval is 10 minutes. If you want changes to take place
immediately, you can flush the cache on individual computers.
To flush the cache and update authorization changes:
1. Log on or switch to the root user on the managed computer.
2. Run the adflush command to clear the agent cache. For example:
/usr/sbin/adflush
Reviewing the fundamentals of role definitions
As discussed in Basic concepts of access rights and roles, rights are fundamental to authorizing user access, you cannot assign rights directly to users.
Instead, rights are combined into role definitions that reflect the needs of a specific job function, such as database administrator, or the ability to perform
a particular task, such as start a web service or run commands that compress or extract files. It is up to you, as an administrator, to decide on the role
definitions your organization needs and to assign those custom role definitions to the appropriate users and groups.
Basic access rights require Active Directory users to have a complete UNIX profile and at least one role assignment, for example by using the UNIX Login role,
that is in effect in the zone to which a computer is joined. To move beyond basic access rights, you must define custom rights and custom role definitions,
then add the specific rights to each role definition.
After you configure a role definition with rights, you can assign it to individual Active Directory users or to Active Directory groups, so that the role applies to
all members of the group. By assigning role definitions to groups, you can manage ongoing role-based user access completely through Active Directory.
Working with computer roles
In previous chapters a role definition described a specific set of access rights for a user or group, including the period of time when those access rights were
in effect. A computer role is an association that enables you to make the most of those role definitions. Role definitions grant specific access rights or
enforce certain access restrictions. Computer roles enable you to associate role definitions with computers that share a similar function or have a common
attribute. This chapter describes how you can configure and use computer roles to manage access rights for different sets of users.
How computer roles provide flexibility
Centrify-managed computers can only be joined to one zone at any time. This limitation makes it difficult to manage granular access rights at the zone level
alone. Computer roles enable you to group computers that share a common function or attribute and associate the group of computers with a specific set of
role assignments to users or groups. Individual computers can be members of any number of computer roles with different sets of users who have different
access rights based on their role assignments.
Computer roles can have multiple role assignments
A computer role associates a group of computers with a set of role assignments. For example, you might have several computers that host Oracle database
instances. Using a computer role, you can associate the group of computers that host an Oracle database with one role assignment that grants some users
full administrative access. That same computer role can associate the same group of computers with a second role assignment that grants some users
access to specific commands that must be run using the oracle account. That same computer role can also associate the same group of computers with a
third role assignment that grants application users permission to log on using a secure shell session. As long as the set of computers remains the same, you
can use the same computer role to grant different sets of users different access rights.
Managing access using multiple computer roles
Computer roles enable you to manage access rights using multiple filters. For example, you might have several computers that host Oracle database
instances. Some of the computers that host an Oracle database might also belong to specific departments, such as the finance or engineering organizations.
Some of the computers that host an Oracle database might run Red Hat Enterprise Linux while others have a Solaris operating system. You can use computer
roles to grant different sets of access rights based on the criteria you want to use to group the computers. In this example, you might have one computer role
for Oracle database servers and their database administrators, another computer role for users in the finance and engineering departments, and another
computer role for IT staff who specialize in managing either Linux or Solaris computers.
Computer roles enable you to define access rights using any grouping criteria that makes sense for your organization. In this case, you might have one
computer role linked with the Active Directory security group for all Oracle servers, a second computer role linked with the security group that only has
computers that belong to the finance or engineering organization, and a third computer role linked with the security group for Linux or Solaris computers. If
the set of computers grouped together changes, you should use a new computer role to grant different sets of users different access rights.
Planning to use computer roles
Because computer roles provide you with a great deal of flexibility for defining access rights, you might want to do some planning before you create new
computer roles. For example, before you create a computer role you must know the criteria you want to use to group computers into one or more Active
Directory security groups. You must also identify the users who will have a common set of access rights based on the computer grouping.
At a high-level, defining a computer role requires the following:
Identify a unique Active Directory security group for each computer role.
You should identify an attribute the computers in a particular group share, such as computers in the web farm, that host specific applications, or serve a
specific department. You can create the group and add computers to it in Access Manager when you create the computer role, or before creating the
computer role using Active Directory Users and Computers.
Identify the sets of users that share common access rights and create Active Directory groups for them.
You might want to define multiple sets of user-based roles. For example, a computer role for Oracle servers might require a “database users” group, a
“database administrators” group, and a “backup operators” group.
Identify the access rights and role definitions for each set of user-based roles.
You might want to create specific rights, role definitions, and role assignments for different sets of users, or use existing roles. For example, the
“database users” group might only require the predefined UNIX Login role definition, while the “database administrators” group might require access to
privileged commands, and the “backup operators” groups might be only be allowed to run a specific set of commands in a restricted shell.
Creating a new computer role
A computer role is similar to a zone in that it defines a group of computers, a set of users, and specific access rights for a combination of computers and
users. However, computer roles do not require a computer to be joined to the zone where the computer role is defined and a computer can be a member of
multiple security groups and thus multiple computer roles.
Because computer role assignments define a relationship between a security group of computers, a set of rights in a role definition, and a security group of
users, they control who can do what on specific computers. You can change the list of computers or the list of users dynamically simply by changing the
security group membership.
What to do before creating a new computer role
Before you create computer roles, you must join a domain and zone. You should also decide on the criteria to use for grouping computers. Each computer
might belong to several different security groups to used in different computer roles. Depending on your organization’s policies for creating security groups,
you might want to prepare one or more Active Directory security groups for Centrify-managed computers.
To create computer roles, your user account must be a domain user with the following permissions:
unique identifier (GUID) for the Authorization object. For Read description Read msDS-AzScopeName Read msDS-AzApplicationData Write description
example: CN=cab186af-61a0-4d54-a0dd... Write msDS-AzScopeName Write msDS-AzApplicationData
A UNIX zone administrator or a Windows domain administrator who is responsible for adding and maintaining security groups performs this task, depending
on your organization’s policies.
It is common to create new computer roles any time you identify new criteria for grouping computers and role assignments.
The following instructions illustrate how to create a new computer role using Access Manager. Examples of scripts that use the Access Module for Windows
website.
To create a new computer role using Access Manager
2. Expand Zones and the individual parent or child zones required to select the zone name that will contain the new computer role.
3. Expand Authorization to select Computer Roles, right-click, then click Create Computer Role.
4. Type a name for the computer role and an optional description, then select either <Create group> to create a new Active Directory group for
computers or <...> to search for an existing group of computers to use.
For example, click Create group to create a new Active Directory security group named oracle_servers for the computers that host Oracle database
instances. If creating a new group, you are prompted for the location, group name, and scope.
5. After you have selected or created an Active Directory security group, click O K, then click O K to save the new computer role.
Note: If you're using classic zones, you cannot add cross-forest

groups to roles at this time. All groups added to roles should be defined in
the local forest. However, users from a trusted forest may be added to
groups in the local forest and then added to a role, or they may be directly
added to a role. (Ref: IN-90001)
Adding computers to a computer role
After you create an Active Directory security group for computers and associate it with a computer role, you can add or remove computers simply by updating
the group membership. For example, if you have a computer role for managing access to Oracle database servers and you deploy a new instance, you simply
add the new server to the computer security group you created for Oracle servers. You can update the group membership using Active Directory Users and
Computers, Access Manager, ADEdit, or another tool of your choice.
After you have specified the Active Directory security group you want associated with a computer role, the account membership is synchronized so you can
use Access Manager or another program to make changes.
The following instructions illustrate how to add computers to a computer role using Access Manager. Examples of scripts that use the Access Module for
Windows PowerShell, ADEdit, or the Centrify Windows API are available in other guides, the Centrify Software Developer’s Kit, or in community forums on the
Centrify website.
To add computers to the computer role using Access Manager
2. Expand Zones and the individual parent or child zones required to select the zone name that contains the computer role to which you want to add
computers.
3. Expand Authorization and Computer Roles, then expand the computer role to which you want to add computers.
4. Select Members, right-click, then select Add Computer.
5. Type all or part of a computer name, then click Find Now to search for the computer accounts to add.
6. Select one or more computers from the results, then click O K to automatically add computers to the Active Directory group associated with the
computer role.
Adding role assignments to a computer role
For computer roles to be effective, you must create the access rights and role definitions for different sets of users. You can then assign the appropriate
predefined or custom roles to different sets of users to grant or restrict their rights within the scope of the computer role. With proper role definitions and role
assignments, you can manage access rights for computers completely through group membership. For example, after you have created the role definition for
Oracle database administrators, you can add and remove group members to the group you created for Oracle administrators in Active Directory.
For information about creating access rights and role definitions, see the following:
Defining rights to run privileged commands
Defining a restricted shell command right
Adding specific PAM access rights
Combining secure shell rights
After you have create the appropriate access rights and role definitions, you must assign those roles to the appropriate users and groups to complete the
configuration of the computer role.
The following instructions illustrate how to add role assignments to a computer role using Access Manager. Examples of scripts that use the Access Module
for Windows PowerShell, ADEdit, or the Centrify Windows API are available in other guides, the Centrify Software Developer’s Kit, or in community forums on
the Centrify website.
To associate user role assignments with a computer role using Access Manager
2. Expand Zones and the individual parent or child zones required to select the zone name that contains the computer role to which you want to add role
assignments.
3. Expand Authorization and Computer Roles, then expand the computer role to which you want to add role assignments.
4. Select Role Assignments, right-click, then select Assign Role.
5. Select the role definition that you want to add to the computer role, then click O K.
6. Click Add AD Account to search for and select an Active Directory user or security group to assign to the role.
You can select User or Group as the object to find, type all or part of the user or group name, then click Find Now. For example, type “ora” to search for
and select the “oracle_db_admins” Active Directory group then click O K.
7. Click O K to complete the role assignment for the selected user or group in the selected computer role.
Repeat these steps for each role definition you want to assign to users and groups in this computer role. For example, if you have an Active Directory
“oracle_db_users” group that should be allowed to log on and run shell commands on the computers in the “oracle_servers” computer role, you would select
the predefined UNIX Login role in Step 5 and assign that role definition for the computers in the “oracle_servers” computer role to the “oracle_db_users”
group in Step 6.
Viewing and modifying a computer role
You can view information about computer roles by expanding Authorization and Computer Roles for a zone. However, computer roles are also closely linked to
the Active Directory groups that define their scope and role assignments, so there are several different ways you might view or modify information about a
computer role. For example, you might use Access Manager, Active Directory Users and Computers, or ADEdit commands, depending on what you are trying
to do.
In Access Manager, you can expand a computer role, then select Role Assignments to see the users, groups, and role definitions that have been assigned
on the computers that are members of the computer role. You can also expand a computer role, then select Members to see the computers to which the role
assignments apply. To see the Active Directory group assigned to the computer role in Access Manager, select the computer role, right-click, then select
Properties.
If you are using Active Directory Users and Computers, you can view the properties for the Active Directory group associated with the computer role and click
the Members tab to see the computers assigned to the computer role.
If you want to add a computer to an existing computer role, you can simply add that computer to the Active Directory group associated with the computer role
without making any changes in Access Manager. Similarly, if users join or leave your organization, you can simply add or remove those user accounts in the
appropriate Active Directory groups that are associated with the computer role. For example, if you define the oracle_servers computer role to associate a
specific set of computers with a role assignment that grants administrative rights to users in the Active Directory security group oracle_db_admins, you
could simply add the user account for Frank.Smith to the Active Directory security group oracle_db_admins to give that user administrative access on the
computers that are members of the oracle_servers computer role. You do not need to make any changes in Access Manager.
To modify the rights and role assignments for a computer role, you must use Access Manager or ADEdit commands.
Using computer roles
Deciding how best to use computer roles requires some planning and configuration that might not be part of your initial deployment plan. To make effective
use of computer roles, you must also prepare appropriate role definitions for different sets of users. However, computer roles provide a powerful and flexible
option for managing access to computers using your existing processes and procedures for managing Active Directory group membership.
After you create a computer role, it is easy to manage even as your organization changes and grows. For example, if another Oracle database server comes
online, you add it to the computer group you created for Oracle database servers in Active Directory. If other DBAs join your organization, you add them to the
Active Directory group you created for Oracle administrators. The computer role links the computer group to the role assignment and no additional updates
are needed to accommodate these kinds of organizational changes. If you need to modify the access rights, you can change the role definition and have the
changes apply to all members of the group.
Requiring multi-factor authentication using computer roles
Computer roles enable you to group and provide access to computers through role assignments. One strategy you might find useful is to use computer roles
to control where multi-factor authentication should apply. For example, you might have several computers with highly sensitive material where you want to
ensure all user access will require multifactor authentication. To accomplish this goal, you can configure a computer role, then add and remove computers
with sensitive information to control whether multi-factor authentication is required.
To require multi-factor authentication based on a computer role
4. Type the role name and, optionally, a role description, then select <Create group> for the Computer group to create a new Active Directory group for
computers.
For example, to create a new Active Directory security group for the computers with sensitive information, click Browse to select the Active Directory
location for the new group. If you are using the default deployment structure, you would browse to a location similar to acme.pubs.org/Acme/Computer
Roles then type a group name such as mfa_required_servers, select a scope, and click O K.
5. Click O K to save the new computer role.
6. Add the computers that require multi-factor authentication for access to the mfa_required_servers Active Directory security group.
As you add computers to the Active Directory security group, the computers are listed as Members of the computer role.
7. Expand the computer role you creates in Step 4, select Role Assignments, right-click, then select Assign Role.
For example, if you created a new computer role with the role name CR_MFA_required, expand that computer role name to select Role Assignments,
right-click, then select Assign Role.
8. Select the predefined require MFA for login role definition, then click O K.
9. Select All Active Directory accounts, then click O K.
Working with managed computers
This chapter describes how to add Linux and UNIX computers to Active Directory domains, manage computer accounts and properties, perform common
administrative tasks, and leave the domain.
Identifying who can add computers to the domain
Who can join computers to a domain depends on your organization’s policies and those policies are enforced through Active Directory. In general, there are
two common scenarios:
Any authenticated domain user can add up to ten computers to the domain.
This is the default behavior for Windows computers. Many organizations follow this policy, so that administrative access is not required to add
computers to a domain.
Only users with specific permissions can add computers to the domain.
Some organization restrict who can add computers to the domain. For example, a user might have to be a member of the Domain Admins or Account
Operators group to add computers to a domain.
The policy your organization follows for Windows also applies when you want to add Linux and UNIX computers to a domain. If any authenticated user can add
a Windows computer to the domain, adding a Linux or UNIX computer does not require an administrative user name and password. If only administrative or
delegated users are allowed to add computers to the domain, the user adding a Linux or UNIX computer must provide an administrative or delegated user
name and password.
If you aren’t sure whether an administrative account is required to join a domain, you can prepare computer account before attempting to join the domain,
and allow the computer account itself to be used to join the domain. Performing this type of “selfservice” join simplifies the operation and allows the
computer account to manage its own password without administrative intervention.
Preparing computer accounts before joining
If joining the domain is restricted to privileged users, or if you know that you will need to specify computerlevel overrides, you can prepare computer accounts
in advance for the Linux and UNIX computers you want to add to the domain.
There are several advantages to preparing computer accounts before joining the domain. For example, preparing a computer account enables you to
accomplish the following:
Specify the user, group, or computer account with permission to join the computer to the domain.
Define the organizational structure you want to use for computers in Active Directory.
Delegate administrative tasks for managing the computer account.
Specify the user or group with permission to manage computer-level overrides for the computer.
By preparing the computer account in advance, you can minimize the changes or configuration steps you might otherwise have to perform after joining the
domain. For example, by identifying the account to use when a computer joins the domain you can ensure users can add their own workstations without being
assigned any special rights. By selecting the appropriate organizational unit for the computer account ahead of time, you minimize the need to move the
computer account after joining the domain.
To prepare a computer account using Access Manager:
2. Expand Zones and any parent or child zones required to select the zone name to which you want to add the computer account.
3. Right-click, then click Prepare UNIX Computer.
4. Select the type of preparation you want to perform, then click Next.
In most cases, you should select both options to ensure the appropriate user or group has the permissions required to join the domain and set computer-
level overrides.
5. Choose whether to create a new computer object or select an existing computer object, then click Next.
If the computer account exists, but you want to add a zone profile and delegate permission to join the domain and manage computer overrides for the
computer, click Browse to search for and select the existing computer object. After selecting an existing computer account, click Next to continue to
Step 7.
6. Type the computer name to use for the new computer account and specify a location for the computer account object in Active Directory, then click
Next.
For Computer name, type the host name to use for the computer account in Active Directory.
For Domain. verify the domain name displayed is the appropriate domain for the computer account to join. Click Browse to navigate to a
different Active Directory domain.
For DNS name, verify the DNS name for the computer account. You can modify the DNS name for the computer, if needed. For example, if
computer names in DNS use a different suffix than the Active Directory domain, you might need to modify the default value displayed.
Select Create the computer object in the container to specify the parent container for the new computer account in Active Directory. In
most cases, you should use the default parent container object. Click Change to navigate to a different container object for the computer
account.
7. Select the Allow this computer to join the domain using a read-only domain controller option if you want the computer to join itself to the
domain using a read-only domain controller and select the type of license to use, then click Next.
If you click Next without selecting Allow this computer to join the domain using a read-only domain controller, the computer must join the
domain by connecting to a writable domain controller.
8. Review the default list of service types and service principal names for the specified computer, then click Next to accept the default set of service
principal names.
If you want to make changes to the default services or service principal names, you can do the following:
Click A d d to add a service type or add a new service name to an existing service type.
Select a service principal name and click Edit to change the name.
Select a service principal name and click Remove to delete the name.
Click Default SPN to restore the default list of service principal names.
If you are in an environment where multiple instances of the same SPN are possible, as a user with administrator privileges, use the -d or --
forceDeleteObjWithDupSpn parameter with the adjoin command to ensure duplicate SPNs are removed.
9. Select whether to allow a specific user or group to join the computer to the domain or use the computer account and automatically-generate password
to join the domain, then click Next.
In most cases, select Allow the computer to join itself to the zone to allow the computer account to perform a “self-service” join. This option is
selected by default because it allows you to automate the join operation so that a user name and password are not required.
If you want a specific user, group, or computer account to be used to join the domain, select Allow this user, group, or computer to join the
computer to the zone then click Browse to search for the user, group, or computer that you want to give permission to join the computer to the
domain.
10. Select the user, group, or computer account with permission to set computer-level overrides, then click Next.
By default, the permissions required to manage computer-level overrides are granted to members of the Domain Admins group. You can click Browse
to search for and select another user, group, or computer account.
11. You can choose to skip permission delegation, if desired.
If you select this option, the service does not set the security descriptor for the computer; you'll need to go in and set that attribute yourself. Some
organizations prefer to set security descriptors manually. Security descriptors include security information such as the object owner, who has access
rights to the object, and so forth.
12. Review your configuration settings, then click Next.
13. Review the confirmation of the operation performed, then click Finish.
The computer account is created in Active Directory and a zone profile for the computer is added to Access Manager in the zone’s Computers
container. The user or group you have designated as the trustee can now join this computer to the domain using the adjoin selfserve command line
option, and the group you designated for computerlevel overrides can add users and role assignments to the computer.
Delegating permissions when preparing a computer account
When you prepare a computer account, you have the option to grant a specific user, group, or computer account the administrative permissions required to
perform two separate tasks:
The permissions required to join the computer account to the domain.
The permissions required to set and manage computer-level overrides
In most cases, you should select both options even if you want to grant different accounts the permissions required to perform each task.
However, it is possible to create a computer account and not delegate permission for computer-level overrides by deselecting the Delegate permission
for machine overrides option. If you deselect this option, you are the only administrator who can set profile or role assignment overrides for the computer.
No other user or group will be granted the permissions required to set or manage computer-level override for user profiles or role assignments.
Likewise, it is possible to delegate permissions for computer-level overrides without preparing the computer to join the domain by deselecting the Prepare
computer for adjoin option. If you deselect this option, the computer icon appears in the zone, but the Active Directory computer object and service
connection point are not created. The designated trustee can set computer-level override for user profiles or role assignments. No other user, group, or
computer account will be specifically granted the permissions required to join the domain.
If any authenticated user can add computers to the domain, then any user with a valid domain account can join Linux and UNIX computers to the domain. If
adding computers to a domain requires an administrative account, only the administrator who creates the computer account can join it to Active Directory.
For more information about who can add computers to a domain, see Identifying who can add computers to the domain.
Allowing password resets for computer accounts
If you use Access Manager and the Prepare UNIX Computer wizard to create a computer account before joining the domain, you can select the Allow the
computer to join itself to the zone option to set the permissions required for a computer to manage its own account. If you use Active Directory Users
and Computers to create a computer account, however, you need to manually modify the permissions for the account.
By default, most computer accounts do not have permission to reset their own account password. This prevents the delegation of administrative rights for
the computer to the local computer account. If you want to give a computer account administrative rights in a zone, you need to modify the computer
account to allow password resets. In addition, allowing a computer account to update its own properties enables Access Manager to display the agent version
and maintain operating system information for the computer account.
Checking for the appropriate permissions
To check whether a computer account allows password resets, you can view the permission settings for the account.
To check and modify the permissions for a computer account:
1. Open Active Directory Users and Computers, expand the domain, and select Computers to find the computer account to which you want to assign
administrative rights.
2. Select the computer account, right click, then select AD Properties.
3. Click the Security tab, scroll down the list of group or user names and select SELF.
4. In the list of Permissions for SELF, scroll to the Reset Password permission, click Allow, then click O K.
5. Select the computer account, right-click and select Reset Account, then click Yes. When the account is reset, click O K.
Assigning administrative rights to computer accounts
After you have checked the Active Directory permissions for a managed computer account and modified them, if necessary, you can assign zone
administrative rights to the account through Access Manager.
To give administrative rights to the computer account:
2. In the console tree, select Zones, and if necessary, Child Zones, then select and expand the zone in which you are interested.
4. Click A d d, select Computer from the Find list, then click Find Now.
5. In the results, select Domain Computers, click O K, then click Next.
6. Click Join computers to the zone and optionally, Remove computers from the zone, then click Next.
Note: {/b}In most cases, these are the only administrative tasks you should assign to the computer account. You can, however, give the account
additional rights, if needed. For information about the permissions associated with each delegated task, see thePlanning and Deployment Guide.
7. Click Finish.
Joining a domain
To begin authenticating users and authorizing access to Linux and UNIX computers and resources, you must first add the computers you want to manage to
the appropriate Active Directory domains in one or more Active Directory forests. You can do this by running the adjoin command interactively or by using the
adjoin command in a script. A successful join operation is what converts a Linux or UNIX computer into a Centrify-managed computer.
Connecting to the domain controller
To add a new computer to a domain, you must specify the domain you want to join. The adjoin program then locates an appropriate domain controller for the
domain you specify and connects to Active Directory through that domain controller. By default, the domain controller to contact is determined by the Active
Directory site topology. If the nearest domain controller in the site is not available, the agent attempts to connect to the next closest domain controller in the
site. If no domain controller can be contacted or the connection takes too long to complete, the join operation fails.
If you don’t want to agent to select a domain controller based on the site topology, you can specify a master domain controller on a zone-by-zone basis. If you
specify a master domain controller, the agent will connect to the appropriate domain controller based on the zone you are joining.
What happens during the join operation
If the Centrify Agent can successfully connect to an Active Directory domain controller, it performs a series of key tasks to complete the join operation. For
example, during the join operation, the adjoin program completes the following tasks:
Starts the Centrify Agent for *NIX adclient process.
Checks whether a computer account already exists for the local computer in Active Directory. It creates a new Active Directory computer account for
the local computer, if needed.
Sets the password on the Active Directory computer account to a randomly-generated password. The password is encrypted and stored locally on the
UNIX host to ensure that only the Centrify Agent has control of the account.
Updates the Kerberos service principal names used by the host computer, generating new a Kerberos configuration file and krb5.keytab entries, and
generating new service keys for the host and http services.
Synchronizes the local computer’s time with Active Directory to ensure the timestamps for Kerberos tickets are accepted for authentication.
After joining a domain
By default, computers function exactly the same after joining the domain as they did before joining the domain. Local users can continue to log on and
existing programs and applications can continue to work as they did before joining the domain. The primary difference after joining the domain is that you
have more complete control over access to the computer and what Active Directory users who are granted access can do. You will also have more tools at
your disposal for managing computer properties and operations. For example, after joining a domain, you can use any combination of the following tools:
Access Manager
Access Module for Windows PowerShell
ADEdit command line programs and scripts
Active Directory Users and Computers
Group Policy Management console and Centrify group policies
You can use any of these tools to add Active Directory users to the appropriate zones, and to define and assign appropriate rights and roles for the users who
need access to Linux and UNIX computers.
Joining a domain and zone with the adjoin command
In most cases, you add a computer to the domain by running the adjoin command directly on a local computer. You run this command once for each Linux or
UNIX computer you want to add to a domain in the forest. Using the administrator or a designated user account, you can run the command interactively at the
command line or include the command in a script to automate joining a domain.
Specifying the most common arguments
Whether you join the domain interactively from the command line or using a script, you must specify a few required arguments. You might also need to
specify several additional arguments, such as a user name and password for an account with permission to join the domain, an alias for the computer in
Active Directory, or the organizational unit in which to place the computer.
The most common format for the adjoin command is:
adjoin --user username --zone zonename domain
For example, the following command illustrates the most common format for the adjoin command:
adjoin --user shea@acme.com --zone LinuxDev sales.acme.com
This command connects to Active Directory as the user shea@acme.com to add the local computer to a previously-created zone called LinuxDev zone and to
the sales.acme.com domain. In this example, the zone and domain name are required. The user name is not a required argument—if not specified the adjoin
command would prompt for the Administrator account password. However, because the user shea is a member of the acme.com domain rather than the
sales.acme.com domain, the user account must be specified in the user_name@domain_name format.
Because the password is not specified in the command line, the adjoin program prompts for the Active Directory password to authenticate the
shea@acme.com account before connecting to Active Directory.
In most cases, you should avoid including the password for an account as part of the adjoin command line for security reasons. If you are using adjoin in a
script, however, you must include the --password option or provide another mechanism for inputting a valid password. For more information about adjoin
command line options and running adjoin commands, see the adjoin man page.
If the adclient process is able to connect to Active Directory and the join is successful, a confirmation message is displayed. By default, the join operation
adds the new computer account to Active Directory in the domain_name/Computers container. If the connection to Active Directory fails, a warning
message is displayed and the join operation fails.
Using the self-serve option for a previously-created computer account
If you have previously prepared a computer account in Active Directory as described in Preparing computer accounts before joining, you can use the
selfserve (-S) option to join a domain without specifying a user name and password. For example, you can run a command similar to the following to join the
domain:
adjoin --selfserve domain
For example:
adjoin --selfserve cendura.org
Note that you must specify the domain to join but not the zone—the computer is automatically joined to the zone in which the computer object was pre-
created.
If you want to preserve service principal names (SPN) configured in the centrifydc.conf, use the adjoin command option -r spn or --useConf spn. This option
only works in conjunction with the -S, --selfserve command.
Joining a domain in workstation mode
In most cases, zones are required if you are adding Linux and UNIX computers to Active Directory to address account migration and role-based access rights.
However, it is possible to deploy without using zones to organize computers, rights, roles, and other information.
The workstation mode is intended for computers that function in the same way as Windows workstations where any valid user can log on to any computer
that is joined to the domain. In general, workstations do not require you to manage identity attributes, such as UIDs and GIDs, or access-related attributes,
such as the hours a user is allowed to log on. To mirror this behavior for Linux and UNIX computers, the workstation mode automatically creates a local user
profile for users when they log on and does not apply any access rules unless you configured them for the user account in Active Directory.
Computers that join the domain using workstation mode are added to a single Auto Zone and are treated the same as Windows workstations, and are
managed by Active Directory and group policy settings. You can use the workstation mode and Auto Zone for any computers that do not require profile
management or role-based access controls. You can also have any combination of workstation computers that don’t require profile management and access
control and workstations and servers that do require profile management, access control, hierarchical zones. For more information, see Using workstation
mode and Auto Zone.
To join a domain using workstation mode instead of zones, you can run a command similar to the following:
adjoin --workstation --user username domain
For example:
adjoin --workstation --user kai.rodriguez cendura.org
This command adds the local computer to a single Auto Zone. The Auto Zone requires no configuration and there are no properties, user profiles, or access
rights to manage. All Active Directory users and groups in the forest, or in forests with a two-way trust, can access the computers in the Auto Zone.
Joining the domain using the computer account
On the computer to which you have given administrative rights, run the adjoin command and set the user name parameter to the computer name with a dollar
sign ($) appended and the password to the computer name.
adjoin domain --zone zoneName --user computername$ --password computername
For example, if the computer name is valencia and the Active Directory domain is arcade.com, you would run a command similar to the following:
adjoin arcade.com --zone finance --user valencia$ --password valencia
Setting the password interval for managed computers
After joining a domain, the password for the managed computer account in Active Directory is automatically reset at a regular interval to ensure security. By
default, the password for the computer account is updated with a new, randomlygenerated password every seven days. You can customize how frequently
the password for the account is changed through the Password change interval group policy or by modifying the adclient.krb5.password.change.interval
parameter in the configuration file, centrifydc.conf, on any managed computer.
Allowing a managed computer to authenticate NIS users
If you are using one or more managed computers as a NIS server to provide “agentless” authentication to NIS client requests or to publish NIS network maps,
you can identify those computers in Access Manager by setting the Allow this computer to authenticate NIS users option on the computer’s Centrify
Profile. Setting this option adds the computer account to the zone_nis_servers Active Directory group. Additional configuration is required if you want a
managed computer to respond to NIS client request.
This option is provided because using Centrify Network Information Service (adnisd) is more secure than using a legacy NIS server and can be useful to
accommodate certain situations, such as a transition from NIS domains to Active Directory domains. However, continuing to use NIS client requests to
retrieve network information is not a secure practice and might result in an audit finding in some organizations.
For more information about installing, configuring, and using the Centrify Network Information Service, see the Network Information Service Administrator’s
Guide.
Changing the zone for a managed computer
When you join a domain, you must join a specific zone unless you are using workstation mode and connecting through Auto Zone. Over time, you might want
to migrate managed computer accounts from one zone to another. You can change the zone information for a computer at any time, if needed. You can
change the zone for a computer by selecting a new parent or child zone in the computer properties or by cutting and pasting the computer object from one
zone to another in Access Manager.
After you change the zone for a managed computer, you must restart the Centrify Agent for *NIX on that computer for the change to take effect. You are not
required to run adleave or adjoin to complete the change. For example, after you have changed the zone for a computer log on to that computer and run the
following command:
/etc/init.d/centrifydc restart
Alternatively, you can restart the managed computer to restart all services, including the Centrify Agent for *NIX. In most cases, however, restarting the
agent is sufficient.
Note: If the computer has role assignments defined, you might be

prevented from moving the computer until you remove the role assignments.
Changing domain information for a managed computer
Once a computer successfully joins a domain, you can remove it from a domain at any time by using the adleave command. You must also use the adleave
command before you can join a new domain or make changes to the domain information for a computer, such as changing the computer name.
Leaving a domain
Leaving the domain before attempting to join a new domain or changing a computer name ensures that there will not be file conflicts or orphaned information
that might prevent the join operation from completing.
You should note that leaving the domain removes all of the Centrify-specific information for the managed computer from Active Directory and reverts any
computer settings that were changed by the adjoin command to their preadjoin condition. These changes include reverting PAM, NSS, and Kerberos
configuration files to their pre-adjoin states and deleting the /etc/krb5.keytab file. Leaving the domain does not delete the Active Directory computer object
itself.
Leaving the domain does not delete the Active Directory computer object itself. If you want to completely remove any record of the computer from Active
Directory, you must delete the computer object using Active Directory Users and Computers.
Joining a different domain
After running the adleave command, re-run the adjoin command with the appropriate arguments to join a different Active Directory domain. For example:
adjoin --zone arcade.com --user gale.harris operations.acme.com
For more information about using the adjoin and adleave commands, see the adjoin or adleave man page.
Renaming a managed computer
If you need to rename a Linux or UNIX computer that is joined to a domain, you should first leave the domain, rename the computer, then rejoin the domain.
Otherwise, you could have issues with the service connection point or service principal name for the computer.
Customizing configuration settings for a computer
You can configure many aspects of the environment for individual computers by applying a Group Policy Object to a site, domain, or organizational unit that
includes managed computers and enabling Centrify-specific group policies. For example, you can use policies to customize PAM operations, the length of
time to wait for connections between the Centrify Agent for *NIX and Active Directory, or how frequently to change the computer account password. For
information about the group policies available and how to enable them, see the Group Policy Guide.
If you are not deploying Centrify group policies, you can also customize the configuration settings in any computer’s local agent configuration file,
centrifydc.conf. The comments within the file describe the most common settings. For more information about setting the parameters directly in the agent
configuration file, see the Configuration and Tuning Reference Guide.
Enabling FIPS-compliant encryption
The Federal Information Processing Standard 140-2 (FIPS 140-2) describes US Federal government requirements that IT products should meet for sensitive,
but unclassified use. The standard is published by the National Institute of Standards and Technology (NIST) and is required by all non-military agencies of
the United States Government. This standard is also widely used by many other organizations outside of the government.
The standard defines the security requirements that must be satisfied by a cryptographic module used to secure unclassified information. There are four
levels of security: from Level 1 (lowest) to Level 4 (highest). These levels are intended to cover the wide range of potential applications and environments in
which cryptographic modules might be deployed. The security requirements cover areas related to the secure design and implementation of a cryptographic
module.
The Centrify Agent can be configured to use FIPS-compliant encryption so that a managed computer can successfully join a domain that is FIPS 140-2, Level
1, compliant.
Verifying the Windows environment
Before you configure the Centrify Agent to use FIPS-compliant encryption, you should verify that the Active Directory domain meets the minimum
requirements for FIPScompliance. For a Centrify-managed computer to join a FIPS 140-2 Active Directory domain, the Active Directory domain must meet the
following basic requirements:
The domain must be at domain functional level Windows Server 2008, or later.
The forest must have a global catalog computer that is running at domain functional level Windows Server 2008, or later.
The domain must have at least one Windows Server 2008 R2, or later, domain controller.
Any trusted domains you plan to access must be at domain functional level Windows Server 2008, or later.
Although a managed computer can successfully join a domain that has trust relationships to domains at a lower functional level, it cannot access users in
those trusted domains, for example, to add user profiles or roles to a zone.
Using group policy for FIPS compliance
If your Active Directory forest meets the minimum requirements and you have configured the Windows environment with the local or group “System
cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” security policy, you can make Centrifymanaged computers FIPS-
compliant by enabling and applying the Centrify “Use FIPS compliant algorithms for encryption, hashing and signing” group policy. You should not use the
equivalent Windows group policy to configure FIPScompliant communications for Linux and UNIX computers. The Centrify “Use FIPS compliant algorithms for
encryption, hashing and signing” group policy is specifically designed to support Active Directory domains that are configured for FIPS 140-2 compliance.
The Centrify “Use FIPS compliant algorithms for encryption, hashing and signing” group policy is defined in a separate XML (centrifydc_fips.xml) or ADM
(centrifydc_fips.adm) template file. The template file is included in the Centrify group policy extension. You must add one of these templates to a Group
Policy Object to make a Centrify-managed computer FIPS-compliant mode. For information about adding template files and enabling group policies, see the
Group Policy Guide. After you enable the policy, it takes effect at the next group policy update interval. To have the policy applied immediately, run the
adgpdupdate command.
Using the XML template group policy
If you use the XML group policy template to enable FIPS mode, the policy verifies that each computer is joined to a domain at the domain functional level
Windows Server 2008, or later. If a domain controller does not meet this minimum domain functional level, the policy issues a warning that allows you to skip
enabling of FIPS mode for that computer.
The XML group policy template also verifies all computers to which the policy applies are running a supported operating system. On the computers that are
running a supported operating system, the policy sets the fips.mode.enable configuration parameter to true and automatically stops and restarts the adclient
process. After the restart, the computers where the policy was applied are FIPS-compliant.
If the computer is not running a supported platform, the XML policy leaves the fips.mode.enable configuration parameter set to false, and does not stop and
restart adclient. The computer remains joined and the current encryption and hashing algorithms remain in force.
Modifying the agent configuration file
The Centrify “Use FIPS compliant algorithms for encryption, hashing and signing” group policy sets the fips.mode.enable parameter in the Centrify
configuration file to true. By default, this parameter is set to false until the group policy is applied and the computer is updated at the next group policy update
interval. You can also manually modify this parameter setting directly in the agent configuration file (centrifydc.conf), then restart the adclient process to
enable FIPS mode. In most cases, however, you should use the group policy to set the configuration parameter to enable FIPS mode rather than manually
editing the fips.mode.enable parameter on individual computers.
Applying the group policy to a domain
In most cases, you should apply the “Use FIPS compliant algorithms for encryption, hashing and signing” group policy to a Windows Server 2008, or later,
domain to enable FIPS mode. If the group policy is applied to the domain, then the computer will be enabled for FIPS mode automatically when it joins the
domain.
Agent requirements for FIPS-compliant encryption
You can only configure FIPS mode for Centrify Agents, version 5.0.2, or later. In addition, FIPS mode is only supported on specific distributions of Linux and
Mac OS X operating systems. For a complete and up-to-date list of the platforms that Centrify supports in FIPS mode, see the NIST validation entry for
Centrify FIPS mode.
NTLM authentication
The Centrify Agent does not support NTLM authentication through SMB or SMB2 when configured to use FIPS-compliant encryption. FIPS mode only allows
NTLM pass-through authentication over SChannel. Note that NTLM pass-through authentication requires a Windows Server 2008 R2, or later, domain
controller.
Non-compliant operations
When configured to run in FIPS mode, the agent uses non-FIPS compliant hash and key-hash algorithms, as follows:
MD4, MD5 and HMAC-MD5 are used to support NTLM passthrough authentication (including using NLTM for PAM authentication).
MD4 is used to generate the managed computer password hash for use in setting up AES NetLogon Secure Channel. AES NetLogon Secure Channel is
used for NTLM pass-through authentication as well as for updating operating system version attributes.
MD5 is used to generate the UNIX password hash to verify against the MD5 password hash that is stored in the cache during disconnected mode login.
(This is for backward compatibility support; this happens when you upgrade from a DirectControl version that does not support the SHA256 password
hash.)
When configured to run in FIPS mode, the agent uses a non-FIPS compliant encryption algorithm, as follows:
Non-FIPS compliant encryption will be used in encrypting secret information for internal communication through a UNIX domain socket.
A non-FIPS compliant random number generator is used in generating the Initialization Vector used in the encryption.
Configuring the encryption types for trusted domains
Inter-realm keys for the AES256-CTS and AES128-CTS encryption types must be established between any trusted domains to enable Active Directory users
from these domains to log on to the joined computer. You can use the ksetup utility, installed by default on the domain controller, to set up the inter-realm
keys.
To configure the inter-realm keys
1. On the domain controller, open a Command Prompt window.
2. Type the following commands:
C:\>ksetup.exe /SetEncTypeAttr trustedDomain AES256-CTS-HMAC-SHA1-96
C:\>ksetup.exe /SetEncTypeAttr trustedDomain AES128-CTS-HMAC-SHA1-96
Note: If you are using pre-validated Active Directory users, you must enable these users for Kerberos AES 128- and 256-bit encryption. You can do so by
editing user accounts in Active Directory or by setting attributes for the users in ADSI Edit. For more information, see Enabling required encryption types
for pre-validated users.
Manually granting write permissions for a computer account
If the domain that the managed computer is joining does not have at least one Windows Server 2008 R2 domain controller, you must manually grant write
permission for the Operating System Version and msDS-supportedEncryptionTypes attributes to the computer account of the joined computer.
To grant write permission for required attributes to the computer account
1. Open Active Directory Users and Computers or ADSI Edit.
2. Expand the Computers container and select the computer that is joining the domain, right-click, then click Properties.
4. Click A d d.
5. In the “Enter the object name to select” field, type SELF and click O K.
6. Click the Properties tab, select This object only from the Apply to list, then scroll down and click Allow for the following attributes:
Write msDS-supportedEncryptionTypes
Write Operating System Version
7. Click O K in each dialog box to close the dialog and save the new permissions.
Manually granting write permissions for a user account
If the domain that the managed computer is joining does not have at least one Windows Server 2008 R2 domain controller, you must manually grant write
permission for the Operating System Version and msDS-supportedEncryptionTypes attributes to the user account used to join the computer to the domain.
1. Open Active Directory Users Computers or ADSI Edit.
2. Expand the Computers container and select the computer that is joining the domain, right-click, then click Properties.
4. Click A d d.
5. In the “Enter the object name to select” field, type the name of the Active Directory user who will join the computer to the domain and click O K.
6. Click the Properties tab, select This object only from the Apply to list, then scroll down and click Allow for the following attributes:
Write msDS-supportedEncryptionType
Write Operating System Version attributes
7. Click O K in each dialog box to close the dialog and save the new permissions.
Enabling required encryption types for pre-validated users
If you are using pre-validated Active Directory users, you must enable Kerberos AES 128- and 256-bit encryption for these users. You can do so by editing the
user accounts in Active Directory Users and Computers or by setting attributes for the users in ADSI Edit.
To enable encryption for pre-validated users by using Active Directory Users and Computers
1. On the domain controller, open Active Directory Users and Computers.
2. Navigate to the domain and select Users.
3. Select the pre-validated user, right-click, then click Properties.
4. Click the Account tab, then select the following Account options:
This account supports Kerberos AES 128 bit encryption.
This account supports Kerberos AES 256 bit encryption.
5. Click O K to save the updated account information.
To enable encryption for pre-validated users by using ADSI Edit
1. On the domain controller, open ADSI Edit.
2. Navigate to the domain and select CN=Users.
3. Select the user, right-click, then click Properties.
4. In the Attribute Editor tab, select the msDS-supportedEncryptionTypes attribute and select Edit.
5. Type 0X18 to set the hex value for the attribute and click O K.
You should see that the value shows:
0x18=(AES128-CTS-HMAC-SHA1-96 | AES256-CTS-HMAC-SHA1-96)
6. Click O K to save the new setting.
How Centrify FIPS mode affects other encryption settings
If you enable FIPS mode, you cannot specify the Data Encryption Standard when joining the domain. The adjoin --des option is not supported. Only AES
authentication is supported.
If you have specified multiple types of encryption for the computer by setting the adclient.krb5.permitted.encryption.types parameter in the centrifydc.conf
configuration file, only aes256-cts and aes128-cts encryption type keys are generated and saved to the keytab file. However, if arcfour-hmac-md5
encryption is specified, the MD4Hash of the computer password is generated and saved to the keytab file.
In addition, depending on how your environment is configured, you can choose whether to remove any non-AES encryption keys for service principal names
(SPNs) from the computer's keytab file by setting the adclient.krb5.clean.nonfips.enctypes parameter in the centrifydc.conf configuration file. If you set this
parameter to true, adclient scans the keytab file and removes any non-AES encryption keys for SPNs during startup. This parameter is false by default.
Restarting the agent after enabling FIPS mode
If you use the ADM group policy template, which does not perform validation checks, or if you manually enable FIPS mode by setting the fips.mode.enable
parameter in the agent configuration file, the adclient process will not start if the domain functional level is below Windows Server 2008.
If you attempt to start adclient and the domain functional level is below Windows Server 2008, you will see the following error message:
Cannot start adclient in FIPS Mode as machine is joined to domain with PreWindows 2008 Domain Functional Level!
To restart the agent, you must disable FIPS mode by setting the fips.mode.enable parameter to false or the “Use FIPS compliant algorithms for encryption,
hashing and signing” group policy to Not configured. After disabling FIPS mode, you can continue working at your current domain functional level in non-FIPS
mode by restarting the agent:
/usr/share/centrifydc/centrifydc restart
If you want to enable FIPS mode, leave the current domain, update your domain functional level, then join a Windows Server 2008, or later, domain.
Importing sudoers configuration files
If you are currently managing privileges on Linux and UNIX computers using multiple sudoers configuration files, you can import that information and convert
it into rights and role definitions that can then be assigned to Active Directory users and groups, local users and groups, or both.
This chapter describes how to migrate all of your privilege management information from sudoers configuration files to Active Directory through Access
Manager.
Identify the sudoers file on each computer
Most organizations use sudoers configuration files and the sudo program to manage privileges on Linux and UNIX computers. To read the sudoers file on each
Linux or UNIX computer, you must have root-level permission. You can define a command right to grant this level of access to other users.
The default location for the sudoers configuration file is /etc/sudoers, and in general, this is the file to import from each computer. However, there are some
exceptions:
If sudo was compiled with the --sysconfdir option to specify a different location for sudoers file, you need to find the actual location. Run sudo -V to see
the sudo configuration options, including the path to the sudoers file.
If your environment has an automatic mechanism for distributing a single sudoers file to the entire network, you can use that one file and don’t need to
import multiple files.
Get the sudoers file from each computer
You can manually copy the sudoers file to a location on the Windows computer that has Access Manager installed. You should specify a file name that
identifies the computer where the file was used. For example, you might include the local host name or a functional description, such as
oracle_server_sudoers.txt or qa1_server_sudoers.txt.
Import the sudoers file
After you have copied the sudoers file to the computer where Access Manager is installed, you can import the sudoers file into a selected Centrify zone.
To import the sudoers file
2. Expand Zones and the individual parent or child zones required to select the zone name into which you want to import the sudoers file.
In most cases, if you have a sudoers file that covers multiple computers, you should import it into a parent zone so that it is available to multiple child
zones. If the file is used on a single computer, you might select the specific child zone that contains that computer.
3. Right-click, then select Import sudoers file.
4. Click Browse and navigate to the location in which you copied the sudoers file, select the file, click Open, then click Next.
5. Review the contents of the file to verify you are ready to import, then click Next.
If you have previously imported a sudoers file—for example, from a different computer—importing a new sudoers file overwrites the data from the
previous import. If you have not yet converted the previous sudoers information to rights and rights in Access Manager, click Cancel to exit the wizard.
For more information about convert the imported information to Centrify rights and roles, see Converting sudoers aliases and user specifications before
importing an another sudoers file.
6. Review the parsing summary for errors or warnings to verify whether you are ready to import, then click Next.
You can click Details to see the list of error and warnings, if applicable. From the list, you can select a specific error or warning, then click Go To to see
the definition in the sudoers file. You can continue with the import if the list only displays warnings. If there are errors, you must fix them before
continuing. Make note of any errors and warnings to fix, then click Close to close the Details list.
If the file contains errors, or if you want to fix warnings before importing, click Cancel to exit the wizard. You can then open the sudoers file in a text
editor to fix, delete, or comment out the lines in the file, then save it. After you have modified the file, you can rerun the Import Sudoers File wizard.
7. Click Finish to complete the import.
The import wizard creates a new node called Sudoers, which contains sub-nodes for the types of data contained in a sudoers file. For example, expand
Sudoers to see the nodes for User Alias, Runas Alias, Host Alias, Command Alias, and User Specifications. If the Sudoers node is not visible, select
Authorization, right-click, then click Refresh.
Some or all of the Sudoers sub-nodes might be empty depending on whether the sudoers file included definitions of that type. For example, if there are no
user aliases defined in the sudoers file, the User Alias sub-node is displayed in Access Manager, but there are no entries under it.
You can now convert the sudoers data to rights, role definitions, and role assignments in the Centrify zone. If you intend to import more than one sudoers file
into the same zone, you must convert the imported aliases and user specifications to rights, role definitions, and role assignments before importing another
sudoers file.
Converting sudoers aliases and user specifications
Before you convert the sudoers file aliases and user specifications to rights, role definitions, and role assignments, be certain that you have imported all the
users and groups specified in the sudoers file into Active Directory, and that you have added them to the zone in which you are imported the sudoers file. If
there are users and groups without a profile in the zone when you attempt to convert the user specifications from the imported sudoers file into role
assignments in Access Manager, the conversion will fail.
In addition, keep in mind that the role definitions and assignments you create from sudoers specifications do not contain any UNIX system rights or PAM
access rights. You can assign those rights through other roles, such as the predefined UNIX Login role, or you can add system rights and PAM access rights to
the role definitions after you create them from the sudoers specifications.
Within each item are objects for the sudoers definitions that were imported. For example, within User Alias are alias definitions, each one of which contains
the user accounts defined for that alias.
Each type of information from the sudoers file converts to a different type of authorization information in the Centrify zone. You do not need to convert all of
the imported aliases. You can simply ignore or delete aliases that are obsolete or no longer relevant.
Converting user aliases
On Linux and UNIX computers, a user alias in the sudoers file defines a set of users without creating a group. When you convert a user alias specification to be
used in a zone, however, it becomes an Active Directory group. Assigning users to groups simplifies user management because if users change roles or leave
the company, you can simply remove their group membership, without deleting their accounts, and effectively, they no longer have access to the roles
assigned to members of the group.
You can create a new Active Directory group from the user alias you imported or map the imported alias to an existing Active Directory group.
To create a new Active Directory group from a user alias
2. Expand Zones and the individual parent or child zones required to select the zone name into which you imported the sudoers file.
3. Expand Authorization and Sudoers, then select User Alias.
4. Select the alias name, right-click, then select Create AD Group.
5. Verify the container location, or click Browse to select a different container, then click Next.
6. Verify the group name, which defaults to the alias name, optionally, add a prefix or suffix, and select the scope for the group, then click Next.
7. Review the group and group membership information displayed, then click Next.
If there are any warnings or errors displayed, you must fix the errors before continuing. If only warning are displayed, you can continue to create the
group. For example, if the user alias has members that don’t have a corresponding Active Directory account, you can continue creating the group.
8. Review information about the new Active Directory group, then click Finish to create the group.
To map a user alias to an existing group
3. Expand Authorization and Sudoers, then select User Alias.
4. Select the alias name, right-click, and select Map to AD Group.
5. Select Remove original AD group membership or cancel the selection depending on whether you want to keep the current members of the group
when adding the users from the alias definition.
If you select this option, the wizard removes the existing members of the group when adding the new members. If you do not select this option, the
wizard adds the new members to the existing members.
6. Click Browse, then enter search criteria to identify the group and click Find Now.
7. Select the name of the group and click O K.
The wizard imports the users defined by the alias into the specified Active Directory group. It also issues a warning message that it can’t import users
who are defined by the alias but who are not defined in Active Directory.
Viewing run-as aliases
A run-as alias defines a group of one or more users who other users are able to run commands as. Select and double-click the alias name to expand it and see
the users who are defined for it. You cannot directly import run-as aliases. However, if a user specification includes a run-as alias, you can view the run-as
definition in the Runas Alias node, and import the commands defined in the specification. For more information about user specifications, see Converting
user specifications.
Converting host aliases
Host alias definitions are popular in centralized sudoers files because they allow you to assign privileges to groups of computers rather than managing
privileges on an individual computer and file basis. They convert naturally to computer roles, which also assign privileges to groups of computers.
When you convert a host alias to a computer role, the wizard creates a new computer role, creates an Active Directory group that contains the computers
defined in the host alias, and adds these computers to the new computer role. Because the computer role group is an Active Directory group, the computers
can span multiple zones and include computers that are joined to different zones. To complete the computer role definition, you must add the appropriate
user role assignments, which specify what specific users and groups in different role definitions are allowed to do on the computers included in the computer
role group.
To create a computer role from a host alias
3. Expand Authorization and Sudoers, then select Host Alias.
4. Select the alias name, right-click, then select Create Computer Role.
5. Click Next to accept the location for the group of computers, or change the location, then click Next.
6. Verify or change the group name, optionally, add a prefix or suffix, and select the scope for the group, then click Next.
7. Review the group and group membership information displayed, then click Next.
8. Review information about the new Active Directory group for computers, then click Finish to create the group and the new computer role.
If the computer accounts exist in Active Directory, the computers defined in the host alias are automatically added to the new Active Directory
computer group and to the “Members” node of the new computer role.
9. Expand Authorization, Computer Roles, and the computer role name.
10. Select Role Assignments, right-click, and click Assign Role.
11. Select the role and click O K.
12. Click Add AD Account.
13. Select User or Group, enter search criteria, then click Find Now to search for and elect the user or group, then click O K.
14. Select the appropriate user or group from the result, then click O K to complete the user role assignment.
Viewing command aliases
You can select the Command Alias sub-node to view the command aliases that were imported from the sudoers file. You can’t edit or delete the command
aliases. The information is displayed for your reference. You can assign the command aliases listed role definitions, role groups, and computer roles when you
convert the user specifications imported from the sudoers file.
Converting user specifications
In the sudoers file, user specifications make use of the alias definitions to assign commands and privileges to users. After you import the sudoers file, you can
convert the user specifications into role assignments.
To convert user specifications to role definitions and role assignments
3. Expand Authorization and Sudoers, then select User Specifications.
4. Select the name of a user specification, right-click, then select Import.
5. Review the list of commands to be created, then click Next.
6. Verify the name of the role definition name to be created, then click Next.
By default, the role definition is named Role_n. You can change it after it is created.
7. If the user or group defined in the imported user specification is not found in the zone, the role assignment to be created is displayed and you can click
Next, then click Finish.
If the user or group defined in the imported user specification is not found in the zone, the role assignment will fail and the role displays an error ( Error ).
Click Cancel to exit the wizard and add the user or group to Active Directory and the zone.
Importing a user specification will fail if the user or group defined in the user specification is not found in the zone or if no computers are defined for the
host alias in the user specification are found in the zone.
8. Rename the role definition by expanding Authorization and Role Definitions.
Select the new role definition, for example, Role_2.
Right-click, then select Rename
Type a new name for the role definition.
The role definitions you create from a sudoers specification do not contain the UNIX system rights or PAM access rights. You can assign these rights through
a separate role assignment or by add the appropriate UNIX system rights and PAM access rights to the new role definitions.
Removing imported sudoers information
Once you have validated the conversion of imported sudoers file information, you can purge the sudoers information from Access Manager.
To purge sudoers information
3. Expand Authorization, then select Sudoers.
4. Right-click, then select Purge.
The Sudoers node and sub nodes are removed from Access Manager.
Mapping sudo to dzdo
To execute privileged commands users must type dzdo and the command name. If you want, you can map sudo to dzdo, which allows your users, who are
accustomed to using sudo to execute their privileged commands, to continue to type sudo commandName. If the user has a role assignment that allow him to
execute the command in an unrestricted shell, the command is executed using dzdo commandName. To map sudo to dzdo on computers in your
organization, you can enable the “Replace sudo by dzdo” group policy for a site, domain, or organizational unit.
For more information about working with group policies, see the Group Policy Guide.
Using Centrify OpenLDAP proxy service
This section describes the Centrify OpenLDAP proxy service (centrifydc-ldapproxy) that you can use to map Active Directory users to UNIX identities to
enable access to the files stored on legacy network appliance servers and storage devices. Centrify OpenLDAP also enables Linux and UNIX computers to
search Active Directory domain controllers and global catalog servers for any information stored in Active Directory. If you have the appropriate permissions,
you can also use the Centrify OpenLDAP proxy service to add, modify, or delete information stored in Active Directory.
What the OpenLDAP proxy provides
Many applications support the Lightweight Directory Access Protocol (LDAP) and require data stored in this format, but do not support Kerberos. In addition,
many applications that support LDAP cannot search Active Directory directly because of the complexities of the Active Directory environment itself, such as
the global catalog, multiple domains, multiple forests, and trust relationships.
The Centrify OpenLDAP proxy is an OpenLDAP server process that enables LDAP clients that are not Kerberos-enabled to search Active Directory efficiently
and securely. By using the Centrify OpenLDAP proxy, applications that support LDAP can search complex Active Directory environments and authenticate
users with Active Directory. Through the Centrify Agent, the Centrify OpenLDAP proxy enables you to resolve UID, GID, and group membership efficiently and
collapse the entire Centrify hierarchical zone structure, including parent and child zone, and individual computer overrides into a single namespace for LDAP
applications.
In addition, connecting to Active Directory typically requires an authenticated bind with a valid user name and password. Because the Centrify OpenLDAP
proxy uses the Centrify Agent to connect to Active Directory and retrieve information, you can issue OpenLDAP commands without an authenticated bind.
The following diagram provides a simplified overview of the components.
Components
The key advantages to deploying the Centrify OpenLDAP proxy when you have LDAP clients where the Centrify Agent cannot be installed are as follows:
You can use the Centrify OpenLDAP proxy server to run commands that retrieve or update information stored in Active Directory.
The Centrify OpenLDAP proxy service uses the Centrify Agent to securely connect to Active Directory and retrieve user, group, and other information
from the Active Directory domain controller.
You can leverage the offline authentication and caching capabilities of the Centrify Agent for applications that support LDAP, but not Kerberos.
Regardless of the complexity in Active Directory, including multiple domains and forests and parent and child zones, the Centrify OpenLDAP proxy
treats the information stored in Active Directory as a single RFC2307-compatible namespace.
Enabling simple authentication
Users can be authenticated through simple authentication to the Centrify OpenLDAP proxy with their username and password. This is then converted to a
secure Kerberos authentication by adclient.
By default, to authenticate users, adclient checks its credential cache data first, then, if not in cache, it refers to Active Directory. Allowing Centrify
OpenLDAP proxy to use the adclient credential cache, enables authentication if adclient is in disconnected mode.
If you want to always authenticate through Active Directory:
To the slapd.conf file:
/etc/centrifydc/openldap/slapd.conf
Add:
cdc-auth-prefer-cache false
Enabling simple proxy mode
If either objectClass or objectCategory is not specified in the search filter, the search is in simple proxy mode. With simple proxy mode, all search filters are
sent without translation through adclient to Active Directory. All results are returned as provided by Active Directory without translation or interpretation of
results.
Accessing network appliance or storage servers
One of the most common uses for the Centrify OpenLDAP proxy service is to provide access to the files stored on legacy network appliance file servers and
storage devices. Many organizations use network appliance file servers and storage area network devices to provide highly available and scalable data
storage services that support multiple client access protocols—including NFS, CIFS and iSCSI—and multiple operating systems.
Supporting multiple protocols and operating systems, however, presents a challenge when users want to access files from computers with different
operating systems. To ensure users are granted proper access to files stored on a network appliance or storage server, their identity attributes must be
consistently defined for both UNIX and Windows operating systems.
For example, the identity attributes that allow access to the files on a network appliance or storage server might be UNIX profile attributes from a common
NIS or LDAP repository. The UID and GID values establish file ownership and file access permissions. For Windows users to access the files stored on the
network appliance or storage server, their Windows account must be mapped to the UNIX profile that grants them the appropriate file permissions.
Mapping Active Directory users to UNIX profiles
Centrify enables you to map Active Directory users to one or more UNIX profiles. The UNIX profile contains each user’s identity attributes. You can use this
mapping of Active Directory account information to UNIX identity attributes to provide consistent file and directory ownership and access rights to files that
are stored on a network appliance or storage server.
By mapping an Active Directory account to a UNIX profile, you can ensure that a user’s identity is consistently maintained and that access to UNIX-hosted
resources is properly protected regardless of the computer from which the user accesses the resource.
For network appliance or storage servers that are hosted on UNIX computers and require UNIX identity attributes to grant access, you can use the Centrify
OpenLDAP proxy service to make the Active Directory-hosted user mapping information available through the LDAP or LDAPS protocol.
Configuring servers to use the proxy service
Before you can use the Centrify OpenLDAP proxy service to look up information stored in Active Directory, the network appliance, storage device, or file
server you want to use must be configured to use LDAP to look up user and group information. In most cases, this is an option you configure when setting up a
server or device.
If your vendor supports connecting to LDAP servers for authentication and authorization services, configuring the server or device to use the Centrify
OpenLDAP proxy requires the following high-level steps:
1. Install Access Manager, create at least one zone, and add users to the zone.
2. Install the Centrify Agent on a Linux or UNIX computer and join the computer to an Active Directory domain.
3. Install the centrifydc-ldapproxy package on the Linux or UNIX computer.
4. Start the centrify-ldapproxy service and verify proper operation.
5. Set up the network appliance, storage device, or file server to use the Centrify OpenLDAP proxy service to look up user and group information.
6. Test the solution for proper end-to-end operation.
Installing the Centrify OpenLDAP proxy service
On most platforms, the centrifydc-ldapproxy package is available with the Centrify agent software package but is not installed by default. You can select the
package in the installation script or install it using a native package installer.
To run the Centrify OpenLDAP proxy service, the computer must:
Be joined to an Active Directory domain.
Have the Centrify Agent installed and the adclient running.
In the following example, the agent is installed on a Linux computer and the computer is joined to the acme.org Active Directory domain.
To install the Centrify OpenLDAP proxy service on a Linux computer
1. Log on or switch to the root user, then navigate to the directory where you extracted Centrify files.
For example, if you ran the gunzip and tar commands in the /tmp directory, change to the /tmp directory.
2. Run install.sh or a native package manager to install the files.
For example, run the following command:
./install.sh
You can type K to keep any existing packages you have installed. When you see the Install the CentrifyDC-ldapproxy package prompt, type Y. Follow the
remaining prompts displayed to complete the installation.
Alternatively, you can use a native package manager. For example on most Linux distributions, you can run a command similar to this:
rpm -Uvh centrifydc-ldapproxy-release-arch.rpm
If you are installing on Solaris, unzip and extract the contents of the package, then run a command like this:
pkgadd –d CentrifyDC-ldapproxy -a admin
If you are using an installation program, such as SMIT or YAST, see the documentation for that program.
3. If you want to start the ldapproxy service with parameters, configure the STARTUP-OPTS option.
Run the appropriate command for your platform.
For CentOS, SLES
echo "STARTUP_OPTS=\"-h ldaps:///\"" >> /etc/sysconfig/centrify-ldapproxy
For Debian
echo "STARTUP_OPTS=\"-h ldaps:///\"" >> /etc/default/centrifyldapproxy
For HPUX
echo "STARTUP_OPTS=\"-h ldaps:///\"" >> /etc/rc.config.d/centrify-ldapproxy
For AIX
chssys -a "-d 0 -h ldaps:///" -s centrify-ldapproxy
For Solaris without Service Management Facility (SMF)
echo "STARTUP_OPTS=\"-h ldaps:///\"" >> /etc/centrifydc/openldap/centrify-ldapproxy.conf
For Solaris with Service Management Facility (SMF)
svccfg -s centrify-ldapproxy setprop 'slapd/STARTUP_OPTS=("-h""ldaps:///")'
4. Start the centrify-ldapproxy service.
For example, on Linux computers:
/usr/share/centrifydc/bin/centrify-ldapproxy start
5. Test the service by searching for an object in the Active Directory domain.
For example, to search for groups in the domain, you might type commands like this:
cd /usr/share/centrifydc/bin
ldapsearch -h localhost -p 389 -x -b “dc=acme,dc=org”
s sub "objectClass=group" -D
"cn=amy.adams,cn=users,dc=acme,dc=org" -w 1234abcepassword
The -h and -p options are required to connect to Active Directory using the proxy service and the Centrify Agent. If the LDAP proxy service is not on the
local computer, use the -h option to specify the name of the computer where you have installed it.
You can also connect to Active Directory directly using a valid user name and password. For example:
ldapsearch -D "cn=amy.adams,cn=users,dc=acme,dc=org" -W
-h dc2012.acme.org -p 389 -x -b "dc=acme,dc=org"
-s sub "objectClass=group"
6. (Optional) Review and modify, if necessary, the default centrifyldapproxy service start-up script in the /etc/init.d/ directory.
You can use the /usr/share/centrifydc/bin/centrifyldapproxy script to start, stop, restart or check the status of the Centrify OpenLDAP proxy service.
Note: By default, the service starts automatically when the computer

restarts.
Specifying the LDAP server
After you have installed and tested the Centrify OpenLDAP proxy service, the next step is to configure the network appliance, storage device, or file server to
use the Centrify OpenLDAP proxy service to look up user and group information. In most cases, this involves setting configuration options to specify the
computer where the Centrify OpenLDAP proxy service is running as the LDAP server you want to use in a local or system-wide ldap.conf file. You should
consult the documentation provided by the vendor you are integrating with for details about how to set up LDAP integration.
Testing the solution
After you have configured the network appliance, storage device, or file server to use the Centrify OpenLDAP proxy service on a Centrifymanaged computer,
you should verify that files created by a Windows user have the correct UID and GID to access those files from both a UNIX computer and a Windows
computer.
Manually starting the OpenLDAP service
Typically, the Centrify OpenLDAP proxy service automatically starts when the computer restarts. You have the option to manually start Centrify OpenLDAP
proxy service.
The Centrify OpenLDAP proxy service is a modified version of the standard slapd LDAP server process. The Centrify version of the slapd process also uses a
customized version of the standard LDAP server configuration file in the following location:
/etc/centrifydc/openldap/slapd.conf
This customized version of the slapd.conf configuration file is created automatically when you join a domain and is configured by default with Access
Manager and domain-specific information. You can start or stop the slapd process at any time by using the centrify-ldapproxy script or directly from the
command line.
To start the Centrify OpenLDAP proxy service directly from the command line using the default configuration file, you can run the following command:
/usr/share/centrifydc/libexec/slapd
or
/usr/share/centrifydc/bin/centrify-ldapproxy start
If you start the slapd process directly from the command line, you can also specify additional command line options just as you would for the standard slapd
LDAP server process. For example, you can use the -f command line option to specify a different configuration file to use:
slapd -f /etc/centrifydc/openldap/slapd.conf
or
/usr/share/centrifydc/bin/centrify-ldapproxy start -f /
etc/centrifydc/openldap/slapd.conf
For more information about the command line options when starting the LDAP server directly from the command line, see the man page for the slapd process.
Note: On the computer that is using systemctl, if the slapd process

crashes, the systemd process will restart the slapd process.
Sample deployment scenario
The following diagram illustrates a basic deployment scenario for a distributed site with minimal OpenLDAP proxy overhead. As depicted in this illustration,
the legacy LDAP servers and devices support a redundant LDAP server for fault tolerance and failover.
Legacy LDAP servers and devices
Using OpenLDAP commands
The Centrify OpenLDAP proxy service includes a set of OpenLDAP commands that have been modified to support looking up information in Active Directory
domain controllers and the global catalog. The Centrify distribution of OpenLDAP supports most of the standard options and syntax for performing LDAP
operations, but the ldap commands in the Centrify distribution of OpenLDAP also support the following options that are not supported in a standard
OpenLDAP distribution:
Use this option To do this
-m Use the local machine credentials from the /etc/krb5.keytab file. This option requires root user access.
-r Disable line wrapping when printing out LDIF entries.
The Centrify distribution of OpenLDAP also provides extended URL support for Active Directory. With Centrify LDAP commands, you can use the following
URLs to connect to Active Directory computers:
Use this To do this
ldap://domain_name Connect to the appropriate domain controller for the specified domain within the Active Directory site.
ldap:// Connect to the joined domain.
Connect to the global catalog domain controller for the joined domain. You can use the optional domain_name parameter to specify
gc://[domain_name]
a domain in a different forest.
The Centrify distribution of OpenLDAP includes the following commands:
ldapsearch
ldapadd
ldapmodify
ldapmodrdn
ldapcompare
ldapdelete
Note: The ldappasswd and ldapwhoami commands do not work with Active
Directory. For more information about using the OpenLDAP commands or the
standard options available, see the man page for each command.
Centrify OpenLDAP proxy commands attributes
The Centrify OpenLDAP proxy commands accept the following attributes.
dn - Specifying the dn attribute returns only the distinguished name
1.1 - Specifying the 1.1 attribute returns only the distinguished name
* - Specifying the asterisk (*) attribute return is situational:
If only * is specified, Centrify OpenLDAP proxy returns all our supported attributes.
If the * is specified with additional attributes, Centrify OpenLDAP proxy returns the given additional attributes.
Searching for users and groups
If you want to use ldapsearch to find a user, do not use objectclass=user or objectcategory=person to specify the filter. Instead, you should use
objectclass=posixaccount. For example, to find the user with the UNIX name jtr enter a command similar to the following:
/usr/share/centrifydc/bin/ldapsearch -x -h localhost -D
“CN=Administrator,CN=Users,DC=pistolas,DC=org” -W -b
“dc=pistolas,dc=org” "(&(objectclass=posixaccount)(uid=jtr))"“
Optionally, use the UID number instead of the UNIX name:
"(&(objectclass=posixaccount)(uidNumber=1234567))"
Similarly, use objectclass=posixgroup to retrieve information on a group. This filter supports the following options:
cn: Find a group with a given UNIX name
gidNumber: Find a group with a given GID
memberUID: Search for secondary group membership of given UNIX user.
Searching the global catalogs
In most cases, you use the Centrify OpenLDAP proxy service to search for information through the domain controller. However, you can also use the Centrify
OpenLDAP proxy service to perform searches in the global catalog, if needed. The global catalog search is especially useful if you have a large, multiple-
domain forest.
To specify that you want the Centrify OpenLDAP proxy service to search the global catalog, add “CN=$” to the front of the search base.
To search Active Directory for a specific account, use the syntax:
"(&(objectCategory=Person)(Name=amy.adams*))"
For example, in the global catalog, you might type a command similar
to the following:
/usr/share/centrifydc/bin/ldapsearch -h localhost -D
"cn=amy.adams,cn=NewUsers,dc=ajax,dc=org" -w password -x -b "cn=$"
By default the Centrify OpenLDAP proxy service is configured to disable anonymous binds. To allow anonymous binds:
1. Edit the /etc/centrifydc/openldap/slapd.conf file.
2. Remove or comment following line.
require authc
If anonymous binds are disabled, you no longer need to specify the -D and -w parameters to invoke an ldapsearch. For example:
ldapsearch -h localhost -x -b "dc=wonder,dc=land"

"(&(objectClass=User)(displayName=Mister\*))" displayName
Minimizing search traffic to adclient
To minimize the traffic to adclient and subsequently to Active Directory, during an ldapsearch, the Centrify OpenLDAP proxy implements memory cache. The
Centrify OpenLDAP proxy memory cache is disabled by default.
To enable the Centrify OpenLDAP proxy memory cache, change slapd.conf to:
ldapproxy.cache.enabled true
Enabling encrypted communication
By default, communication between LDAP clients and the Centrify OpenLDAP proxy service is not encrypted. To secure communications between LDAP
clients and the Centrify OpenLDAP proxy service using Transport Layer Security (TLS), you must create or obtain the required certificates and configure both
the LDAP client and the LDAP server to use the certificates. In addition, you must configure the LDAP server with the certification authority (CA) certificate,
its own server certificate, and a private key.
The current versions of the ldapsearch client and ldapproxy server support Transport Layer Security (TLS) v1.2.
Depending on your network topology, you might also need to modify client-side or server-side configuration settings to successfully return search results.
Preparing for auto-enrollment
You can configure the Centrify OpenLDAP proxy service to automatically get the certificate, private key, and CA chain for secure LDAP (ldaps) connections.
To configure automatic enrollment for certificates, however, you must have an Active Directory domain controller that you can use as a certification
authority for issuing certificates.
The following steps summarize how to prepare the domain controller:
1. Use Server Manager to add the Active Directory Certificate Services role to a domain controller.
2. In the Add Roles wizard, select the Certification Authority role service and follow the prompts displayed to configure the server role.
3. Open the Certificates MMC snap-in, select the domain controller certificate, right-click, then click Open.
4. Select the Details tab, click Copy to file, then follow the prompts displayed to export the certificate to a file.
5. From Administrative Tools, select Group Policy Management, then select an appropriate Group Policy Object for the forest and domain you want to edit.
6. Right-click the Group Policy Object, then click Edit.
7. Under Computer Configuration, expand Policies > Windows Settings > Security Settings, then select Public Key Policies.
8. Select Trusted Root Certificate Authorities, right-click to select Import, then follow the prompts displayed to import the certificate.
9. Select Certificate Services Client - Auto-Enrollment, then select Enabled.
10. From Administrative Tools, select Certification Authority, expand the name of the domain controller you are using as the certification authority, then
select Certificate Templates.
11. Right-click to select Manage, select an appropriate template to use, such as the Computer template, right-click, then click Duplicate Template to
open the properties page for the new template.
12. Type an appropriate name for the new template, such as Centrify OpenLDAP Proxy.
13. Click the Security tab, select the Domain Computers group, select Allow for the Autoenroll permission, then click Apply.
You can set other properties on the remaining tabs, as needed. For example, you might want to click the Subject Name tab to change the subject name
format to Fully distinguished name. When you are finished setting properties for the template, click O K.
14. In the Certification Authority console, select Certificate Templates, right-click to select New, then click Certificate Template to Issue.
15. Select the template you created, for example, select the Centrify OpenLDAP Proxy template, then click O K.
Updating the Centrify OpenLDAP proxy computer
After you have prepared the domain controller with the policy for certificate autoenrollment, you can use the following steps to provide the required
certificate, private key, and certification authority.
1. Verify the computer where you are running the Centrify LDAP proxy service is joined to an Active Directory domain.
2. Change to the directory where certificates for auto-enrollment are located.
cd /var/centrify/net/certs/
You should see files similar to the following listed in the directory:
auto_LDAPProxy.cert
auto_LDAPProxy.chain
auto_LDAPProxy.key
trust_41DFF689876FCE52E02EE73FC7E3782964DC54BB.crl
trust_F7842B2A65489F15A1722518E41F5E6B0F4FBC5E.cert
3. Run an openssl command similar to the following to create the certificate:
openssl pkcs7 -in auto_LDAPProxy.chain -text -out auto_LDAPProxy_CA.pem print_certs
4. Add the following lines to /etc/centrifydc/openldap/slapd.conf configuration file. Comment out the old TLSCipherSuite line, as shown here.
TLSCertificateFile /var/centrify/net/certs/auto_LDAPProxy_CA.pem
TLSCertificateFile /var/centrify/net/certs/auto_LDAPProxy.cert
TLSCertificateKeyFile /var/centrify/net/certs/auto_LDAPProxy.key
TLSCipherSuite TLSv1.2
# TLSCipherSuite SSLv3
You should also review and modify other server configuration settings, if needed. For example, you might use settings similar to the following:
# Require START TLS on port 389

security tls=1
# Require TLS v1.0 or better
TLSProtocolMin 3.1
TLSVerifyClient try
5. Add the following line to /etc/centrifydc/openldap/ldap.conf configuration file:
TLS_CACERT /var/centrify/net/certs/auto_LDAPProxy_CA.pem
You should also review and modify other configuration settings, if needed. For example, you might need to change the TIMEOUT value to allow clients to
wait an appropriate number of seconds for a response:
TIMEOUT 15
6. Restart the Centrify OpenLDAP proxy service.
sudo /usr/share/centrifydc/bin/centrify-ldapproxy start -h ldaps:///
7. Test operation by running an OpenLDAP command, such as ldapsearch.
/usr/share/centrifydc/bin/ldapsearch -x -H ldaps://localhost:636 -b 'cn=users,dc=win2012,dc=test' -D administrator@win2012.test -W "

(cn=test_user)"
8. To confirm that TLSv1.2 is being used, use openssl s_client to connect to the slapd. For example, enter:
$ openssl s_client -connect localhost:636 -showcerts -state -CAfile /etc/centrifydc/openldap/cacert.pem
9. Review the output from the previous command and confirm that the protocol is TLSv1.2, as shown here:
...
SSL Session:
Protocol : TLSv1.2
10. (Optional) Alternatively, to confirm that TLSv1.2 is used, run a software tool like Wireshark to capture and inspect the ldapsearch traffic.
Securing communication without auto-enrollment
If you are not using an Active Directory domain controller and autoenrollment for certificate distribution, you can manually configure the Centrify OpenLDAP
proxy service to use the server certificate and private key you create.
The following steps summarize how you can manually configure the Centrify OpenLDAP proxy service to use certificates.
1. Use CA.sh to create the certificates:
/usr/share/centrifydc/ssl/misc/CA.pl -newca
/usr/share/centrifydc/bin/openssl req -new -nodes -keyout newreq.pem -out newreq.pem
/usr/share/centrifydc/ssl/misc/CA.pl -sign
2. Install the certificates in the /etc/centrifydc/openldap directory.
cp demoCA/cacert.pem /etc/centrifydc/openldap/cacert.pem
mv newcert.pem /etc/centrifydc/openldap/servercrt.pem
mv newreq.pem /etc/centrifydc/openldap/serverkey.pem
3. Add the following lines to /etc/centrifydc/openldap/slapd.conf configuration file:
TLSCACertificateFile /etc/centrifydc/openldap/cacert.pem
TLSCertificateFile /etc/centrifydc/openldap/servercrt.pem
TLSCertificateKeyFile /etc/centrifydc/openldap/serverkey.pem
4. Add the following line to /etc/centrifydc/openldap/ldap.conf configuration file:
TLS_CACERT /etc/centrifydc/openldap/cacert.pem
5. Start the slapd deamon using the following:
/usr/share/centrifydc/libexec/slapd -h "ldaps:///"
or
sudo /usr/share/centrifydc/bin/centrify-ldapproxy start -h ldaps:///
Searching for automount maps and entries
You can use the Centrify ldapproxy service and ldapsearch command to find automount maps and automount map entries that you have stored in Active
Directory. The following examples illustrate how to write filters to retrieve automount information. These examples assume you have added the following
automount maps and map entires to Active Directory using Access Manager:
The auto.home map has the map entries test1 and test2.
The autotest map has the map entries test10 and test11.
To retrieve both maps, you might run a command with a filter like this:
ldapsearch -x -h localhost -b "DC=acme,DC=test" "(objectClass=automountMap)"

-D "cn=amy.adams,cn=users,dc=acme,dc=org" -w 1234abcepassword
The command returns attribute information for each map similar to this:
dn: cn=auto.home,cn=NisMaps,cn=global,cn=Zones,dc=acme,dc=test
automountMapName: auto.home
ou: auto.home
cn: auto.home
displayName: $CimsAutomountMapVersion1
objectClass: top
objectClass: automountMap
uSNChanged: 20046
To retrieve information for a specific map, you might run a command with a filter like this:
ldapsearch -x -h localhost -b "DC=acme,DC=test"

"(&(objectClass=automountMap)(automountMapName=auto.home))"
To retrieve all map entries from both maps, you might run a command with a filter like this:
ldapsearch -x -h localhost -b "DC=acme,DC=test" "(objectClass=automount)"

To retrieve information for a specific map entry, you might run a command with a filter like this:
ldapsearch -x -h localhost -b "cn=auto.home,DC=acme,DC=test"

"(&(objectClass=automount)(automountKey=test1))"
For information about adding and managing NIS maps to Active Directory, see the Network Information Service Administrator’s Guide.
Automatic translation to search for zone users
If you integrate the Centrify Agent with a software environment that has limited configuration options, a standard ldapsearch query might fail to return zone
users and groups. If you encounter this issue, you can use a configuration parameter to automatically translate a standard search for Active Directory users
and groups into a search query for zone users and groups.
You can set the ldapproxy.cdctranslate.fetchbydnuid parameter in the slapd.conf configuration file to true if you want a search for Active Directory users and
groups to be automatically translated into a search for zone users and groups. The default is false. After changing the parameter setting, you should restart
the centrify-ldapproxy service.
Note that the translation only applies if the ldapproxy.cdctranslate.fetchbydnuid parameter is set to true, and the following additional conditions are in the
search request:
For the search base, the first part of the DN must be "uid=unixname"
The search scope base must be (0)
The search filter must be (objectClass=*)
For example, automatic translation is performed if you run a command similar to the following after changing the ldapproxy.cdctranslate.fetchbydnuid
parameter to true and restarting the centrify-ldapproxy service:
ldapsearch -x -D "cn=zoe,OU=ajax,dc=acme,dc=org" -w 1234abcepassword

-h localhost "(objectClass=*)" -b "uid=zoe,OU=ajax,dc=acme,dc=org"
-s base
Using workstation mode and Auto Zone
For most organizations, adding Linux or UNIX computers to an Active Directory domain involves creating one or more parent zones, adding Active Directory
users and groups to the zone, and assigning one or more roles to the zone users. As an alternative to this process, you can create a single Auto Zone for all
Active Directory users or a specific subset of Active Directory users.
Profiles are generated for all users in the forest
If you use Auto Zone, all of the profile attributes that are normally defined in the zone to which a computer is joined are generated automatically based on user
attributes in Active Directory or based on a set of agent configuration parameters. By default, all Active Directory users and groups in for the forest
automatically become valid users and groups on the computers joined to Auto Zone. The generated profiles have a unique UID and GID for each Active
Directory user in the forest. The generated profile is what enables access to the computers joined to Auto Zone.
In addition, if you have Active Directory users in another forest that has a two-way trust relationship with the forest of the joined domain, all of those users are
also valid users for the joined computer.
Note: Auto Zone does not support one-way trusts. If a computer is joined
to a domain that has a one-way trust relationship with another domain, the users
and groups in the trusted domain do not become valid users and groups on the
computer.
Limiting users and groups in Auto Zone
If you want to use Auto Zone, but do not want to give all Active Directory users and groups a valid profile, you can use group policies or configuration settings
to limit the generation of profiles and computer access to specific users and groups. For example, if you have a two Active Directory groups with users who
need access to Linux, UNIX, or Mac OS X computers, you can use either group policies or configuration settings to specify that only the two groups who
require profiles are valid Auto Zone users and all other Active Directory users should be ignored.
Auto Zone does not provide zone-specific features
If you decide to use Auto Zone, you should keep in mind that Auto Zone does not support any zone-specific features, such as the ability to define rights and
roles, assign roles to users and groups, configure auditing, or keep legacy identity attributes on different computers.
If you want to configure role-based access rights, delegate administrative activity, or migrate existing users and groups, you should not use Auto Zone. If you
have a large Active Directory forest, but only require automatic profile generation for a subset of users and groups, you might want to use a combination of
hierarchical zone and Auto Zone.
Joining a domain as a workstation
Auto Zone is created automatically in Active Directory if you join a domain by running the adjoin command with the --workstation option.
What to do before joining Auto Zone
Before joining a computer to Auto Zone, be certain that the following are true:
Active Directory identities are unique for the forest and any two-way trusted forest.
The Active Directory users and groups require a single set of properties for all computers that join the domain through Auto Zone and do not need to be
segregated into zones for any reason.
All domains in the forest and any trusted external forest must be unique or the join will fail. In this case, you must manually configure a unique prefix for
each trusted domain using configuration parameters.
A Linux or UNIX administrator with root permission on the computers you want to join to an Active Directory domain. The administrator must also know the
password for an Active Directory domain administrator account.
In most cases, you only do this once for each Linux or UNIX computer that needs to join an Active Directory domain as a workstation.
You must have an account with root permission to modify agent configuration files on managed computers or an administrative account with write
permission to enable group policies on a Group Policy Object linked to a domain or organizational unit.
The following instructions illustrate how to join Auto Zone using the adjoin command.
To join a computer to a domain as a workstation
1. Log on the computer with the Centrify Agent using an account with root privilege.
2. Open a terminal and execute the following command:
adjoin domainName --workstation
For example:
[root@rhe5]#adjoin acme.com --workstation
3. Type the Active Directory administrator’s password.
Administrator@ACME.COM’s password:
Using domain controller: win-f7d27u7kl6m.acme.com writeable=true

Join to domain:acme.com, zone: Auto Zone succesful
4. Run the adinfo command to verify the connection to Auto Zone:
[root@rhe5]# adinfo
Local host name: rhe5
Joined to domain: acme.com
Joined as: rhe5.acme.com
Pre-win2K name: rhe5
Current DC: win-f72d7u7kl6m.acme.com
Preferred site: Default-First-Site
Zone: Auto Zone
Last password set: 2012-09-30 18:08:34 PDT
Licensed Features: Enabled
Generating profiles for specific users and groups
You can automatically generate profiles for specific users and groups by enabling group policies in a Group Policy Object for a domain, site, or organizational
unit in an Active Directory forest or by specifying configuration settings on individual computers.
You must have an account with root permission to modify agent configuration files on managed computers or an administrative account with write
permission to enable group policies on a Group Policy Object linked to a domain or organizational unit.
A Windows or UNIX administrator performs this task, depending on your organization’s policies. In most cases, a Windows administrator is responsible for
configuring group policies and modifying Group Policy Objects. If your organization uses local configuration settings, the UNIX administrator is usually
responsible for this task.
Steps for completing this task using group policies
In most cases, you should use group policies in a Group Policy Object to identify the Active Directory users and groups for which you want to automatically
generate profiles. The Group Policy Object enables you to centrally manage access to computers in the Auto Zone. You can enable and configure the
following group policies to specify a subset of Active Directory users and groups that should have access to computers in Auto Zone:
Specify AD users allowed in Auto Zone
Specify groups of AD users allowed in Auto Zone
Specify AD groups allowed in Auto Zone
The following instructions illustrate how to limit the valid users and groups in the Auto Zone using these group policy settings.
To specify users and groups to include in Auto Zone by using group policy settings
1. Identify or create an Active Directory group that includes all of the users that you want to give access to Centrify-managed computers.
The group can be a domain local, global, or universal group. The group can include sub groups — members of these sub groups will also be included in
Auto Zone.
2. Open Group Policy Management to create or select a Group Policy Object that is linked to a site, domain, or organizational unit.
3. Right-click the Group Policy Object, then select Edit to open Group Policy Management Editor.
4. Expand Computer Configuration > Policies > Centrify Settings > DirectControl Settings, click Adclient Settings.
Double-click “Specify groups of AD users allowed in Auto Zone” to specify users by Active Directory group without automatically generating
profiles for the groups themselves.
Double-click Specify AD users allowed in Auto Zone to specify individual Active Directory users for which to automatically generate profile.
Double-click Specify AD groups allowed in Auto Zone to specify individual Active Directory groups for which to automatically generate profile.
5. Select Enabled, then click List to browse for the groups or users to include.
6. Click A d d, enter search criteria, then click Find Now.
7. Select one or more groups or users from the list, then click O K.
Steps for completing this task using configuration parameters
In some cases, you might want to limit the Active Directory users and groups who have a profile generated by configuring parameters in the centrifydc.conf
file on individual computers. For example, you might want to use configuration parameter settings if you don’t want to implement or apply group policies on
certain computers.
You can configure the following configuration parameters to specify a subset of Active Directory users and groups that should have access to computers in
Auto Zone:
auto.schema.allow.users
auto.schema.allow.groups
auto.schema.groups
The following instructions illustrate how to limit the valid users and groups in the Auto Zone using these configuration parameters settings.
To specify users and groups to add to Auto Zone by using configuration parameters
1. On a Windows computer, in Active Directory Users and Computers, identify or create a group or group that includes all the users who you want to have
access to your Centrifymanaged computers.
2. On each computer to add to Auto Zone, open the /etc/centrifydc/centrifydc.conf configuration file.
Find the auto.schema.allow.groups parameter and remove the comment (#) to add the names of groups separated by commas.
Find auto.schema.allow.users and remove the comment (#) to add the names of users separated by commas.
Find auto.schema.groups and remove the comment (#) to add the names of groups separated by commas.
The configuration file contains comments that list the valid formats for user and group names. For more information about setting these
parameters or editing the configuration file, see theConfiguration and Tuning Reference Guide.
Troubleshooting authentication and authorization
This chapter describes how to use diagnostic tools and log files to retrieve information about the operation of Server Suite software and how to identify and
correct problems within your environment.
Diagnostic tools and log files
All Centrify services include diagnostic tools and logging mechanisms to help you trace the source of problems if they occur. These diagnostic tools and log
files allow you to periodically check your environment and view information about Centrify operation, your Active Directory connections, and the
configuration settings for individual UNIX and Linux computers.
Although logging is not enabled by default for performance reasons, log files provide a detailed record of Centrify Agent (adclient) activity. This information
can be used to analyze the behavior of adclient and communication with Active Directory to locate points of failure. However, log files and other diagnostic
tools provide an internal view of operation and are primarily intended for Centrify experts and technical staff.
In most cases, you should only enable logging when you need to troubleshoot unexpected behavior, authentication failure, or problems with connecting to
Active Directory or when requested to do so by Centrify Support. Other troubleshooting tools, such as command line programs, can be used at any time to
collect or display information about your environment.
Analyzing information in Active Directory
One important way you can troubleshoot your environment is by running the Analyze command. The Analyze command enables you to selectively check the
integrity of the information stored in Active Directory. With the Analyze wizard, you can check for a variety of potential problems, such as duplicate user IDs,
duplicate groups, empty zones, orphaned data objects, or computers that have joined more than one zone.
Note: When you run the Analyze command, only the zones that are open are
checked.
To check for problems with information in the Active Directory forest:
If you are prompted to connect to a forest, specify the forest domain or domain controller to which you want to connect.
2. In the console tree, select the Access Manager root node, right-click, then click Analyze.
3. Select the types of checks you want to perform, then click Next to generate the report.
Select this
To do this
option
Perform all of the data integrity checks. Note If you do not register the administrative notification handler through the Setup Wizard or
All
manually using ADSI, you should periodically run the Analyze command with All or Orphan UNIX data objects selected.
Computers
joined to Check for computers that have joined the domain using more than one zone. Each UNIX computer should only reside in one zone, but if you
multiple run the join command more than once, it is possible to have the same computer in more than one zone. This option checks for this problem.
zones
Cyclic zone Check for a circular zone hierarchy. The console prevents you from creating a circular zone hierarchy, but it is possible to do so
hierarchy inadvertently when using ADEdit.
Duplicate
groups in Check for duplicate UNIX group names or group identifiers (GIDs) in each open Centrify zone.
zones
Duplicate role
assignment
Check for computers that have more than one location to store role assignment information.
containers in
computer
Duplicate
service
Check for duplicate service principal names across the entire forest. Service principal names are required to be unique within an Active
principal
Directory forest.
names in
forest
Duplicate
Check for duplicate SFU zones that are set to manage the same NIS domain.
SFU zones
Duplicate
users in Check for duplicate UNIX user names or user identifiers (UIDs) in each open Centrify zone.
zones
Duplicate
zone default Check for duplicate Zones parent container objects in the Active Directory forest.
container
Empty
Select this
To do this
option
computer Check for computer roles that contain no computers or role assignments.
roles
Empty
profiles in
Check for hierarchical zones that contain users or groups that have no profile data defined.
hierarchical
zones
Empty zones Check for zones that have no computers, users, or groups.
Foreign
Security
Check for foreign security principal objects whose corresponding security principal has been removed.
Principal
Clean Up
Check for users with missing UNIX profile attributes or who are missing a primary profile. This analysis option checks the entire zone
Incomplete
hierarchy for profiles with missing attributes and for users who have multiple profiles defined but don not have a primary profile. Users with
user UNIX
an incomplete profile or a missing primary profile will not be able to log on even if they are assigned a role with login rights. Note that a
data
profile can be incomplete at any level of the zone hierarchy as long as it is complete at the level where a computer is joined.
Inconsistency Check that there is a zone_nis_servers group in each zone that supports agentless authentication and that the group contains all the NIS
in granting servers that have been defined for the zone. The zone_nis_servers group is required to assign permissions to managed computers that act
NIS server as NIS servers, and should not be manually deleted or modified. This option checks that the group exists and includes all of the computers
permissions acting as NIS servers to ensure data integrity.
Inconsistent
computer Check for discrepancy between the DNS name for a computer in Active Directory and its Centrify computer profile name.
object names
Insufficient
permission Check whether the computer object in Active Directory has sufficient permission to update the version number property of the Centrify
for agent Agent for *NIX in the computer’s serviceConnectionPoint object. If the computer object does not have permission to change this property,
version the version number cannot be displayed.
update
Insufficient
permission Check whether the computer object in Active Directory has sufficient permission to update the version number property of the operating
for OS system in the computer’s serviceConnectionPoint object. If the computer object does not have permission to change this property, the
version operating system version number cannot be displayed.
update
Check whether an invalid right has been assigned to a role. This error occurs if a right has been added to a role and subsequently the right
becomes invalid. Generally, a right becomes invalid if it is edited with a third-party tool, such as ADSI Edit, and an attribute is set to an invalid
value. For example, Access Manager creates Active Directory objects of type msDSAZOperation for command- and PAM-application-
Invalid right rights, and assigns a HEX value to the msDS-AzOperationId attribute of these objects. The range of reserved values for this attribute is as
assignments follows: Command: (HEX) 0500,0000 – 05FF,FFFF PAM application: (HEX) 0200,0000 – 02FF,FFFF If this attribute is set to a value that is
out of the reserved range, the right will be invalid and will no longer appear in Access Manager. If the right has been assigned to a role, the
Analyze Invalid right assignment check returns an error. You can select the error in the Analysis Results node and use the Action menu to
delete it from the role if you wish.
Invalid role Check whether invalid role assignments exist in the zone. In most cases, invalid role assignments occur when a role assignment is defined
assignments for a computer account and the computer leaves a zone without cleaning up roleassignment objects.
Check for role assignments that contain multiple roles or multiple users. In most cases, this error only occurs if you are using third-party
Invalid role tools to edit role assignments. Centrify tools prevent you from creating invalid role assignments. Note that a role assignment consists of a
Select this
To do this
option
assignments single user and a single role. To assign multiple roles to a user, you create multiple role assignments, which are stored in the form of
(DZ V2) user@domain role/sourceZone; for example: qa1@acme.com login/engineering qa1@acme.com vi_power/engineering qa1@acme.com
test/engineering
Check for child zones that have an invalid parent zone. The information identifying the parent-child zone relationship is stored in the child
zone in the form of a HEX string and the name of the domain to which the parent zone belongs. If this identifier is deleted, or changed to an
Orphan child
invalid format, or if the parent zone is deleted but the child zone remains in the domain, Analyze (Orphan child zones) returns an error. Note
zones
that this error typically occurs only if you use third-party tools to edit zone objects in Active Directory. If you delete a parent zone using
Centrify tools, child zones are deleted as well.
Check for role assignments that consist of a non-existent role or user, or that do not contain a role or user. In most cases, this error only
Orphan role occurs if you are using third-party tools to edit Centrify objects in Active Directory. If you delete a role or user using Centrify tools or using
assignments Active Directory Users and Computers, the role assignment will be deleted as well (the change will be visible after you refresh the display)
and Analyze will not return an error.
Orphan zone
Check for zone data that have no corresponding Active Directory objects or have invalid links to Active Directory objects. For example, if
data objects
you delete an Active Directory user but do not remove the profile for this user in a zone, the zone profile becomes an orphan and is flagged
and invalid
as such by this option.
data links
Check for roles that have been assigned commands that cannot be executed. When rights are created, they can be defined to run in a
Restricted
restricted-shell role, in an enhanced role (with dzdo), or with both. If a command that has not been defined to run in a restricted-shell is
roles
added to a restricted-shell role, this check returns an error.
Zone created
Check for zone information created in another zone’s parent container. Note that this check does not look at hierarchical zones because it
under
is expected that child zones are physically contained in their parent zone.
another zone
Zone
information in Check for zone information stored in an obsolete Centrify zone format.
old format
Zoneless
Check for computers that do not belong to any zone.
computers
4. Review the result summary, then click Finish.
5. If the result summary indicates any issues, you can view the details by selecting Analysis Results in the console tree and viewing the information
listed in the right pane. For example:
Analysis results
For additional information, select the warning or error, right-click, then select Properties. For example:
Properties
Common scenarios that generate analysis results
For most organizations, it is appropriate to check the data integrity of the Active Directory forest on a regular basis. Although running the Analyze command
frequently may not be necessary for small networks with few domain controllers, there are several common scenarios that you should consider to determine
how often you should check the forest for potential problems. The most likely reasons for data integrity issues stem from:
Multiple administrators performing concurrent operations.
Administrators using different domain controllers to perform a single operation.
Replication delays that allow duplicate or conflicting information to be saved in Active Directory.
Insufficient permissions that prevent an operation from being successfully completed.
Network problems that prevent an operation from being successfully completed.
Partial or incomplete upgrades that result in inconsistency of the information stored in Active Directory.
Using ADEdit rather than the Console to create, modify, or delete zone objects, which may lead to problems, such as inadvertently creating a circular
zone structure or an empty profile.
Using third-party tools, such as ADSI Edit, to edit objects directly in Active Directory, which may lead to corrupted or invalid zone objects.
Running Analyze periodically helps to ensure the issues these scenarios can cause are reported in the Analysis Results, so you can take corrective action.
Responding to analysis results
Depending on the type of warning or error generated in the Analysis Results, you might be able to take corrective action or access additional information by
right-clicking a result, then selecting an appropriate action. For example, if a computer account lacks the permission required to update Active Directory with
the operating system version currently installed, you can right-click the warning in the Analysis Result then select Grant computer the rights to modify
operating system properties.
If right-clicking a result does not provide a responsive action, you should use Access Manager or ADEdit to correct the issue.
The following table describes the warnings and errors you may see in the Analysis Results after running the Analyze wizard and how to resolve potential
issues.
Result Responsive action
No responsive action can be taken directly within the Analysis Results for this issue. In general, this issue only
occurs if an administrator runs adleave with the --force option then runs adjoin to join the computer to a
If there are any computers joined to
different domain without removing the old computer profile from Active Directory. You should identify the
multiple zones, an error is displayed.
appropriate zone for the computer, then use the Access Manager console to delete the computer profile from
any additional zones.
If the parent-child relationship of any

Break the circular relationship.
zones is circular, an error is displayed.
occurs if multiple administrators perform concurrent operations or there are replication delays that allow a
If there are any duplicate groups in a duplicate group profile to be added to a zone. For example, if two administrators add the same group to a zone
zone, a warning is displayed. using different domain controllers, there will be duplicate group profiles after the domain controllers complete
replication. You should use the Access Manager console or ADSI Editor to delete the duplicate group profiles
from the zone.
No responsive action can be taken directly within the Analysis Results for this issue. Right-click the warning and
If any duplicate service principal names
click Properties to identify the duplicate SPN. Open the account properties for the user or computer and
(SPNs) are found for users or computers
modify or remove the duplicate servicePrincipalName value. Alternatively, run the adjoin command with the -d
in the forest, a warning is displayed.
or --forceDeleteObjWithDupSpn option. See the adjoin man page for additional information.
If there are any duplicate users in a zone, duplicate user profile to be added to a zone. For example, if two administrators add the same user to a zone
a warning is displayed. using different domain controllers, there will be duplicate user profiles after the domain controllers complete
replication. You should use the Access Manager console or ADSI Editor to delete the duplicate user profiles from
the zone.
No responsive action can be taken directly within the Analysis Results for this issue. Because an SFU zone is
If more than one Centrify SFU zone is associated with an Active Directory SFU schema extension, there should be a maximum of one SFU zone in an
found in the forest, a warning is Active Directory forest. In general, this issue only occurs if multiple administrators perform concurrent
displayed. operations or there are replication delays that allow a duplicate. You should use the Access Manager console or
ADSI Editor to delete any duplicate SFU zones.
If a duplicate default parent container for
duplicate default container for new zones. Having more than one default parent container for zones can result
zones is found, a warning is displayed.
in an unexpected default value in the Create New Zone wizard. You should use the ADSI Editor to delete any
duplicate Zones parent containers from the forest.
If the computer role has no member computers, right-click the warning in the Analysis Results, then select A d d
If a computer role does not have any computers to add computers, or Delete Computer Role to remove the computer role. If a computer role has
member computers or role assignments, computer members but no role assignments, the only available response from the Analysis Results zone is to
a warning is displayed. delete the computer role. You can, however, select the computer role in the Console, and add role assignments
to its Role Assignments node.
If a user or group profile has been added

Right-click the warning in the Analysis Results, then select Delete empty profile to delete the profile from
to a zone but has no attributes defined,
the zone, or Modify profile to define one or more attributes for the user or group.
an error message is displayed.
If any zone does not contain users,

groups, or computers, a warning is
No responsive action can be taken directly within the Analysis Results for these issues. In general, this issue
displayed for each type of object. For
occurs early in a deployment before you have populated zones. You should use the Access Manager console to
example, if a zone has computers and
add missing objects to the zone. If the empty zone is not a valid zone, right-click the zone and select Delete.
groups, but no users, only the user
warning is displayed for that zone.
If one or more secondary profiles are

Right-click the warning in the Analysis Results, then select Promote secondary profile to primary to
found for a user but no primary profile is
select a secondary profile you want to make the primary profile for the user.
found, a warning message is displayed.
If a user’s UNIX profile is incomplete in

Right-click the warning in the Analysis Results, then select Modify zone profile to define additional
the entire zone hierarchy, a warning
attributes to complete the user’s profile.
If the Active Directory group

Right-click the error in the Analysis Results, then select Create NIS servers group to create the
zone_nis_servers is not found in a zone
zone_nis_servers group for agentless authentication. Note that your account must have permission to create
configured for agentless authentication,
this object for the operation to be successful.
an error is displayed.
If the membership of the

zone_nis_servers group is not consistent
Right-click the error in the Analysis Results, then select Fix group membership to modify the membership
with the computers authorized as NIS
list for the zone_nis_servers group.
servers, a “Membership inconsistent”
error is displayed.
If a zone is configured to support

agentless authentication and the
No responsive action can be taken directly within the Analysis Results for these issues. You should verify that all
zone_nis_servers group exists but does
of the computers you want to use as NIS servers in the zone are configured to allow agentless authentication.
not contain all computers in the zone, an
informational alert is displayed.
If there is a discrepancy between the DNS

name in AD and the Centrify computer
Right-click the error in the Analysis Results, then select Fix group membership to
profile name, a warning message is
displayed.
If a computer account does not have

Right-click the error in the Analysis Results, then select Grant permission to computer account to
permission to write to the keywords
update the permissions on the computer account object.
attribute, an error is displayed.
If a computer account does not have

Right-click the error in the Analysis Results, then select Grant computer permission to modify
permission to modify operating system
operating system properties to update the permissions on the computer account object.
properties, a warning is displayed.
If a right for a role is invalid, a warning

Right-click the error in the Analysis Results, then select Delete Right to delete the right from the role.
If a role assignment is invalid, a warning

If multiple roles are assigned to a user, a

warning message is displayed.
If a child zone has an invalid parent zone,

an error message is displayed.
If an object has no parent object, a

warning message is displayed.
If a restricted-shell role is assigned a

Right-click the error in the Analysis Results, then select Delete Commands to remove the commands from
right that cannot be run in a restricted
the role, or select Allow running in restricted role to allow running the command in the restricted role.
shell, a warning message is displayed.
If any computers in the zone are running version 2.x or 3.x agents, you should ignore this warning to ensure
If a zone was created using the version
compatibility for those agents. If all of the agents in the zone have been upgraded, you can right-click the
2.x console and includes a Private Groups
warning in the Analysis Results, then select Remove privateGroupCreation attribute to update the zone
container, a warning is displayed.
format.
If any computers in the zone are running version 2.x or 3.x agents, you should ignore this warning to ensure
If a computer profile was created using
compatibility for those agents. If all of the agents in the zone have been upgraded, you can right-click the
the version 2.x console, the warning “Unix
warning in the Analysis Results, then select Remove managedBy and unix_enabled attribute to update
computer is in old format” is displayed.
the computer profile in the zone.
If a group profile was created using the

If all of the agents in the zone have been upgraded, you can right-click the warning in the Analysis Results, then
version 2.x console, the warning “Unix
select Remove managedBy attribute to update the group profile in the zone.
group is in old format” is displayed.
If a user profile was created using the

If all of the agents in the zone have been upgraded, you can right-click the warning in the Analysis Results, then
version 2.x console, the warning “Unix
select Remove managedBy and app_enabled attribute to update the user profile in the zone.
user is in old format” is displayed.
If a computer, group, or user profile

In general, this issue occurs if an administrator removes an Active Directory computer, group, or user object
exists, but no corresponding Active
manually using ADSI Editor or Active Directory Users and Computers but the corresponding data is not removed
Directory computer, group, or user object
for the UNIX profile. Right-click the warning in the Analysis Results, then select Remove orphan profile to
is found, the warning “Orphan UNIX data
remove all of the UNIX properties associated with the orphan profile.
object” is displayed.
Computer, group, and user profiles are associated with Active Directory computer, group, and user objects
If a computer, group, or user profile has
through either the managedBy attribute (agent version 2.x) or a parentLink value in the keywords attribute
inconsistent links, an informational
(agent version 3.x and later). If the links refer to different Active Directory objects, you will see this alert. Right-
“Inconsistent links” alert is displayed.
click the alert in the Analysis Results, then select Overwrite with the active link to remove outdated links.
If a computer, group, or user profile does

Right-click the warning in the Analysis Results, then select Missing parentLink to add the parentLink value to
not have a parentLink value defined, a
the keywords attribute.
“Missing parentLink” warning is displayed.
If the parent container for a zone is No responsive action can be taken directly within the Analysis Results for these issues. You should move the
another zone object, an error is displayed. zone to another parent container or delete and recreate the zone in a different location.
The computer ObjectName contains Right-click the warning in the Analysis Results, then select Move to Zone to search for and select the zone
Centrify information but it is not in a zone. you want to place the computer in.
Configuring logging for the agent
By default, the Centrify Agent for *NIX logs errors, warnings and informational messages in the UNIX syslog and /var/log/messages files along with other
kernel and program messages. Although these files contain valuable information for tracking system operations and troubleshooting issues, occasionally you
may find it useful to activate agent-specific logging and record that information in a log file.
To enable logging on the Centrify Agent for *NIX
1. Log in as or switch to the root user.
2. Run the addebug command:
Note: You must type the full path to the command because addebug is
not included in the path by default.
Once you run this command, all of the Centrify Agent activity is written to the /var/log/centrifydc.logfile. If the adclient process stops running while you
have logging enabled, the addebug program records messages from PAM and NSS requests in the /var/centrifydc/centrify_client.log file. Therefore,
you should also check that file location if you enable logging.
For performance and security reasons, you should only enable logging when necessary, for example, when requested to do so by Centrify Support, and for
short periods of time to diagnose a problem. Keep in mind that sensitive information may be written to this file and you should evaluate the contents of the file
before giving others access to it.
When you are ready to stop logging activity, run the addebug off command.
Setting the logging level
You can define the level of detail written to the log by setting the log configuration parameter in the Centrify configuration file:
log: level
With this parameter, the log level works as a filter to define the type of information you are interested in and ensure that only the messages that meet the
criteria are written to the log. For example, if you want to see warning and error messages but not informational messages, you can change the log level from
INFO to WARN. By changing the log level, you can reduce the number of messages included in the log and record only messages that indicate a problem.
Conversely, if you want to see more detail about system activity, you can change the log level to INFO or DEBUG to log information about operations that do
not generate any warnings or errors.
You can use the following keywords to specify the type of information you want to record in the log file:
Specify
this To log this type of information
level
Fatal error messages that indicate a system failure or other severe, critical event. In addition to being recorded in the system log, this type of
FATAL
message is typically written to the user’s console. With this setting, only the most severe problems generate log file messages.
System error messages for problems that may require operator intervention or from which system recovery is not likely. With this setting, both
ERROR
fatal and less-severe error events generate log file messages.
Warning messages that indicate an undesirable condition or describe a problem from which system recovery is likely. With this setting,
WARN
warnings, errors, and fatal events generate log file messages.
INFO Informational messages that describe operational status or provide event notification.
Logging for Access Manager
Although most logging activity focuses on the actions of the Centrify Agent, you can also enable or disable logging for the Access Manager console and
configure the types of messages to record in the log file by selecting options in Access Manager.
To configure logging for operations handled through the Access Manager console:
1. Open Centrify Access Manager.
2. In the console tree, select Centrify Access Manager, right-click, then click Options.
3. Click the Log Settings tab, select the type of messages to log, then click O K.
If you enable logging, the log file is located by default in the C:\Users\user\AppData\Roaming\Centrify\DirectControl folder and is updated as you perform
different operations in the Access Manager console.
Logging to the circular in-memory buffer
If the Centrify Agent for *NIX’s adclient process is interrupted or stops unexpectedly, a separate watchdog process (cdcwatch) automatically enables an in-
memory circular buffer that writes log messages passed to the logging subsystem to help identify what operation the adclient process was performing when
the problem occurred. The in-memory buffer is also mapped to an actual file, so that if there’s a system crash or a core dump, the last messages leading up to
the event are saved. Messages from the in-memory circular buffer have the prefix _cbuf, so they can be extracted from a core file using the strings
command.
The in-memory circular buffer allows debug-level information to be automatically written to a log file even if debugging is turned off. It can be manually
enabled by restarting the adclient process with the -M command line option. The default size of the buffer is 128K, which should be sufficient to log
approximately 500 messages. Because enabling the buffer can impact performance, you should not manually enable the circular buffer or modify its size or
logging level unless you are instructed to make the changes by Centrify Support.
Collecting diagnostic information
You can use the adinfo command to display or collect detailed diagnostic and configuration information for a local UNIX computer. Options control the type of
information and level of detail displayed or collected. The options you are most likely to use to collect diagnostic information are the --config, --diag, or --
support options, which require you to be logged in as root. You can redirect the output from any adinfo command to a file for further analysis or to forward
information to Centrify Support.
For more information about the options available and the information returned with each option, see the man page for adinfo.
To display the basic configuration information for the local UNIX computer, you can type:
adinfo
If the computer has joined a domain, this command displays information similar to the following:

Zone: ajax.org/Ajax/Zones/corporate
Licensed Features Enabled
Working with domain controllers and DNS servers
Delinea Agents are designed to perform the same set of DNS lookup requests that a typical Windows workstation performs to find the nearest domain
controller for the local site. The DNS lookup request enables the Centrify Agent for *NIX to find domain controllers as they become available on the network or
as the computer is relocated to another network location where different domain controllers are present. Centrify Agents also use DNS to find the Kerberos
service providers and the global catalog service providers for the Active Directory forest.
In a typical Windows environment, the DNS server role is updated dynamically to contain the service locater (SRV) DNS entries for Active Directory’s LDAP,
Kerberos, and global catalog services, so this information is available for Centrify Agents to use. However, there are some configurations of DNS that might
not provide all of the SRV records for the set of domain controllers that provide Active Directory service to the enterprise. You may also run into problems if
DNS for the enterprise runs on UNIX servers that cannot locate your Active Directory domain controllers. The next sections describe how you can adjust DNS
or Centrify Agent to ensure they work together properly in your environment.
Related topics
Configuring the DNS server role on Windows

Configuring DNS running on UNIX servers
Setting up DNS service on a target domain controller
Setting the domain controller in the configuration file
Configuring the DNS server role on Windows
One of the most common scenarios for running DNS in an environment with Active Directory is to add the DNS server role to a Windows domain controller or
another Windows server.
If you are already using DNS in Active Directory and dynamically publishing DNS service records, no additional configuration should be necessary. If you are
using DNS in Active Directory but have disabled dynamic updates, you should change the configuration for the DNS server role to allow dynamic updates.
Making this change will allow Centrify Agents to properly locate domain controllers in the site and select an appropriate new domain controller if a connection
to its primary domain controller is lost or the managed computer is moved to a new location on the network.
Configuring DNS running on UNIX servers
If your environment is configured to use UNIX-based DNS servers instead of Active Directory-based DNS servers and the UNIX system is configured to use
DHCP, the nameserver entry in /etc/resolv.conf file is set automatically to point to a DNS server.
If this DNS server is aware of the Active Directory domain you want to join, no further changes are needed. If the DNS server identified as a nameserver in the
/etc/resolv.conf file is not aware of the domain you are trying to join, for example, because you are using a test domain or a separate evaluation environment,
you need to either disable DHCP or manually set the location of the Active Directory domain controller in the Centrify configuration file.
Checking whether DNS can resolve the domain controller
In most cases, you can verify whether a UNIX computer can locate the domain controller and related services by running the ping command and verifying
connectivity to the correct Active Directory domain controller or by checking the nameserver entry in the /etc/resolv.conf file. This nameserver entry should
be the IP address of one of the domain controllers in the domain you want to join.
If the ping command is successful, it indicates the DNS server is aware of the Active Directory domain you want to join and no further changes are needed. If
the ping command is not successful, you will need to take further action to resolve the issue.
Resolving issues in locating Active Directory domain controllers
If the UNIX computer cannot find the Active Directory domain controller, there are several ways you can resolve the issue. Depending on your environment
and specific situation, you should consider doing one of the following:
Set up DNS on the target Active Directory domain controller and the manually configure the nameserver entry in the /etc/resolv.conf file to use that
domain controller as described in Setting up DNS service on a target domain controller.
Set the Centrify configuration file to manually identify the domain controllers you want to use as described in Setting the domain controller in the
configuration file.
Setting up DNS service on a target domain controller
One of the simplest ways to ensure that the UNIX computers can locate the Active Directory domain controller and related services is to use the DNS service
on the Active Directory domain controller as a DNS slave to the enterprise DNS servers. You can do this is by configuring the DNS server role on the Active
Directory domain controller, then specifying that domain controller in the UNIX computer’s /etc/resolv.conf file. You can then add a forwarder to the local
DNS on the domain controller that will pass on all lookups that it cannot satisfy to an enterprise DNS server.
This configuration does not require any changes to the enterprise DNS servers. Any look up request from the domain controller is simply a query from another
computer in the enterprise. However, the UNIX computers configured to use this slave DNS service will receive the appropriate Service Location (SRV)
records and global catalog updates for the Active Directory domain controller. In addition, the DNS service on the domain controller can be configured to
forward requests to the enterprise DNS servers so those requests can be answered when the local DNS service cannot respond.
Adding a DNS server role to an Active Directory domain controller
The specific steps for adding the DNS server role to a domain controller depend on the version of Windows Server you use. In most cases, you can use an
administrative tool, such as Server Manager, to add roles. Follow the instructions displayed in the wizard to add the DNS Server server roles, configure the
DNS server lookup zones, select the Allow both nonsecure and secure dynamic updates option.
After you have configured the DNS server role on the domain controller, the computer uses the local DNS server as its primary DNS server.
Configuring UNIX to use DNS service on the target domain controller
Once you have configured the DNS service to contain the required Active Directory entries, you simply need to modify the UNIX computer to send all DNS
lookup requests to the newly configured DNS server.
To configure the UNIX computer to use the new DNS server:
1. Open the /etc/resolv.conf file.
2. Set the IP address of the nameserver entry to the IP address of the DNS server on the Active Directory domain controller you just configured.
Setting the domain controller in the configuration file
If you are not able to use DNS to locate the Active Directory domain controllers on your network, you can manually specify one or more domain controllers in
the Centrify configuration file.
To manually specify a domain controller, add the following entry to the Centrify configuration file, /etc/centrifydc/centrifydc.conf:
dns.dc.domain_name: server_name [server_name ...]
For example, if you want to ensure the Centrify Agent uses the domain mylab.test and the domain controller named dc1.mylab.test, you could add the
following line to the /etc/centrifydc/centrifydc.conf file:
dns.dc.mylab.test: dc1.mylab.test
Note: You must specify the name of the domain controller, not its IP
address. In addition, the domain controller name must be resolvable using either
DNS or in the local /etc/hosts file. Therefore, you must add entries to the
local /etc/hosts for each domain controller you want to use if you are not using
DNS or if the DNS server cannot locate your domain controllers.
dns.dc.mylab.test: dc1.mylab.test dc2.mylab.test
The Centrify Agent will attempt to connect to the domain controllers in the order specified. For example, if the domain controller dc1.mylab.test cannot be
reached, the agent will then attempt to connect to dc2.mylab.test.
If the global catalog for a given domain is on a different domain controller, you can add a separate dns.gc.domain_name entry to the configuration file to
specify the location of the global catalog. For example:
dns.gc.mylab.test: dc3.mylab.test
You can add as many domain and domain controller entries to the Centrify configuration file as you need. Because the entries manually specified in the
configuration file override any site settings for your domain, you can completely control the Centrify Agent for *NIX’s binding to the domains in your forest
through this mechanism.
Note: In most cases, you should use DNS whenever possible to locate your
domain controllers. Using DNS ensures that any changes to the domain topology
are handled automatically through the DNS lookups. The settings in the
configuration file provide a manual alternative to looking up information
through DNS for those cases when using DNS is not possible. If you use the
manually-defined entries in the configuration file and the domain topology is
changed by an Active Directory administrator, you must manually update the
location of the domains in each configuration file.
Using the fixdns script
The Centrify Agent includes a fixdns script that you can use to inspect your environment and make the necessary configuration file changes for you.
To run this script, you need to specify the domain controller name and IP address:
fixdns domain_controller_name IP_address
For example if you intend to join the domain mytest.lab and the domain controller for that domain is dc1.mytest.lab and its address is 172.27.20.1, you would
run the following command:
fixdns dc1.mytest.lab 127.27.20.1
The fixdns script will then make the necessary changes to the /etc/hosts and the Centrify configuration file.
Note: This script does not update the /etc/resolv.conf file. If the
script cannot locate the domain controller using the existing /etc/resolv.conf
settings, it will assume that you want to use settings from the configuration
file.
What the Centrify DNS subsystem provides
Centrify provides a DNS subsystem that bypasses the local DNS resolver to address common issues that occur with many local DNS resolvers. These
common issues for local DNS resolvers include:
Degraded performance when connecting to a slow DNS server or when attempting to use dead DNS servers.
Degraded performance when reacquiring a DNS server that went offline and has come back online.
Degraded performance related to DNS timeouts.
Platform-related DNS idiosyncrasies, such as MDNS, appending.LOCAL suffixes, and so on.
The Centrify DNS subsystem performs the following functions:
Looks up hosts by name.
Looks up hosts by IP address.
Queries DNS service location records (SRV) to discover the domain controllers that support Active Directory services including KDC, KPASSWD, LDAP
and the global catalog.
Resolving a host name or IP address
When the DNS client subsystem receives a DNS requests, it attempts to resolve the host name or IP address by first checking the /etc/hosts file. If the file
contains a valid entry to resolve the specified host name or IP address, the DNS client subsystem processes the DNS request.
Entries in /etc/hosts must be in the following format:
IPv4_address hostname alias alias ...
where:
IPv4_address must be in the first position
hostname is a fully-qualified domain name and must be in the second position.
aliases are optional and follow the address and hostname entries.
For example:
192.169.147.135 ginger.acme.com ginger
Note: Service (SRV) record queries cannot be satisfied from the

/etc/hosts file.
If resolution by /etc/hosts is unsuccessful, the DNS subsystem attempts to select a DNS server that can be used to resolve the host name or IP address (as
described in the next section, Selecting a DNS server).
Selecting a DNS server
If unable to resolve a host name or IP address by finding an entry in the /etc/hosts name (as described in Resolving a host name or IP address), the Centrify
DNS subsystem attempts to find a DNS server to resolve the host name or IP address, as follows:
It checks for a working DNS server that has already been selected (cached in memory and stored in /var/centrify/kset.dns.server), and if available, uses
it.
If a working DNS server is not already selected, it checks /etc/resolv.conf for configured DNS servers, and if populated, selects the fastest one from the
list.
If no working DNS servers are found, the request fails.
At this point, DNS is considered down, and the Centrify DNS subsystem waits for the interval specified by the dns.dead.resweep.interval (default is 60
seconds), before attempting again to find a DNS server.
Specifying DNS-related parameters
Parameters in the Centrify configuration file control many aspects of Centrify DNS subsystem operation. Although you can set any of these parameters, the
default settings should provide you with optimal DNS operation. See the Configuration and Tuning Reference Guide for details about any of these parameters.
The DNS subsystem periodically checks in the background to see if a DNS server that is faster than the currently selected one is available. The
dns.alive.resweep.interval parameter determines how often this background check occurs; the default value is one hour (3600 seconds).
When a DNS server is selected, its address is stored in the kset.dns.server file, and it is used for all DNS requests until one of the following occurs:
The selected server stops responding.
A new server sweep discovers a faster DNS server and replaces it.
The adclient process is stopped and restarted, which triggers a sweep for a new DNS server.
The specified server is no longer in the list of servers in /etc/resolv.conf.
For the sweep, the dns.sweep.pattern parameter determines the probe pattern that is used to find a live DNS server; that is, it sets the protocol to use (TCP or
UDP) and the amount of time to wait for a response. By default, this parameter specifies both a TCP and UDP probe.
The dns.timeout and dns.udp.retries parameters determine the amount of time to wait, and how often to re-send a request when the current server does not
respond to a request. If the current server does not respond to a request within the specified time out period, it is considered down and Centrify looks for a
different server. If it cannot find a live server, DNS is considered down, and the Centrify Agent for *NIX waits for the period of the dns.dead.resweep.interval
parameter, 60 seconds by default, before performing a sweep to find a new server.
Filtering the objects displayed
For performance or security reasons, you might want to filter or limit the objects displayed in the Access Manager console. Depending on your environment,
you might want to display more or less information by setting filter options. These filter settings enable you to control both the number and type of objects
displayed. You should note, however, that these settings can affect the performance of the console.
To filter the objects listed in Access Manager:
2. In the console tree, select Access Manager, right-click, then click Options.
3. Click the Filter Settings tab.
4. Select Load all zones to automatically open either all zones in the connected forest or all zones in a specific parent container.
If you select this option and connected forest all zones in the forest are opened automatically each time you start Access Manager. Selecting
this option prevents you from opening or closing any zones manually. Depending on the number of zones you have, you might experience slower
performance in the console if you select this option.
If you select this option and container, you can then click Browse to search for a container from which to automatically load zones. Selecting this
option prevents you from opening or closing any zones manually. Depending on the number of zones you have in the selected container, you might
experience slower performance in the console if you select this option.
5. Select Show disabled Active Directory accounts to display disabled computer and user accounts or uncheck this option to hide disabled objects.
6. Select Show orphans to display all users, groups, and computers that have a UNIX profile or uncheck this option to hide all orphan profiles.
Orphan profiles are the service connection points that no longer have a corresponding Active Directory object. Hiding or removing orphan profiles can
improve console performance. For information about locating orphan profiles by running an analysis on the Active Directory forest, see Analyzing
information in Active Directory.
7. Select Show Auto Zone to display the users, groups, and computers that have joined the Auto Zone or uncheck this option to hide Auto Zone
information.
8. Set the Maximum number of items to be displayed in the list option to limit the total number of objects displayed in the console, up to total
maximum allowed (65535).
This setting applies to all of the objects displayed in Access Manager, including zones, computers, users, groups, pending users, pending groups, NIS
maps, and all defined rights, roles, and role assignments. Lowering the maximum number of items displayed improves performance when browsing the
listed items. Note that this setting does not affect the number of items you can define, only the number displayed.
9. Click O K.
Authentication Service issues on
Be aware of the following issue when working with the Authentication Service on UNIX or Linux systems:
The directory /var should not be NFS mounted or else DirectControl may not work properly. (Ref: IN-90009)
Please see KB-9092 for further details about using common UNIX commands with Privilege Elevation Service restricted shells.
Using Centrify commands for administrative tasks
This chapter provides an overview of the Centrify command-line interface and a list of the command-line programs you can execute locally on Centrify-
managed computers.
How and when to use command-line programs
UNIX command-line programs are installed by default when you install the Centrify Agent for *NIX. The commands are typically installed in one of the
following directories:
/usr/sbin, /usr/bin
/usr/share/centrifydc /bin
The Centrify Agent includes a large number of command-line programs that enable you to perform a variety of administrative tasks directly from a UNIX shell
or using a shell script. These command-line programs use the underlying adclient service library to perform important tasks on the computers you add to
Active Directory domains. For example, there are commands that allow you to remove a computer from an Active Directory domain, change an Active
Directory user’s password, and return detailed diagnostic information about the operations of a host computer.
You can use command-line programs interactively or in shell scripts when you must take action directly on a Centrify-managed computer, or when taking
action from a managed computer is most convenient. For example, individual users can use a command-line program to change their Active Directory
password from a login shell without logging on to a Windows computer.
Some command-line programs perform specific tasks that you will only use infrequently or under specific conditions. Other programs perform common
administrative tasks that you are likely to use repeatedly.
The most commonly used programs include the following:
The adjoin command is the first command you use to add a local computer to an Active Directory domain.
The adinfo command display summary or detailed diagnostic and configuration information for a computer and its Active Directory domain.
The adpasswd command allows you to change an Active Directory account password from a Centrify-managed computer.
The adgpupdate command allows you to force group policies to be refreshed immediately.
The adleave command allows you to remove a managed computer from its current Active Directory domain or from the Active Directory forest entirely.
Displaying usage information and man pages
To display a summary of usage information for any command-line program, type the command and the --help or -h option. For example, to see usage
information for the adleave command, type:
adleave --help
The usage information includes a list of options and arguments, and a brief description of each option. For example, if you specify adleave -h on the command
line, the command displays the command-line syntax and a list of the valid options you can use when you execute adleave commands, similar to the
following:
usage: adleave [options]

options:
-u, --user user[@domain] user name, default is administrator
-p, --password pw user password, prompts if absent
-s, --server ds domain server for leave operations
-Z, --zoneserver ds domain server for zone operations
useful if zone is in another domain
-C, --noconf do not restore PAM or NSS config
-G, --nogp do not restore Group Policy
-f, --force force local leave, no network activity
-v, --version print version information
-h, --help print this help information and exit
For more complete information about any command, you can review the information in the command’s manual (man) page. For example, to see the manual
page for the adleave command, type:
man adleave
Result codes used by multiple programs
Many Centrify command-line programs share a common set of result codes returned when an operation is successful or an error occurs. The following table
lists the result codes that are reserved for use by Centrify command-line programs.
Result Error name Indicates
0 ERR_SUCCESS Successful completion of the operation.
6 ERR_OTHERS Miscellaneous errors occurred during the operation.
7 ERR_USAGES Usage error occurred during the operation.
8 ERR_OP_ABORTED Operation aborted by user.
9 ERR_ROOT_PRIV Root privilege is required for the operation.
10 ERR_NOT_JOINED Computer is not currently joined to any Active Directory domain.
11 ERR_ALREADY_JOINED Computer is already joined to the current Active Directory domain.
12 ERR_JOINED_ANOTHER_DOMAIN Computer is currently joined to another Active Directory domain.
13 ERR_ADCLIENT_DOWN The adclient process is not running or not available.
14 ERR_ADCLIENT_DISCONNECTED The adclient process is running in disconnected mode.
15 ERR_ADLCIENT_STARTUP The adclient process failed to start.
16 ERR_DNS_TIMEOUT The DNS server is not responding and may be down.
17 ERR_DNS_GENERIC A generic DNS problem occurred during the operation.
18 ERR_INVALID_DOMAIN_NAME The Active Directory domain name is incorrect or not found in DNS.
19 ERR_INVALID_LOGON User name or password provided is not correct.
20 ERR_ACCOUNT_DISABLED The account specified has been disabled.
21 ERR_ACCOUNT_EXPIRED The account specified has expired.
22 ERR_ACCOUNT_EXISTS The account specified already exists,
23 ERR_ACCOUNT_NOTFOUND The account specified was not found in Active Directory.
24 ERR_PASSWORD_EXPIRED The account password has expired.
25 ERR_ZONE_NOTFOUND The zone cannot be found.
26 ERR_CONTAINER_NOTFOUND Invalid Active Directory container object.
27 ERR_INSUFFICIENT_PERM The account specified does not have permission to perform the operation.
28 ERR_CLOCK_SKEW The time difference between system clocks is beyond the acceptable range.
29 ERR_COMPUTER_NAME Invalid computer account.
30 ERR_CRED_INVALID Invalid credentials.
Result Error name Indicates
31 ERR_SERVICE_TKT_INVALID Invalid service ticket.
32 ERR_POLICY_NOT_MATCH Policy not matched.
33 ERR_REJECT_CHG_PASSWD Password change rejected.
34 ERR_WORKSTATION_DENY Workstation denied.
35 ERR_NOT_FIND_USER No matching user found.
36 ERR_NOT_FIND_GROUP No matching group found.
37 ERR_NOT_CONNECT_ADCLIENT An attempt to open a connection to the adclient process failed.
38 ERR_ADLCIENT_STOP Unable to stop the adclient process.
39 ERR_QUOTA_EXCEEDED The user has exceeded the number of join operations allowed.
40 ERR_OPEN_FILE The attempt to open a file failed.
41 ERR_READ_FILE The attempt to read a file failed.
42 ERR_COPY_FILE The attempt to copy a file failed.
For information about command-specific result codes, see the manual page for individual commandline programs.
Perform administrative tasks using commands
Most administrative tasks can be performed using Access Manager on a Windows computer or by using ADEdit commands or scripts from a Centrify-
managed computer that has access to the Active Directory domain controller. In some cases, however, there are operations that you must or prefer to
perform locally on a managed computer by executing commandline programs.
The command line programs allow you to perform administrative tasks—such as join or leave a domain or generate diagnostic information—directly in a UNIX
shell. Many of the command-line programs require administrative privileges or must run using root to perform privileged operations. You can define command
rights for these programs to grant permission to run them to other users.
The following table provides a summary of the command-line programs for access control and privilege management that are installed with the Centrify
Agent for *NIX. For complete information about the options you can specify for any command, see the man page for that command.
This command Enables you to do this
Clear the local cache on a computer. You can use this command to clear all cached information or a specific cache file. You can
adcache
also use the command to check a cache file for a specific key value and to reclaim disk space.
Check the operating system, network, and Active Directory connections to verify that a computer is ready to join an Active
adcheck
Directory domain.
Move a joined computer from a classic zone to a hierarchical zone. Before moving a computer with this command, you must use
adchzone
admigrate to migrate the classic zone to a hierarchical zone.
Start, stop, or manage operations for the Centrify Agent process on a local computer. In most cases, you should start and stop
adclient
adclient using a startup script.
Start or stop detailed logging activity for the Centrify Agent (adclient) process on a local computer. If you do not specify an option,
addebug the addebug command displays its current status, indicating whether logging is active or disabled. You must be logged in as root to
run this command.
Create a database file with zone information. You can then use the adreport command to generate reports from this file, or read it
addbloader
with standard tools.
Update DNS records on an Active Directory-based DNS server in environments where the DHCP server cannot update DNS records
addns
automatically.
adfinddomain Display the domain controller associated with the Active Directory domain you specify.
adfips Enable or disable FIPS-compliant encryption. You must be logged in as root to run this command.
Resolve UID and GID conflicts and change the ownership of a local user’s files to match the user and group IDs defined for the user
adfixid
in Active Directory.
adflush Clear the cache on a local computer. Executing adflush with no options expires the domain controller and global catalog caches.
Retrieve group policies from the Active Directory domain controller and apply the policy settings to the local computer and current
adgpupdate
user immediately.
adid Display the real and effective UIDs and GIDs for the current user or a specified user.
Display detailed Active Directory, network, and diagnostic information for a local computer. Options control the type of information
adinfo
and level of detail displayed.
adjoin Add the local host computer to the specified Active Directory domain. You must log in as root to run the adjoin command.
Create and manage Kerberos key tables (*.keytab files) and coordinate changes with the Kerberos key distribution center (KDC)
adkeytab
provided by Active Directory. The arguments required and options available depend on the operation you want to perform.
adleave Remove the local host computer from its current Active Directory domain. You must log in as root to run the adleave command.
adlicense Enable or disable licensed features on a local computer. You must log in as root to run the adlicense command.
admanagelocal Display currently managed local accounts, status of local account management, and force a foreground sync of local accounts.
Migrate information from a classic zone to a hierarchical zone. You can migrate a classic zone to a new peer hierarchical zone, or
admigrate
you can specify a parent zone for the migration.
Obscure sensitive information, such as email addresses, host names, and user names, that might be recorded in a log file before
adobfuscate sending the file to Centrify for analysis. You must create a pattern file to use with this command. The command reads the pattern
file and replaces items matching the patterns specified with generic values.
adpasswd Change the password of the user executing the command or change the password of another Active Directory user.
Query Active Directory for information about users and groups from the command line on a Centrify-managed computer. This
adquery command is provided for backward compatibility. In most cases, you should use adedit commands or scripts to perform
administrative tasks in Active Directory from Linux or UNIX computers.
Force the Centrify Agent process (adclient) to reload the configuration properties in the /etc/centrifydc.conf file and in other files
adreload
in the /etc/centrifydc directory.
Generate user, computer, command, and role assignment reports for a zone. You must run the addbloader command to create a
adreport
database containing information about a zone before you can run this command to generate a report.
adrmlocal Report and remove local user names that duplicate Active Directory user names.
Specify where to send audit trail events. You can choose to send audit trail events to the syslog facility, the Centrify auditing
adsendaudittrailevent
service, or both.
adsetgroups View or change the list of groups available for the current user.
adsmb Perform file operations, such as get a file, write a file, or display the contents of a directory using the Centrify smb stack.
Update user and group account information from the command line on Centrifymanaged computer. This command is provided for
adupdate backward compatibility. In most cases, you should use adedit commands or scripts to perform administrative tasks in Active
Directory from Linux or UJNIX computers.
Execute a privileged command as root or another specified user. You must be assigned a role that grants privileged command
dzdo
rights to use this command.
dzedit Edit a file as root or another user.
Display detailed information about the configuration of rights and roles for one or more specified users on the local computer. If
dzinfo
you do not specify a user, the command returns information for the currently logged on user.
Run commands in a restricted environment shell. This shell is a customized Bourne shell that provides environment variables, job
dzsh
control, command history, and access to specific commands defined by roles.
ldapadd Open a connection to the Active Directory domain controller or another LDAP server to add new entries.
Open a connection to the specified Active Directory domain controller or another LDAP server to compare LDAP entries. You can
ldapcompare use this command to determine whether a specified entry has a particular attribute-value combination. The only information
returned is whether the comparison evaluated to true or false. No other information about the entry is provided.
Open a connection to the specified Active Directory domain controller or another LDAP server using the provided distinguished
ldapdelete
name and password to delete the specified entry or entries.
ldapmodify
name and password to modify the specified entry or entries.
ldapmodrdn
name and password to move or rename the specified entry or entries.
ldapsearch
name and password to locate and retrieve the specified entry or entries.
Clear the Centrify Network Information Service cache on a local computer, or restart the service without flushing the cache. You
nisflush
must be logged in as the root user to run this command.
Using Python with Centrify objects
You can use Python commands or scripts to interact with Centrify objects on Linux systems. Centrify provides two Python modules that you can use in Python
scripts to communicate with the Centrify Agent for *NIX:
pylrpc: Calls reference internal LRPC objects and methods.
pycapi: Calls reference the Centrify API (CAPI) mainly for use with NSS and PAM.
Requirements
Python requirements:
Use Python version 3.4 or later
Add the following path to your PYTHONPATH variable:
/usr/share/centrifydc/python/lib64
For example, you can update the PYTHONPATH by running the following command:
$export PYTHONPATH=/usr/share/centrifydc/python/lib64
In your python scripts, you can import either module into your script with an import statement, such as the following:
import pylrpc
import pycapi
There are some sample scripts included so that you can what kinds of things you can do. Example python scripts are installed at
/usr/share/centrifydc/samples/python.
Python Pylrpc reference
This section covers the objects, methods, and other details for the Pylrpc module.
Pylrpc module objects
There are two objects in the Pylrpc module:
Session
This object works with the agent. When you construct this object, it creates a session with the agent automatically. When you delete this object, the
session closes automatically.
Error
This is the type of exceptions that the Session object methods raise upon failure.
Pylrpc session object methods
This section lists out each method that you can use with the session object in the Pylrpc module.
_init_()
Opens a session with the agent.
s=pylrpc.Session()
adinfo()
Get joining settings and status of the local system
Parameters:
none
Returns:
A Python dictionary with keys and values that use the string type.
Raises:
Error - if any error occurred
Example:
info = s.adinfo()
getUser(uid, option) and getUser(uname, option)
Query a user by UNIX UID, UNIX name or AD name
Parameters:
uid (int) or name (str)
option (int)
pylrpc.UNIX_ONLY : to ask adclient to return result only when the user is zone enabled
pylrpc.CHECK_AD_FIRST: to ask adclient to ignore cache and read from AD if connected
pylrpc.GROUP_MEMBERSHIP: to ask adclient to return user's group membership info
pylrpc.EXPIRED_GRP_MEMBERS: when used with pylrpc.GROUP_MEMBERSHIP, ask adclient to trigger asynchronous group membership refresh
for this user
Returns:
Object (see Description of object below)
Raises:
Example:
# Query a zone user by UNIX uid or UNIX name
user = s.getUser("username", pylrpc.UNIX_ONLY)
user = s.getUser(999999, pylrpc.UNIX_ONLY | pylrpc.GROUP_MEMBERSHIP)
# Query an AD user by AD name
# by UPN or samAccountName@domain
user = s.getUser("Krusty@domain.com", pylrpc.GROUP_MEMBERSHIP)
# by NTLM name
user = s.getUser("domain.com+krusty", pylrpc.GROUP_MEMBERSHIP | pylrpc.CHECK_AD_FIRST)
# by Canonical name
user = s.getUser("domain.com/Users/krusty")
getGroup(gid, option) and getGroup(gname, option)
Query a zone group by gid or name
Parameters:
gid (int) or name (str)
option (int)
pylrpc.UNIX_ONLY : to ask adclient to return result only when the group is zone enabled
pylrpc.CHECK_AD_FIRST: to ask adclient to ignore cache and read from AD if connected
pylrpc.GROUP_MEMBERSHIP: to ask adclient to return group’s group member info
pylrpc.EXPIRED_GRP_MEMBERS: when used with pylrpc.GROUP_MEMBERSHIP, ask adclient to trigger asynchronous member refresh for this
group
Returns:
Object (see Description of object below)
Raises:
Example:
# Query a zone group by UNIX gid or UNIX name
group = s.getGroup("username", pylrpc.UNIX_ONLY)
group = s.getGroup(999999, pylrpc.UNIX_ONLY | pylrpc.GROUP_MEMBERSHIP)
# Query an AD group by AD name
# by samAccountName@domain
group = s.getGroup("dba@domain.com", pylrpc.GROUP_MEMBERSHIP)
# by Canonical name
group = s.getGroup("domain.com/Users/dba")
flushCache(type)
Expire or flush adclient’s cache
Parameters:
type (int)
pylrpc.EXPIRE_OBJ_CACHE: force expire object data caches, equivalent to "adflush -e -fy"
pylrpc.FLUSH_DNS_CACHE: flush DNS cache, equivalent to "adflush -d -fy"
pylrpc.FLUSH_AUTH_STORE: flush authorization data cache, equivalent to "adflush -a -fy"
pylrpc.FLUSH_TRUSTS: flush domain trust cache, equivalent to "adflush -t -fy"
pylrpc.FLUSH_OBJ_CACHE: flush object data caches, equivalent to "adflush -o -fy"
pylrpc.FLUSH_BINDINGS: drop DC bindings, equivalent to "adflush -b -fy"
pylrpc.FLUSH_CONNECTORS: flush Centrify Connector info, equivalent to "adflush -c -fy"
Returns:
True on success
Raises:
Example:
result = s.flushCache(pylrpc.FLUSH_OBJ_CACHE | pylrpc.FLUSH_AUTH_STORE)
refreshObject
force flush a single object out from object data cache
Parameters:
type (int)
pylrpc.UserType
pylrpc.GroupType
name (str)
Can be UNIX name or AD name
Returns:
True on success
Raises:
Example:
result = s.refreshObject(pylrpc.UserType, "username")
result = s.refreshObject(pylrpc.GroupType, "groupname")
Pylrpc Error object methods
The base class of Error is the Python Exception class.
Here's an example:
try:
s = pylrpc.Session()
except pylrpc.Error as ex:
print("ERROR: %s, code= %s" % (ex.message(), ex.code()))
message()
The error message
Returns:
message as (str)
code()
Returns the error code.
Returns:
code as (int) (See codes and error messages)
Codes and error messages
Code Error message
9 Root privilege is required for the operation
10 The system is not joined to any domain
13 adclient is not running/not available
52 User not found in zone
35 Active Directory user not found
53 Group not found in zone
36 Active Directory group not found
6 Other misc errors
Pylrpc dictionary objects
Some of the pylrpc methods return objects, those are described below. A dictionary is a data type in Python that's used to store a set of key:value pairs.
Object
Description
name
The Object is a dictionary object that stores the attributes of the object returned. For each item in the dictionary object, the key is a string, and the
Object
value is a list of bytes objects. If the attribute has only one value, the attribute will be a list with only one bytes object.
Python Pycapi Reference
This section covers the objects, methods, and other details for the Pycapi module.
Pycapi Module Methods
The following table provides a summary of the available methods in the pycapi module. Click the method name to go to the details for that method.
Return
Return
Method Name Method description value
description
type
The CAPI
GetMajorVersion() Returns the CAPI library's major version number. int library's major
version number
The CAPI
GetMinorVersion() Returns the CAPI library's minorversion number. int library's minor
version number
Does housekeeping in preparation for exiting a program that is using the CAPI library. Calling this
Shutdown() function is optional, but if if the in-memory SID cache is enabled it will take care of freeing up any n/a
allocated memory associated with the cache.
The string
GetCdcCodeStr(code) Returns the string associated with the supplied code. parameter: code (int) -code string associated with
the code.
The name of
GetErrSystemStr(system) Returns the name of the error subsystem with an ID. parameters: system (int) - error system ID string the error
subsystem.
The Active
Returns the Active Directory domain name from the distinguished name or canonical name in upper
DomainFromDN() string Directory
case. Parameters: dn (string) - error system ID
domain name
Pycapi Module Objects
There are two objects in the Pycapi module:
Session
This object works with the agent. When you construct this object, it creates a session with the agent automatically. When you delete this object, the
session closes automatically.
Error
Session Object Methods
This section lists details about each method that you can use with the Session object.
Create a session with the agent using the open method.
Disconnect from the agent using the close method.
close()
Disconnect from the agent and free all resources associated with the session.
open(majorVersion, minorVersion)
Parameters:
majorVersion(int): major version of required CAPI version
minorVersion(int): minor version of required CAPI version
If you specify majorVersion:
You must specify the major version of the Centrify API (CAPI). If the current version of CAPI is lower than the specified version, this method call fails.
Optionally you can also specify the minorVersion.
If you don't specify the version parameters, the service doesn't do any version checking.
Raises
getOption(option)
Get an option's current setting with an ID.
Parameters:
option (int) - option ID (see Option constants)
Returns:
value as (int)
Raises:
setOption(option, value)
Set an option with an ID and a value.
Parameters:
option (int): option ID (see Option in Constants)
value (int): option value
Raises:
setSessionID(id)
Set a session-specific string. This string will show up in the agent event logs to provide an easy way to track logging events specific to requests generated by
this CAPI session.
Parameters:
id (str) - session-specific string
Raises:
isSessionConnected()
Check whether the session is connected to the DirectControl agent and the session is valid.
Returns:
code as (int). If the session is connected and valid, the code value will be CODE_SUCCESS (see Code constants).
getSessionCode()
Get the code from the last session transaction.
Returns:
code as (int) (see Code constants)
ldapFetch(domain, dn, attrs)
Fetch a specific object from Active Directory.
Parameters:
domain (str) - domain to search in. Specify either a domain name, or "$" to use global catalog or "" to use the default domain controller.
dn (str) - the DN to return. An empty string "" can be used to specify the DSE root.
attrs (list of str) - the attributes to return. An empty list or None will return only the attributes DirectControl normally caches for the matched object.
Returns:
Object (see Object)
Raises:
lookupObjectByUnixId(type, id)
Look up a user or group by Unix ID.
Parameters:
type (int) - object type (see Object type constants)
id (int) - Unix user ID or group ID
Returns:
Object (see Object)
Raises:
lookupObjectByName(category, name)
Look up a user or group by name in a category.
Parameters:
category (str) - category (see AD Category constants ) to limit the search
name (str) - user name or group name
Returns:
Object (see Object)
Raises:
lookupObjectByGuid(guid)
Look up a user or group by GUID.
Parameters:
guid (str) - GUID
Returns:
Object (see Object)
Raises:
lookupObjectBySid(sid)
Look up a user or group by SID.
Parameters:
sid (str) - SID
Returns:
Object (see Object)
Raises:
getDomainRids()
Get the domain map of all of the accessible domains with their corresponding RID information.
Returns:
KeyValueSet (see KeyValueSet)
Raises:
Error - if any error occurred. If the domain map construction is not complete, the code will be TRY_AGAIN.
networkChange()
Notify adclient that there was a network change on the system.
Returns:
code as (int). If success, the code value will be CODE_SUCCESS (see Code constants)
ping()
Test the connection to the agent.
Returns:
getKerberosName(name, useSamName)
Get the Kerberos principal name of a user.
Parameters:
name (str) - user name
useSamName (int) - TRUE will use sAMAccount name (see Boolean constants)
Raises:
authValidateAccount(name, flags)
Check a user account to see if any logon restrictions currently apply.
Parameters:
flags (int) - validate flags (see Validate Flag constants)
Returns:
authValidatePlainTextUserNonCDC(name, password)
Validate a non-DirectControl managed user.
Parameters:
password (str) - user password
Returns:
authValidatePlainTextUser(name, password)
Validate a user and password using Kerberos.
Parameters:
password (str) - user password
Returns:
systemHealthInfo(refresh=FALSE)
Return information about DirectControl's system health.
Parameters:
refresh (int) - if FALSE, return information from last API call. If TRUE, send a probe to collect updated information. (See Boolean constants)
Returns:
KeyValueSet (see KeyValueSet)
Raises:
getForestList(flags)
Get the trusted forest information list.
Parameters:
flags (int) - flags (see Get DC Flag constants)
Returns:
ObjectList (see ObjectList)
Raises:
getDomainList(flags)
Get the trusted domain information.
Parameters:
Returns:
ObjectList (see ObjectList)
Raises:
getDCInfo(name)
Get Information about a specific domain controller (DC).
Parameters:
name (str) - name of the domain controller
Returns:
Object (see Object)
Raises:
getDomainControllers(name, flags)
Get a list of domain controllers for specific domain.
Parameters:
name (str) - name of the domain
Returns:
StringSet (see StringSet)
Raises:
getAuditLevel(name)
Get audit level of a user.
Parameters:
Returns:
audit level as (int) (see Audit Level constants)
Raises:
Throw Error exception in case of error.
Error Object Methods
The base class of Error is the Python Exception class.
message()
Returns a message as a string
Returns:
message as (str) (see Audit Level constants)
code()
Returns code
Returns:
code as (int) (see Code constants)
Pycapi Module Constants
This section lists out the different constant values that can be used with the Pycapi module.
Boolean Constants
Constant Value
TRUE 1
Constant Value
FALSE 0
Code Constants
Constant Value
CODE_SUCCESS 0
CODE_FAILURE 1
CODE_NOMEM 2
CODE_BAD_OPTION 3
CODE_BAD_PARAM 4
CODE_BAD_SESSION 5
CODE_LRPC_FAILED 6
CODE_NO_MORE 7
CODE_NO_SUCH_ATTR 8
CODE_NO_SUCH_OBJECT 9
CODE_SERVER_UNREACHABLE 10
CODE_SEARCH_IN_PROGRESS 11
CODE_BAD_VERSION 12
CODE_INVALID_USER 13
CODE_INVALID_PASSWORD 14
CODE_ACCOUNT_LOCKED 15
CODE_PASSWORD_EXPIRED 16
CODE_PASSWORD_POLICY_NOT_MATCHED 17
CODE_PASSWORD_CHANGE_REJECTED 18
CODE_ACCOUNT_EXPIRED 19
CODE_ACCOUNT_DISABLED 20
CODE_WORKSTATION_DENIED 21
CODE_PERMISSION 22
CODE_BAD_PACKET 23
CODE_BAD_DATA 24
Constant Value
CODE_NOT_JOINED 25
CODE_VALUE_NOT_SET 26
CODE_IO_ERROR 27
CODE_SYS_ERROR 28
CODE_NO_SYS_ERROR_INFO 29
CODE_WRONG_DATA_TYPE 30
CODE_MULTI_VALUE 31
CODE_NO_ADCLIENT 32
CODE_LOGON_FAILURE 33
CODE_NOT_GROUP_MEMBER 34
CODE_FOREIGN_DOMAIN 35
CODE_NOT_FOUND 36
CODE_EXISTS 37
CODE_TRUST_ERROR 38
CODE_ACCOUNT_LOGON_HOURS 39
CODE_ACCOUNT_WORKSTATION 40
TRY_AGAIN 41
CODE_NO_DNS 42
CODE_BAD_COMPUTER_OBJECT 43
CODE_ACCOUNT_RESTRICTION 44
CODE_ALREADY_JOINED 45
CODE_CLIENT_DISCONNECTED 46
CODE_GROUP_POLICY_NOT_FOUND 47
CODE_INVALID_CONTAINER 48
CODE_NAME_MATCHES_DC 49
CODE_NETWORK_ERROR 50
CODE_OUT_BOUND_TRUST 51
CODE_PROCESS_AUTHENTICATION 52
Constant Value
CODE_UNKNOWN 53
CODE_ZONE_ACCESS_PERMISSION 54
CODE_IN_ANOTHER_DOMAIN 55
CODE_FIPS_NONCOMPLIANT 56
CODE_BLOCKED 57
CODE_REENTERED 58
CODE_PASSWORD_DID_CHANGE 59
Error System Constants
Constant Value
ERR_SYS_NONE 0
ERR_SYS_KERBEROS 1
ERR_SYS_LDAP 2
ERR_SYS_NTSTATUS 3
ERR_SYS_BASE 4
ERR_SYS_AZMAN 5
ERR_SYS_DNS 6
ERR_SYS_NETWORK 7
ERR_SYS_GP 8
ERR_SYS_FIPS 9
ERR_SYS_EOL 10
Option Constants
Constant Value
OPT_UNIX_ONLY 0x00000001
OPT_CHECK_AD_FIRST 0x00000002
OPT_GROUP_MEMBERSHIP 0x00000004
OPT_UNIX_NAME 0x00000008
OPT_WINDOWS_NAME 0x00000010
Constant Value
OPT_APPLY_OVERRIDES 0x00000020
OPT_ZONE_SEARCH 0x00000040
OPT_AUTO_RECONNECT 0x00000080
OPT_AUTH_VALIDATE_ACCOUNT 0x00000100
OPT_CREATE_KRB5_CACHE 0x00000200
OPT_NO_CACHE 0x00000400
OPT_REFRESH_MEMBERSHIP 0x00000800
OPT_AUTH_VALIDATE_ACCT_PREFER_CACHE 0x00001000
OPT_LOCATE_ALL_SERVICES 0x00002000
Object Type Constants
Constant Value
OBJTYPE_USER 1
OBJTYPE_GROUP 2
OBJTYPE_COMPUTER 3
AD Category Constants
Constant Value
AD_CATEGORY_GROUP "Group"
AD_CATEGORY_USER "Person"
AD_CATEGORY_COMPUTER "Computer"
AD_CATEGORY_CONTAINER "Container"
AD_CATEGORY_ORGUNIT "Organizational-Unit"
AD_CATEGORY_SCP "Service-Connection-Point"
AD_CATEGORY_CLASS_STORE "Class-Store"
AD_CATEGORY_FSP "Foreign-Security-Principal"
AD_CATEGORY_ANY ""
Get DC Flag Constants
Constant Value
GETDC_FLAGS_GET_ALL 0x00000001
GETDC_FLAGS_WRITABLE 0x00000002
GETDC_FLAGS_NO_LIVE_TEST 0x00000004
GETDC_FLAGS_DONT_READ_CACHE 0x00000008
GETDC_FLAGS_IGNORE_KSET 0x00000010
GETDC_FLAGS_DEEP_SWEEP 0x000000020
GETDC_FLAGS_SPEED_SORT 0x000000040
GETDC_FLAGS_ANY_SITE 0x000000080
AD Attribute Constants
Constant Value
AD_ATTR_USERNAME "name"
AD_ATTR_USER_PRINCIPAL_NAME "_userPrincipalName"
Validate Flag Constants
Constant Value
VALIDATE_ACCT_LOCKOUT 0x00000001
VALIDATE_ACCT_DISABLED 0x00000002
VALIDATE_ACCT_EXPIRED 0x00000004
VALIDATE_PASSWD_EXPIRED 0x00000008
VALIDATE_WORKSTATIONS 0x00000010
VALIDATE_LOGON_HOURS 0x00000020
VALIDATE_ALL 0xffffffff
Audit Level Constants
Constant Value
AUDITLEVEL_NOTSET -1
AUDITLEVEL_AUDITIFPOSSIBLE 0
AUDITLEVEL_NOAUDIT 1
AUDITLEVEL_AUDITREQUIRED 2
Constant Value
AUDITLEVEL_SYSRIGHTS 3
Pycapi Dictionary Objects
Some of the pycapi methods return objects, those are described below. A dictionary is a data type in Python that's used to store a set of key:value pairs.
Object
Description
Name
The Object is a dictionary object that stores the attributes of the object returned. For each item in the dictionary object, the key is a string,
Object
and the value is a list of bytes objects. If the attribute has only one value, the attribute will be a list with only one bytes object.
ObjectList A list of objects.
StringSet A list of strings.
KeyValueSet A dictionary of strings.
Administering macOS Systems
About Delinea Management Services for Mac
With Delinea Management Services for Mac, you can use Active Directory to centrally manage authentication, policy enforcement, single sign-on (SSO), and
user self-service for popular endpoint devices running Mac operating systems.
A key component of Delinea Management Services for Mac is the DirectControl agent for Mac computers. You must install the agent on each computer that
you want to integrate with Active Directory and manage through Delinea Access Manager.
After you install the agent on a Mac computer, you can perform many administration and configuration tasks on the computer to enable the computer to work
with Delinea Management Services and with Active Directory.
Intended Audience
This guide is intended for Mac system administrators.
Topics Covered in this Guide
Installing the DC Agent Creating Home Directories Working with Macs Understanding Group Policies Setting Computer-based Policies Setting User-based
Policies Configuring a Mac for Smart Card Login Troubleshooting Installing and Removing the Agent
The Administrator’s Guide for Mac provides information about the administration and configuration tasks that you perform on a Mac computer after you
install the agent so that you can manage users, groups, computers, and zones with Access Manager. Additional topics, such as installing the agent, optionally
enrolling the computer in the Delinea Platform, and troubleshooting issues after the agent is installed are also covered.
Specific areas of focus are as follows:
This guide provides installation instructions and step-by-step instructions for configuring Mac computers to join an Active Directory domain through
Auto Zone, which creates one large zone for all Mac computers. Auto Zone requires minimal configuration and is appropriate for most Mac
environments. If your environment is larger, or more complex, and doesn’t easily fit into Auto Zone, you must consult the Planning and Deployment
Guide for detailed information on how to move your Mac users and computers to Active Directory and use Delinea zones to structure your environment.
This guide explains how to handle issues and tasks that are specific or unique to a Mac environment.
This guide does not cover planning or Access Manager tasks handled through the Access Manager console. For more information about those topics, see
Where to go for more information.
This guide assumes you have a working knowledge of performing administrative tasks in a Mac environment.
Installing the DirectControl Agent for Mac
This section explains how to install the DirectControl Agent for a Mac computer.
Preparing to Install the DirectControl Agent for Mac
You must install the DirectControl Agent for Mac on each computer that you want to manage through Delinea and Active Directory. You can check the
Release Notes included with the software, or visit the Delinea Web site (scroll to Supported Platforms and click the Details tab) to verify that each
computer where you plan to install is running a supported version of the mac operating system.
Note: The installation package also contains a utility, ADCheck, which verifies that each of your Mac computers is ready for installation of the
DirectControl agent. ADCheck confirms that a computer is running a supported OS, has sufficient disk space to install the DirectControl agent,
and that the domain you intend to join has functioning domain controllers and DNS servers. Information about running ADCheck is included in this
documentation.
Installing the Agent on Apple M1 Mac Computers
Depending on whether you using the graphical installer or the command line version to install the DirectControl Agent for Mac on Apple M1 Mac computers,
you may need to install some additional software.
If you install the DirectControl Agent for Mac on an Apple M1 Mac computer using the graphical user interface, you might be asked to install Rosetta.
Click Install, then enter your user name and password to allow installation to proceed.
For more information, see https://support.apple.com/en-us/HT211861.
If you install the DirectControl Agent for Mac on an Apple M1 Mac computer using the install.sh script, or by installing remotely, you might need manually
install Rosetta first. Please run the following command with root privileges to install Rosetta 2:
/usr/sbin/softwareupdate --install-rosetta --agree-to-license
Verifying DirectControl Agent for Mac Installation Prerequisites
Before installing the DirectControl Agent for Mac on your Mac computers, be certain that you or another administrator has installed Delinea Management
Services on a Windows computer in the domain. Delinea Management Services includes the Access Manager Console, which is the primary management
console for performing ongoing operations, including the application of group policies. Always install this console unless you are installing and running
Delinea Express for Linux and UNIX, which does not contain a console component.
For information about other Delinea Management Services components, such as Zone Provisioning Agent, see the Planning and Deployment Guide and the
Administrator’s Guide for Linux and UNIX.
Deciding When and How to Join a Domain
Following installation, you will be prompted to join a domain. Whether to join a domain depends primarily on how you intend to join. Delinea provides two ways
to join a domain:
Through Auto Zone, which is the recommended method for installations with 1500 or fewer users. When joined through Auto Zone, all users and groups
defined in Active Directory for the forest — as well as all Active Directory users defined in a forest with a two-way, cross-forest trust relationship to the
forest of the joined domain — automatically become valid users and groups on the Mac computer.
By connecting to a specific Delinea zone, which is the recommended method for installations with 1500 or more users, or for installations in which fine-
tuned access control is needed. A zone is similar to an Active Directory organizational unit (OU) and allows you to organize the computers in your
organization in meaningful ways to simplify account and access management and the migration of information from existing sources to Active
Directory.
The assumption of this guide is that you are joining Auto Zone. After installation, you can follow the instructions to join the domain and with a few
configuration steps all your Active Directory users will be able to log into this computer.
Note: If you have a set of Apple Open Directory users, you should migrate them following installation but before joining a domain.
On the other hand, if your environment requires a zone structure, you must create that structure before joining a domain. Therefore, after installing the
DirectControl agent, consult the Planning and Deployment Guide and the Administrator’s Guide for Linux and UNIX, which explain in detail how to plan, create,
and maintain an Active Directory installation of non-Windows computers with Server Suite.
Installing the DirectControl Agent
The DirectControl Agent for Mac can be installed in several different ways. The procedure in this section shows how do so by double-clicking the Delinea
Installer package (DMG) and following the instructions displayed on the screen. This installation method is recommended for most users when installing on a
single computer or a limited number of computers.
When you use the Delinea package installer, you will be prompted to join the domain. You may also join the domain after installation using either the adjoin
command-line program or the Delinea Directory Access plug-in.
Delinea provides a number of other ways to install the DirectControl Agent for Mac
By executing the DirectControl Agent for Mac installation script, install.sh in a Terminal window on a Mac computer and following the instructions
displayed by the script.
If you are an experienced UNIX administrator and are familiar with UNIX command-line installations, running install.sh is a good method to use. When you
install using the install.sh script, you can automatically join an Active Directory domain as part of the installation process; see Installing Using the
install.sh Script for details.
By installing remotely, without user interaction, using Apple Remote Desktop. This is a good method to use if you are using Apple Remote Desktop for
software distribution. With Apple Remote Desktop you can add pre- and post-installation scripts that allow you to join the remote computer to a domain
after installation; see Installing Silently on a Remote Computer for details.
To install the DirectControl Agent for Mac on a Mac computer using the graphical user interface:
1. Before installing the DirectControl Agent for Mac, disable Apple’s built-in Active Directory plug-in, and remove Active Directory from the Authentication,
and Contacts search paths. For more information, see Disabling the Apple Built-in Active Directory Plug-in.
2. In addition, be certain that the Apple Directory Utility is closed.
3. Log on with the Administrator account.
4. Navigate to the directory on the CD or your local network where the agent package is located. For example, if you are installing from the Delinea CD,
open the MacOS directory.
5. Double-click the DMG file, for example:
centrifydc-release-mac10.10-x86_64.dmg
6. Double-click ADCheck to open the ADCheck utility.
ADCheck performs a set of operating system, network, and Active Directory checks to verify that the Mac computer meets the system requirements
necessary to install the DirectControl Agent for Mac and join an Active Directory domain.
7. Enter the domain you intend to join with the Mac computer and click AD Check; for example:
8. Review the results of the checks performed. If the target computer, DNS environment, and Active Directory configuration pass all checks with no
warnings or errors, you should be able to perform a successful installation and join the specified domain. If you receive errors or warnings, correct them
before proceeding with the installation; see the Administrator’s Guide for Linux and UNIX for more information about ADCheck.
9. Double-click the DelineaDC package to open the Installer:
10. Review the information in the Welcome page, then click Continue.
11. Review or print the terms of the license agreement, then click Continue; click Agree to agree to the terms of the license agreement. Then click
Install (note that you cannot change the volume on which the agent is installed — it must be on the same volume as Mac OS X).
12. If prompted, enter the administrator name and password, and click Install Software to install the DirectControl Agent for Mac.
If you see the following warning box, click O K. If you did not have Directory Utility running during the installation, you can ignore the warning. If Directory
Utility was open, you can quit and restart it to show the correct status of the Delinea plug-in.
The installation process runs and presents the Installation Completed page once the DirectControl Agent for Mac is installed.
13. Select Launch Delinea Join Assistant if you want to join a domain, then click Continue.
Note: If you know that you want to use Delinea zones in your environment, exit the installer now. You must create zones first, before you can
join to one. Refer to Deciding When and How to Join a Domain for more information.
If you chose not to launch the Delinea Join Assistant before clicking Continue, the installer presents a summary indicating that the installation was
successful. You can now close the installer.
If you chose to launch the Delinea Join Assistant, you can start the process of Joining an Active Directory Domain described in the next section.
Note: If the Mac system is MacOS 11 or later, you must configure full disk access for the DirectControl Agent for Mac before you join the
system to an Active Directory domain.
Joining an Active Directory Domain
This topic shows how to use the Delinea Join Assistant to join a domain. To join a domain, you must be a domain admin or a domain user with permission to
create computer objects. If necessary, your domain administrator can use the Delegation Wizard to delegate permission to create computer objects. Refer to
Who Can Add a Workstation to a Domain for more information.
Note: Alternately, you may run the adjoin command-line utility, interactively or in a script, for each Macintosh computer you want to add to a
domain in the forest. See the Administrator’s Guide for Linux and UNIX for details.
To join the Mac to a domain:
1. Launch the Delinea Join Assistant.
There are two ways to launch the Delinea Join Assistant:
from the DirectControl agent installer, as described in Installing the DirectControl Agent for Mac.
click Applications > Utilities > Delinea, double-click Delinea Join Assistant to open it, then click Continue on the Welcome page
2. Enter the active directory domain that you want to join as well as administrator credentials for that domain, then click Continue.
A page appears that allows you to select how to join the domain with an option to enroll in the Privileged Access Service.
3. Select from the following options:
Select this
To do this
option
Joins the computer through Auto Zone, which allows joining a computer with little or no configuration. This option is recommended
Auto
for most installations.
Zone Joins to the zone that you type in the box. Note that you must have created at least one zone before you can use this option.
Computer Defaults to the name of the computer on which you are running the join assistant, but you can change it if you want to use a different
name name for the local host in Active Directory.
Note: Enrollment is no longer supported.
4. (Optional) Click the arrow to expand the Advanced Options and select any Advanced Options that you want to use to join the device.
Select
this To do this
option
Overwrite the information stored in Active Directory for an existing computer account. This option allows you to replace the information
Overwrite
for a computer previously joined to the domain. If there is already a computer account with the same name stored in Active Directory, you
existing
must use this option if you want to replace the stored information. You should only use this option when you know it is safe to force
joined
information from the local computer to overwrite existing information. Checking this option is the same as running the adjoin command
computer
with the --force option.
Specify the distinguished name (DN) of the container or Organizational Unit in which you want to place this computer account. By default,
computer accounts are created in the domain’s default Computers container. Click Browse to browse Active Directory and select the
Container
container to use, or click Container DN and enter the name of the container in distinguished name format; for example, if the domain
DN
suffix is acme.com and you want to place this computer in the paris.regional.sales.acme.com organizational unit, you would type: ou=paris,
ou=regional, ou=sales Checking this option is the same as running the adjoin command with the --container option.
Preferred Specify the name of the domain controller to which you prefer to connect. You can use this option to override the automatic selection of a
Domain domain controller based on the Active Directory site information. Checking this option is the same as running the adjoin command with
Server the --server option.
Computer Specify an alias name you want to use for this computer in Active Directory. This option creates a Kerberos service principal name for the
Alias alias and the computer may be referred to by this alias. Checking this option is the same as running the adjoin command with the --alias
Name option.
5. Click J o i n.
Delinea Join Assistant informs you that you have successfully joined your Mac to your Active Directory domain at <mydomain.com>.
6. Click Done to close the Delinea Join Assistant.
Your Active Directory users can now log on to the joined Mac computer, as described in Logging onto the Mac after Joining a Domain.
Configuring Full Disk Access for the DirectControl Agent for Mac
Due to a limitation of MacOS 11.x and MacOS 12.x, “Full Disk Access” is required for the DirectControl Agent for Mac. You can configure this yourself if you're
an administrator on the computer, or you can set it by way of your MDM (Mobile Device Management) provider.
To configure full disk access as an administrator:
1. Log in to the Mac computer as an administrator user.
2. Open System Preferences.
3. Click Security & Privacy.
4. Click Privacy.
5. Click Lock and then enter the password or use TouchID to unlock.
6. In the left pane, scroll down and select Full Disk Access.
7. Click + (the plus button).
8. Press and hold these three keys together: Sshift + Command + G.
9. Enter the path "/usr/local/sbin/adclient" and click G O, then click Open to add the path.
10. Repeat step 7 and 8, then input the path "/Applications/Utilities/Centrify/Centrify Join Assistant.app" and click G O, then click Open to add the path.
11. Repeat step 7 and 8, then input the path "/Applications/Utilities/Centrify/Smart Card Assistant.app" and click G O, then click Open to add the path.
12. Click Lock again to lock the system preferences.
Configuring Full Disk Access Through Your MDM Provider
Contact your MDM provider for more information. Your MDM provider will need the following information:
% codesign -dv /usr/local/sbin/adclient

Executable=/usr/local/sbin/adclient
Identifier=adclient
...
% codesign -dr - /usr/local/sbin/adclient
Executable=/usr/local/sbin/adclient
designated => identifier adclient and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and
certificate leaf[subject.OU] = "64CT837G5Z"
% codesign -dv /Applications/Utilities/Centrify/Centrify\ Join\ Assistant.app
Executable=/Applications/Utilities/Centrify/Centrify Join Assistant.app/Contents/MacOS/Centrify Join Assistant
Identifier=com.centrify.cdc.centrifyjoinassistant
...
% codesign -dr - /Applications/Utilities/Centrify/Centrify\ Join\ Assistant.app
Executable=/Applications/Utilities/Centrify/Centrify Join Assistant.app/Contents/MacOS/Centrify Join Assistant
designated => identifier "com.centrify.cdc.centrifyjoinassistant" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate
leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "64CT837G5Z"
% codesign -dv /Applications/Utilities/Centrify/Smart\ Card\ Assistant.app
Executable=/Applications/Utilities/Centrify/Smart Card Assistant.app/Contents/MacOS/SCTool
Identifier=com.centrify.cdc.smartcardassistant
...
% codesign -dr - /Applications/Utilities/Centrify/Smart\ Card\ Assistant.app
Executable=/Applications/Utilities/Centrify/Smart Card Assistant.app/Contents/MacOS/SCTool
designated => identifier "com.centrify.cdc.smartcardassistant" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate
leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "64CT837G5Z"
Configuring Full Disk Access for Apple Remote Desktop
If your organization uses Apple Remote Desktop to run any DirectControl Agent for Mac commands (such as adjoin, adleave, and so forth), you need to also
set Full Disk Access for Apple Remote Desktop. You can do this either as an administrator user or through your MDM service, following the same procedures
as mentioned earlier.
If you're configuring full disk access as an administrator, the application path to add is as follows:
/System/Library/CoreServices/RemoteManagement/ARDAgent.app
If you're configuring full disk access through your MDM provider, here's the information that your provider needs:
% codesign -dv /System/Library/CoreServices/RemoteManagement/ARDAgent.app

Executable=/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Identifier=com.apple.RemoteDesktopAgent
...
% codesign -dr - /System/Library/CoreServices/RemoteManagement/ARDAgent.app
Executable=/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
designated => identifier "com.apple.RemoteDesktopAgent" and anchor apple
Logging onto the Mac After Joining a Domain
When using Auto Zone, all Active Directory users in the domain become valid users on a joined computer. To verify that the software is working properly, you
can simply log into the Mac computer by using an Active Directory account.
On the Mac login screen, select Other and enter an Active Directory user name and password:
Upgrading The DirectControl Agent for Mac
In most cases, you can update agents on Mac computers by simply installing the new agent either directly or remotely on top of an existing agent. As a best
practice, you should perform in-place upgrades using a local Mac administrative (admin) account or any other user account that has local administrative
rights and reboot the computer after completing the upgrade. In most cases, you should not perform the upgrade while you are logged on as an Active
Directory user in a currently active session.
In rare cases, you might be advised to run adflush to clear the Active Directory cache before performing an in-place upgrade. For example, if you are updating
agents from version 4.x, or earlier, to 5.1.x, run adflush first to ensure a smooth upgrade. It is highly unusual for an upgrade to require you to leave and rejoin a
managed Mac computer to the domain.
Creating Home Directories
This section explains how to create different types of home directories for a Mac computer.
Understanding Home Directories
Whenever an Active Directory user logs in to a Mac computer, a home directory is created for the user. Mac provides three styles of home directory, which
can be configured by an administrator to fit the type of user who will be using the computer, the type of computer, and the use to which the computer will be
put. Auto Zone supports each of these styles:
Local home directory — The user’s home directory is created on the local computer in the Users folder with the user’s login name (/Users/username).
Network shared directory — The user’s home directory is created on a network share.
Portable home directory — The user’s home directory is created on a network share and copied and synchronized to the local computer. This type of
directory is also called a mobile home directory.
When you join a computer to a domain by connecting to Auto Zone, the home directory is created based on the following:
Active Directory user settings; for example, an administrator can specify a network home directory in the Profile for an Active Directory user.
Auto Zone default values; by default, Auto Zone is configured to support the creation of home directories in the Users folder on the local computer.
Auto Zone parameters set in the configuration file, /etc/centrifydc/centrifydc.conf by an administrator or by a group policy. See the Configuration and Tuning
Reference Guide for a description of all Auto Zone parameters.
The following sections explain in detail how to set up each type of user home directory.
Configuring a Local Home Directory
In general, you do not need to explicitly configure local home directories for your Active Directory users because Auto Zone is configured to work for Active
Directory users exactly as if they were local users. That is, by default, an Active Directory user who logs in to a Mac computer that is joined to a domain
through Auto Zone is given a local home directory at /Users/username. For example, for a user, Glen Morris, whose login name is gmorris, the local home directory
is set to: /Users/gmorris.
Although it isn’t necessary to explicitly configure the agent for local home directories, in some situations you might want to do so. For example, if a Windows
user has a local home directories defined in their Active Directory profile, that home directory will be assigned when the user attempts to log in and may
prevent the user from logging in. The agent provides a configuration parameter (auto.schema.use.adhomedir)that you can set to ignore home directories in an
Active Directory profile and always set the home directory to the default (/Users/username).
To explicitly configure a computer for local home directories:
1. On the Mac computer, edit the configuration file, /etc/centrifydc/centrifydc.conf.
2. Add the following two parameters:
auto.schema.use.adhomedir: false
auto.schema.homedir: /Users/%{user}
Setting auto.schema.use.adhomedir to false configures the local computer to ignore any home directories that are set for users in Active Directory. This
parameter is set to true by default.
Setting auto.schema.homedir: /Users/%{user} configures the local computer to set the home directory to /Users/username, where username is the user
logon name defined in the user’s Active Directory account. Note that this parameter is set to this value by default on all Mac computers.
Note: If you plan to configure network-home or portable-home directories for this computer, you must set auto.schema.use.adhomedir to
true, the default value, otherwise, the agent will ignore the network home directories that you specify for users in Active Directory.
Configuring a Network Home Directory
For each user whom you want to have a network home directory, you must specify the location in Active Directory.
Note: In earlier releases you had to first create a network home directory for a user if you planned to also create a portable home (mobile home)
directory for that user. With the current release, you can create portable home directories for users without first creating network home
directories for those users.
To configuring a network home directory for a user connected to Auto Zone:
1. Create a network share to host the home directory.
For example, on the dc-demo server (acme.com domain), create a network share called MacUsers.
You must assign appropriate permissions to the network shared directory so the Active Directory account is able to write to the user’s home directory.
One way to do this is to assign read/write permissions to Authenticated Users on the network share. Each home directory that is created inherits
permission from the network share so the account of the logged-in user is granted write permission its network home directory. See Setting Shared
Directory Permissions for more details about properly setting and fine-tuning network share permissions.
2. On a domain controller in the forest to which the Mac OS computer is joined, open Active Directory Users and Computers.
3. Select Users, select the user, then right-click the user and click Properties.
4. Click the Profile tab, then under Home folder select Connect.
5. In Connect...To type the location of the share you created in Step 1 by using the following format:
//*Server/share/path
For example:
//dc-demo.acme.com/MacUsers/rdavis
6. Click O K to save the user profile.
7. (Optionally) By default, the agent is configured to use the Active Directory home folder if one is specified in a user’s profile. However, to be explicit, you
can edit the configuration file and add the following parameter:
auto.schema.use.adhomedir: true
Save and close the file.
8. Specify the type of share to mount for the network home directory on the Mac computer, SMB, or AFP.
By default, the Mac computer will attempt to mount an SMB share for the network home. If you specified an AFP share, you must set the following
parameter in the configuration file:
auto.schema.remote.file.service:AFP
Or enable the Computer Configuration > Policies > Centrify Settings > DirectControl Settings > Adclient Settings > Auto Zone
remote file service group policy to specify SMB (the default) or AFP for all Mac computers.
9. Optionally, if you want the network home directory to be mounted automatically on the user’s computer, enable the following group policy: User
Configuration > Policies > Centrify Settings > Mac OS X Settings > Automount Settings > Automount user’s Windows home.
When the specified user next logs onto the Mac computer, the home directory will be created on the specified share. On the Mac computer, you should see
the server and share under SHARED in the Finder.
Configuring a Portable Home Directory
You can create a portable home directory for a user and synchronize that directory with the share defined in the user’s Centrify Profile. You can synchronize
to /SMB/, /AFP/, or /Network/Servers (NFS) shares.
Advantages of a Portable Home Directory
If a user does not have a portable home directory and the computer becomes disconnected from the domain controller (and therefore disconnected
from Active Directory), the user can log in with Active Directory credentials only if the user’s information exists in the Centrify cache. If there is any
issue with the Centrify cache (for example, if the adflush --force command was issued to flush the cache immediately before the computer was
disconnected from the domain), Active Directory users cannot log in unless they have portable home directories.
Active Directory users without portable home directories are required to log in at least once in connected mode to populate their account information in
the Centrify cache. If the computer is not connected to the domain controller, the Centrify cache is not updated with the initial set of Active Directory
user data, and Active Directory users cannot log in. You use group policies to configure synchronization. These group policies perform the same
function as the Mobility preferences that you can manage through Workgroup Manager.
The following sections describe the process of specifying the options for creating mobile accounts, and for specifying the options for synchronizing mobile
accounts with the network home directory.
Before you begin you should have the following in place:
A Group Policy Object that applies to a domain or OU that includes Mac users.
A good understanding of the synchronization rules that you want to apply. The procedures in the following sections explain the group policies and
options that you can enable, but you should consult the Mac OS X Server documentation for strategies about which options to apply.
Working with Macs
This section describes the unique characteristics or known limitations that are specific to using Delinea Management Services on a Mac computer.
Specifying the Macintosh User’s Home Directory Location
If you configure NFS, SMB, or AFP network file sharing for your Mac OS X computers, you can automatically mount and log on to file shares using Active
Directory credentials.
To enable Mac OS X users to log on to file shares when the network is configured with NFS, SMB, or AFP network sharing:
1. Open Active Directory Users and Computers or the Access Manager console.
2. Select the user account for which you want to enable automounting, right-click, then click Properties.
3. Click the Delinea Profile tab and set the Home directory path to use one of the following formats:
/Users/user_login_name to set the user’s home directory to the default home directory location for all user home directories on Mac OS X computers.
/SMB/server_name/share[/path] to automount a file share on the SMB server_name you specify. Be certain to use the fully-qualified domain name for
server_name, or the IP address. The short name does not work. For example:
/SMB/myHost.acme.com/Users/isuzuki
/SMB/unix_username/server_name/share[/path] to automount a file share when you are using Fast User Switching on the SMB server_name you specify. Be
certain to use the fully-qualified domain name for server_name, or the IP address. The short name does not work. For example:
/SMB/isuzuki/myHost.acme.com/Users/isuzuki
/AFP/server_name/share[/path] to automount a file share on the Apple server_name you specify.
/AFP/unix_username/server_name/share[/path] to automount a file share when you are using Fast User Switching on the Apple server_name you specify.
In specifying the remote SMB or AFP file share, you must use the uppercase letters SMB or AFP at the beginning of the path. If you use lowercase
letters (smb or afp), automounting fails.
Note: If you plan to use Fast User Switching to switch between Active Directory users on the same computer, you should use the
/SMB/unix_username/server_name/share[/path] or /AFP/unix_username/server_name/share[/path] format to specify the user’s home directory to prevent
conflicts between users logging on using the same share. If you want to automount a share on an Apple file server using the Apple File
Protocol (AFP), however, you must use Delinea 3.0.1 or later.
4. In Step 3, if you specified a network directory, make sure the Active Directory user logon name (pre-Windows 2000), also known as the
samAccountName, matches the Mac login name (UNIX name). Otherwise, the login is not guaranteed to work on all Mac systems. The name must be
eight characters or fewer because the UNIX name is automatically truncated to eight characters and won’t match if the Active Directory name is longer.
The Active Directory name is defined on the Accounts tab. To see an example, open the Properties page for a user and select Account.
Then select the Delinea Profile tab to see the UNIX name.
5. For the shared directory you specified in Step 3 (for example, Users), set ‘full’ permissions for authenticated users. See the section, Setting Shared
Directory Permissions, for details on how to do this.
6. Verify that the computer on which the shared directory resides is configured on the DNS server with forward and reverse lookup zones by running the
following commands in a terminal window:
nslookup computerName.domainName
for example:
nslookup QA1.acme.com
Server: acme.com
Address: 192.168.1.139
Name: QA1.acme.com
Address: 192.168.1.139
nslookup ipAddress
for example:
nslookup 192.168.1.139
Server: acme.com
Address: 192.168.1.139
Name: QA1.acme.com
Address: 192.168.1.139
If you get an error message such as this:
Can’t find server name for address 192.168.1.139
it means a reverse lookup zone is not configured for the specified server. To configure DNS forward and reverse lookup zones, see the Microsoft
Support Article 816518.
Populating the Home Directory on a Network Share
If you configure users to automount a network share when they log on, you must determine whether a home directory already exists on the network share for
those users. If the individual user’s home directory does not exist on the network share, Access Manager creates the home directory automatically the first
time the user logs on.
Note: For NFS shares, Access Manager cannot create the home directory on the network share, so you must create the directory before users log
in for the first time.
For example, assume you have defined the home directory in a user’s Delinea Profile as: /SMB/demo-dc.acme.com/home/thomas, indicating that there is an SMB
share on the server demo-dc and a shared folder named home where the user thomas has permission to list and create folders.
Note: For the server name, be certain to use the fully-qualified domain name, such as demo-dc.acme.com, and not the short version demo-dc.
When the zone user thomas logs on for the first time, Access Manager creates the new home directory thomas and populates it with the standard Mac OS X files
and folders.
If the home directory specified in the Delinea Profile for a zone user exists prior to the user’s first logon, Access Manager assumes that the directory is valid
and contains the appropriate files, and it does not populate the directory with additional Mac-specific folders.
Defining a Home Directory in the Active Directory Profile
When you are configuring a network home directory for remote Mac users, the home directory is created automatically when users first log; it should not exist
prior to that initial log on unless you want to prevent Access Manager from creating the home directory. Therefore, you should not define a home directory
connection point in the Profile properties for new Active Directory users or new mobile user accounts. Instead, you should allow Access Manager to create
and populate the remote home directory. However if you need to synchronize a network home directory from a local home directory as part of your migration
process, the network home directory must exist prior to migration. If you are synchronizing from a local home directory to a remote share, you can create the
remote home directory manually, or click the Profile tab and set the connection path.
Setting Shared Directory Permissions
All users who are set up with a network home or portable home directory must have proper permissions to the shared directory in which the home directories
are created. Initially, you can provide access to the shared directory through the Windows built-in security group, Authenticated Users. Later, you can fine
tune permissions for this group based on your company’s file-sharing needs. For example, if an administrator pre-creates home directories for each user
before they log in, users only need Read access to the shared directory to access their home directories.
To set permissions for the shared directory for network home and portable home directories:
1. On the network share computer, select the directory to share (for example, MacUsers). Right-click, click Properties and click the Sharing tab; then
click Advanced Sharing; for example:
2. Make sure Share this folder is selected. Click Permissions, then click A d d:
3. Type auth and click O K to return the Authenticated Users group. Select Authenticated Users, then click Allow for Full Control. Click O K to set
permissions for authenticated users, then click O K again to close the properties page.
4. Verify that Authenticated Users have proper permissions on the Security tab as well as on Share Permissions. Ordinarily, these permissions are
applied automatically because the Active Directory Users group, which includes authenticated users, inherits Full Control to the shared folder, but if
permissions were altered on the Security tab and they are insufficient, users may be unable to log in.
Click the Security tab and select Authenticated Users (or if it is not already in the Group or user names box, click A d d to add it).
5. Select Full control and click O K to save and close the Properties page.
Assigning permissions to Authenticated Users on the network home share directory means that each home folder will inherit permissions that enable
logged-in users to access their home directories. It also means that every user will have access to every other user’s home directory. To change this
access, you can set permissions on the individual home directories. For information about fining tuning permissions for individual users, see the next
section, Limiting Users Access to Other Users’ Home Folders.
Limiting Users Access to Other Users’ Home Folders
The previous section explained how to assign permissions to a network-home shared folder, which are consequently inherited by the home folders created in
the shared folder. Because permissions are inherited, each user has equal access to every other user’s home folder. This section explains how to fine tune
permissions to limit user’s access to their own home folder.
To limit users access to their own home folder:
1. Select the network share you assigned permissions to in the previous section.
2. Select one of the user home directories in the network share.
3. Click the Security tab.
4. Click Advanced and Change Permissions.
5. Deselect Include inheritable permissions from the object’s parent.
6. Click Remove when prompted.
7. Click A d d.
8. Type users and click Return.
9. Select the following permissions for Users:
Traverse folder / execute file
Read Attributes
Read Extended Attributes
Create files / Write Data
Create Folder / Append Data
10. Click O K, and O K again until you have saved all open dialogs and closed the Properties page.
Enabling Users to Manage Their Print Queues
On Mac computers, Delinea Active Directory users are unable to manage their own print jobs. For example, if they attempt to pause, stop, or resume one of
their own print jobs, they are prompted to supply the name and password of a user in the “Print Operator” group, otherwise, they cannot continue. Delinea
supplies the group policy, Map zone groups to local group, that you can use to enable all Mac users authenticated through Active Directory to manage their
printers.
This policy gives members of a specified zone group (an AD group, or AD group that has been added to a Delinea zone) the privileges that belong to members
of a local group on the local group. For example, as explained in the following procedure, mapping an AD group to the local _lpoperator and _lpadmin groups,
provides members of the AD group with the privileges to manage print jobs on the local Mac computer when they log in.
To map a zone group to local _lpoperator and _lpadmin groups:
For purposes of illustration, this procedure asks you to create a MacPrint group and then add specific users to the group to provide them with printing
privileges on Mac computers. You could also map an existing AD group to the local _lpoperator and _lpadmin groups, or create a new group with a different name.
1. On a Windows computer, open Active Directory Users and Computers

2. Select Users, right-click and select New > Group.
3. Enter a name for the group, such as MacPrint and select Global and Security.
4. Double-click the group and select the Members tab
5. Click A d d and select the AD users who you want to provide with printing privileges on Mac computers.
6. Open the Access Manager Console
7. Expand the zone hierarchy as well as the zone containing Mac computers.
8. Expand UNIX Data, select Groups, then right-click and select Create UNIX Group.
9. Find and select the AD group you created (MacPrint) and click O K to add it to the zone.
10. Open the Group Policy Management Editor and select the GPO that you use for Mac OS X computers.
11. Click Computer Configuration > Policies > User Configuration > Policies > Delinea Settings > Mac OS X Settings > Accounts.
12. Double-click Map zone groups to local group.
13. Click the Policy tab and click Enabled.
14. Click A d d and do the following:
1. In Local Group, type _lpoperator to add the printer operators group.
2. In Zone Group click Browse.
3. Find and select the AD zone group you created (MacPrint), then click O K to map MacPrint to the printer operators group.
4. Click A d d again and in Local Group type _lpadmin to add the printer admin group.
5. In Zone Group, click Browse then find and select MacPrint again to map MacPrint to the printer admin group.
15. Click O K to save the policy.
The first time users attempts to manage their printer, for example by pausing the printer, they will be prompted for credentials for a user in the “Printer
Operator” group. They can simply enter their own name and password. Subsequently, they can manage the printer without supplying credentials.
Setting Up Authenticated Printing
In a Windows Active Directory environment that requires authentication for printing services, Mac users who are already authenticated must provide
credentials again when using a Windows network printer. To provide single-sign on when using printers, the Delinea DirectControl Agent for Mac includes an
authenticated printer plug-in that enables users to send print jobs to printers on the Windows network without requiring them to enter credentials again. This
plug-in uses the user identifier (UID) of the user printing a job to find the user account to authenticate, then validates the user’s Kerberos credentials through
Active Directory. If the user’s credentials are not available, the print job will fail.
Understanding Printing on Mac OS X
Mac uses the Common UNIX Printing System (CUPS) to manage printing services. Although you can access the CUPS facility directly to manage printers, in
general you do not need to do so. Printers are managed through the Print and Scan system preference, which uses the CUPS facility. For example, when you
add a printer through Print and Scan, the CUPS facility does the following:
Creates a Postscript Printer Description (PPD) file that defines the printer. The file is given the name of the printer and resides in the /etc/cups/ppd directory;
for example, /etc/cups/ppd/laserjet2.ppd.
Modifies the CUPS configuration file, /etc/cups/printers.conf, with information about the new printer.
One method to set up authenticated printing for all Mac computers in your environment is to configure an authenticated printer on one (template) computer,
then export the files that CUPS creates to define this printer (printerName.ppd and printers.conf) to each of your Mac computers. You can use group policy to
export these files to all your Mac computers.
You can also configure printing directly with CUPS commands.
To set up authenticated printing for multiple printers using the Delinea plug-in, first identify the printer to configure, including the server that hosts it; for
example, HPLaserJet2.@dc01.
1. On the Mac computer that you will use to define an authenticated printer template, open System Preferences > Print & Scan (Print & Fax on
older systems), then click the plus sign (+) and select Add Other Printer or Scanner.
2. Double-click the Advanced icon in the toolbar.
Note: If the Advanced option is not showing, press and hold the Option and Apple keys and right-click in the open area in the toolbar next
to the Windows icon and select Customize Toolbar. Drag the Advanced icon to the toolbar and click Done. Then double-click it.
3. Scroll in the Type drop-down list and select Windows Printer via Delinea from the list.
Note that after you make this selection, the URI scheme in the Device URI window changes to cdcsmb://, which specifies the Delinea plugin.
4. Type the complete URI specification for the printer in the form:
scheme://servername/sharename
for example:
cdcsmb://printserver.acme.com/hplaserjet2
Note: A URI specification does not accept spaces. If the printer share name contains spaces, you must replace them with %20 (ASCII code
for space); for example, to specify the HP Color LaserJet 4 printer:
cdcsmb://printserver.acme.com/HP%20Color%20LaserJet%204
5. Type a name for the printer; for example HPLaserJetMac.
When you type the URI for the printer, the first part of the name automatically appears in the Name field. You can change that name now. This is the
name that will appear in the list of printers in the Print and Scan system preference and in the list of available printers when a user prints a document. It
is also the name of the PPD (Postscript Printer Description) file that the CUPS facility creates for each printer that is added to your Printer preferences.
Type an optional description in Location to assist users in locating the printer.
6. In the Print Using window, specify the type of the printer, which enables you to properly manage the printer.
For example, if you have drivers installed for the printer, click Select Printer Software and select the appropriate item such as HP Laserjet 4300,
then click O K.
You can also specify Generic Postscript Printer, or click Other to browse for drivers or printer software.
Click the A d d button to add the printer to the list of available printers.
7. Repeat this procedure for as many printers as you want to make available for authenticated printing.
You can now use the Copy Files group policy to copy the new printerName.ppd file and updated CUPS configuration file (printers.conf) to the appropriate
locations on each of your Mac computers in the domain.
To copy printer files to other computers:
1. In the Finder on the Mac template computer, navigate to the /etc/cups directory by clicking Go > Go to Folder, then type /etc/cups and click G o.
2. Select printers.conf and copy it to the desktop. When prompted, enter your administrator password to copy the file.
3. Open the ppd folder (/etc/cups/ppd). Select the files for all the authenticated printers you defined in the previous procedure and copy them to the desktop.
4. On the desktop, change the file permissions for the printers.conf and *.ppd files so you can copy them to sysvol:
1. Select the files and click File > Get Info.

2. For each open dialog box, expand Sharing & Permissions, then click the lock icon and provide administrator credentials for making changes.
Set the permissions for everyone to Read only.
3. Reset the lock and close all the open dialogs.
5. On the Windows domain controller create a sub-directory for the printer file in SYSVOL.
SYSVOL is a well-known shared directory on the domain controller that stores server copies of public files that must be shared throughout the domain.
You can use it to copy the printer definition and configuration files to all Mac computers that join the domain.
SYSVOL is located at:
C:WindowsSYSVOLsysvoldomainName
For example, assuming the domain is acme.com, and using the name MacPrinters for the directory, create the following directory:
C:WindowsSYSVOLsysvolacme.comMacPrinters
6. On the Mac computer, copy the files from the desktop to SYSVOL on the Windows domain controller. If you are connected to the domain, you should see
the domain controller in the Finder. If the domain controller is not visible in the Finder, connect to it:
1. Click Go > Connect to Server and select the domain controller.
2. When prompted select SYSVOL; for example:
3. Navigate to the MacPrinters directory you created, for example by clicking acme.com then MacPrinters.
4. Drag the printer files to MacPrinters.
7. Configure the Copy Files group policy.
1. On the Windows domain controller, open the Group Policy Management Editor and select the GPO that is used to manage Mac computers.
2. Navigate to Computer Configuration > Policies > Common UNIX Settings and double-click Copy Files.
3. In Copy file policy setting, select Enabled.
4. Click A d d, then Browse. Double-click to open the directory you created for the printer files in Step 5 (for example, MacPrinters).
5. Select the printers.conf file. Filename now shows MacPrinters/printers.conf.
6. In Destination, type /etc/cups. This group policy will copy printers.conf to the /etc/cups directory of each computer that joins the domain.
7. Select Use destination file ownership and permissions. The file will be assigned the default ownership and permissions:
owner: root (0)
group: lp (26)
permission 0600 (rw- --- ---)
8. Select O K to add the printers.conf file.
8. Click A d d again and browse to MacPrinters to add the PPD files.
1. Select one of the PPD files you copied to the MacPrinters directory.
2. In Destination, type /etc/cups/ppd.
3. Select Use destination file ownership and permissions. The file will be assigned the default ownership and permissions:
owner: root (0)
group: lp (26)
permission 0644 (rw- r-- r--)
4. Click O K to add the file.
9. Repeat the sub-steps in Step 8 for each of the PPD files that you have defined, then click O K to enable the policy.
This group policy will copy each printerName.ppd file to the /etc/cups/ppd directory of every computer to which the policy applies and that is joined to the
domain.
10. Run the adgpupdate command on each target Mac computer to trigger an update of group policies and execute the new Copy Files policy.
By default, group policies are updated automatically every 90 minutes, so you can skip this step and wait for the automatic update if you wish. You
should also log out and back in again on each computer to update the printer configuration dialogs.
Removing a Printer Definition from Client Computers
This section explains how to remove printer definitions that you created for Mac computers in the domain. It assumes that you set up the Copy Files group
policy to add printer definitions to each of your joined Mac computers, as explained in Setting up Authenticated Printing.
To remove a printer definition from computers in a domain:
1. Identify the name of the PPD file to delete in /etc/cups/ppd; for example, laserjet4300.ppd.
2. On the Mac template computer (the computer on which you originally defined the authenticated printer), open System Preferences > Print &
Scan. Select the printer to delete, click the minus (-) button, then click Delete Printer.
Deleting the printer removes the printer from the list, updates the /etc/cups/printers.conf file by removing the definition of the deleted printer, and removes
the printerName.ppd file from the /etc/cups/ppd directory.
3. Copy the updated printers.conf file to the desktop and change the permissions to everyone: Read only.
4. Copy the updated printers.conf file to the SYSVOL and replace the existing file; also remove the PPD file for the deleted printer.
SYSVOL is a well-known shared directory on the domain controller that stores server copies of public files that must be shared throughout the domain.
When authenticated printing was set up, the CUPS configuration file, printers.conf was placed in the SYSVOL/acme.com/MacPrinters folder.
SYSVOL is located at:
C:WindowsSYSVOLsysvoldomainName
If you are connected to the domain, you should see the domain controller in the Finder. If the domain controller is not visible in the Finder, connect to it:
2. When prompted, select SYSVOL; for example:
3. Navigate to the directory you created (domainName/subdirectory), for example by clicking acme.com then MacPrinters.
4. Drag the printer configuration file to this directory.
5. Remove the PPD file for the deleted printer.
5. Remove the deleted printerName.ppd file from the Copy Files policy.
1. On the Windows domain controller, open the group policy editor and select the policy to edit, such as Default Domain Policy.
2. Navigate to Computer Configuration > Policies > Common UNIX Settings and double-click Copy Files.
3. Select the file to delete and click Remove.
4. Click O K to save the updated policy.
6. Configure the Specify commands to run group policy to remove the deleted printerName.ppd file from all the Mac computers in the domain.
1. In the same folder of the group policy editor (Common UNIX Settings), open the Specify commands to run policy and select Enabled.
2. Click A d d.
3. In Run command, enter a command similar to the following to remove the printerName.ppd file from the /etc/cups/ppd directory on each
computer:
rm /etc/cups/ppd/*printerName*.ppd; for example:
rm /etc/cups/ppd/laserjet4300.ppd
The next time group policy is updated on computers in the domain (every 90 minutes by default), the following occurs:
The Copy Files group policy copies the updated printers.conf file to each computer.
The Specify commands to run group policy removes the specified PPD file on each computer.
Setting Up Local and Remote Administrative Privileges
Delinea provides two group policies to set administrative privileges on the local computer
Map zone groups to local admin groups allows you to specify one or more zone groups to map to the local admin group. Members of the specified group
are given administrative privileges on Mac computers managed by Access Manager.
Enable administrator access groups allows users in the zone group ard_admin to access a computer via Apple Remote Desktop with full privileges.
This section shows you how to use these policies together to enable local and remote administrative access to Mac computers.
To enable remote and local access for a group:
1. Create an Active Directory group, for example, My_Mac_Admins, and add users who you want to have administrative privileges.
2. Create an Active Directory group that is a Domain Local Security group. For convenience, name it ard_admin.
3. Add My_Mac_Admins as a member of ard_admin.
4. Create a Delinea zone group, My_Mac_Admins and map it to the Active Directory group My_Mac_Admins.
Note: If the local computer is connected to the domain through Auto Zone, you cannot create a zone group because there are no zones.
However, all Active Directory groups are valid for the joined computer, so you can map any group, such as My_Mac_Admins, to the local
admin group, but you need to know the group’s UNIX name, which you can retrieve on the local computer, by using the adquery command, as
follows
[root]#adquery group -n
For example, the following shows an adquery command and the name it returns:
[root]#adquery group -n |grep -i Mac_Admins my_mac_admins
5. Create a zone group, ard_admin, and map it to the Active Directory group ard_admin.
Note: This zone group must be named ard_admin.
6. In the Group Policy Editor, edit the group policy for the domain, then click Computer Configuration > Policies > Centrify Settings > Mac OS X
Settings > Accounts > Map zone groups to local admin group.
7. Open the policy, select Enable, then click A d d. Enter My_Mac_Admins (or the name retrieved from the adquery -n command in Step 4), then click O K.
This step maps My_Mac_Admins to the admin group on the local computer and gives members of My_Mac_Admins all privileges.
8. Click Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Remote Management > Enable administrator
access groups.
9. Open the policy and select Enable.
This step allows members of ard_admin to access a computer via Apple Remote Desktop with full privileges. In Step 7, you effectively gave members of
My_Mac_Admins administrative privileges. Since My_Mac_Admins includes members of ard_admin, members of ard_admin now have full local and
remote administrative access.
Querying User Information for Active Directory Users
When you run commands or use applications that look up user information in the directory, the local Mac directory service is always consulted first before the
look-up request is made to Active Directory. If a local user exists with the same name as a UNIX profile name that has been defined for the zone, a lookup
request such as id username will return the UID and GID associated with the local user account from the local directory service rather than the information
associated with the UNIX profile defined in Active Directory.
For example, if you have a UNIX profile in Active Directory for the user mia with the UID of 10024 and the user’s primary group is mia with the GID of 10024 and the
user is also a member of the Active Directory group users and GID of 10001, running the id mia command returns the following information from Active Directory:
uid=10024(mia) gid=10024(mia) groups=10024(mia), 10001(users)
However, if there is also a local user account with the same user name of mia, but with a UID of 502 and a primary group named mia with a GID of 502, running id
mia returns the information for the local user retrieved from the Mac directory service, then any additional group membership information retrieved from
Active Directory. For example:
id mia
uid=502(mia) gid=502(mia) groups=502(mai), 10001(users)
Because the Mac directory service is queried first, the information for the local user mia takes precedence over the information defined in Active Directory.
To avoid retrieving the information for a local user instead of the UNIX profile defined in Active Directory, you should make sure that the UNIX profile user
names in Active Directory are different from the local user or disable local user accounts.
Migrating from Open Directory to Active Directory
If you install the Delinea DirectControl Agent for Mac in an environment where existing Mac users and computers are managed with Open Directory, you may
need to migrate the account information and home directories for those users from the Open Directory environment to Delinea Active Directory. Open
Directory and Active Directory support three types of users:
Local users
Network home users
Portable home, or mobile home, users
For example, you may need to migrate existing mobile user accounts from Open Directory to Active Directory or migrate local home directories to a network
share.
To migrate users with existing mobile accounts from Open Directory to Active Directory:
1. Create a copy of the user’s local home directory in a temporary location if you have enough disk space to do so. This copy can serve as a backup to
restore the user’s home directory if you run into any synchronization problems.
2. Log on to the Mac client as an administrator.
3. Disable the LDAP service.
Open the Directory Utility and select the Services tab; then deselect LDAPv3 and click Apply.
4. Open a Terminal window and run the following Directory Service command to delete the user’s record:
dscl /Local/Default -delete /Users/userName
where userName is a local user; for example, to delete the record for cain:
dscl /Local/Default -delete /Users/cain
5. Navigate to the /Users/user_name/Library/Mirrors directory and delete this folder.
6. Join the Mac computer to an Active Directory domain and restart the computer to shut down and restart services.
7. Create an Active Directory user account for the Open Directory user account, if one does not already exist.
If you are creating a new Active Directory user, use Active Directory Users and Computers to add the user account.
8. Add the Active Directory user to the Mac computer’s zone and define the Delinea Profile for the user:
Use the same user name, UID, and GID as the Open Directory user account. You can change this information later with the adfixid program, but for
migration you must use the same values.
Set the home directory for the user to the appropriate network share using the /SMB/share/path or /AFP/share/path syntax. For example,
/SMB/cain/server2003.myDomain.com/Users/cain.
Note: For synchronizing new mobile user accounts, the empty home directory must exist on the network share. If the user home
directories are on the same network share as you previously used with Open Directory, logging on with the new Active Directory
account should not affect the files available on the share.
Because GID values of 0 to 99 are usually reserved for system accounts, you may see a warning message when you save the user’s profile if the
user’s primary GID value is less than 99.
If you have Open Directory users that do not have mobile accounts or portable home directories and you want to synchronize their local home directories with
their network home, you should first use the Workgroup Manager to create mobile accounts for those users to establish a portable home directory. You can
then follow the steps above to synchronize the portable home directories with their network home directory. If you don’t want to synchronize the local home
directory with the home directory on the network share, you can simply create Active Directory accounts for the Open Directory users and remove the local
user records; see Mapping Local User Accounts to Active Directory for information about removing local user records.
Changing the Delinea UIDs and GIDs
To change the UID and GID values in Delinea Active Directory to match the existing values:
1. Log in to the Mac computer as a local administrator.
2. Open a terminal session.
3. Open the user’s home folder and type:
ls -ln total 32
-rw-r--r--@ 1 505 505 3 Mar 26 2007 .CFUserTextEncoding
-rw-r--r--@ 1 505 505 6148 Mar 26 2007 .DS_Store
-rw------- 1 505 505 74 Mar 26 2007 .bash_history
drwx------@ 3 505 505 102 Mar 26 2007 Desktop
drwx------@ 3 505 505 102 Mar 26 2007 Documents
drwx------@ 19 505 505 646 Mar 26 2007 Library
drwx------@ 3 505 505 102 Mar 26 2007 Movies
drwx------@ 3 505 505 102 Mar 26 2007 Music
drwx------@ 4 505 505 136 Mar 26 2007 Pictures
drwxr-xr-x@ 4 505 505 136 Mar 26 2007 Public
drwxr-xr-x@ 5 505 505 170 Mar 26 2007 Sites
The third column shows the UID (505 in this example) and the fourth column shows the GID (also 505).
4. On the Windows workstation, open the Access Manager console. Expand the zone, expand users, and double-click the user to open the property page.
5. Type 505 for the UID.
6. To change the GID, you need to either change the GID of the group to which the user belongs (which will change for all users who belong to that group) or
create a new group. To create a new group:
Open ADUC. Then right-click Users > New > Group. Enter a name for the group and click O K.
In the Access Manager console, right click Groups > Create UNIX Group. Search for the group you created. Change the GID to the desired
value (for example, 505) and click O K.
7. To change the GID of the existing group to which the user belongs, expand Groups and double-click the group name. Change the GID to the desired
value (for example, 505). Click Yes on the warning message.
Modifying the Mac UID and GID to Match AD
To change the existing UID and GID to match the values in Active Directory depends on whether you have a local home directory, a network home directory, or
a mobile home directory.
To change the existing UID and GID if you have a local home or network home directory:
2. Open Applications > Directory Utility > Services. Double-click Active Directory, then click Unbind. Enter your administrator name and
password if necessary.
3. Use the ADJoin tool (either the GUI or the command-line version) to connect to an Active Directory domain.
4. Open a terminal session and type the following:
id userName
Note the primary group. For example:
id cain
...
gid=10000(support)
5. Type:
chown -R userName:primaryGroupName /Users/userName
For example, for a local home directory:
chown -R cain:support /Users/cain
For example, for a network home directory:
chown -R cain:support /SMB/Users/cain
To change the existing UID and GID if you have a mobile home directory:
1. Be certain the local home directory is synchronized with the network home directory.
3. Open Applications > Directory Utility > Services. Double-click Active Directory, then click Unbind. Enter your administrator name and
password if necessary.
4. Use the ADJoin tool (either the GUI or the command-line version) to connect to an Active Directory domain.
5. Open a terminal session and type the following Directory Service command to delete the cached local user:
dscl . -delete /Users/userName
For example:
dscl . -delete /Users/cain
6. Then type the following commands to remove the home directory so that it syncs again from the network and remove the local copy of mcx so you are
prompted to create a mobile account:
rm -rf /Users/userName
rm -rf /Library/Managed Preferences/userName
7. On the Windows Active Directory computer, set the User Configuration > Policies > Centrify Settings > Macintosh Settings > Mobility
Synchronization Settings group policies.
Note: Mobile home directory synchronization is no longer supported since macOS 10.12.
Converting a Local User to an Active Directory User
Although local user accounts can co-exist with Active Directory user accounts, in some cases, you may want to convert some or all of your local accounts to
Active Directory user accounts. Converting local users to Active Directory users simplifies account management, but requires you to take some steps
manually.
On Mac computers, the local account database is always checked for authentication before Active Directory. If a local user has the same username as an
Active Directory user, the local user account is used for authentication. If the local user’s password is different from the Active Directory user’s password
whether logging on using the Mac login window, or remotely (for example, using telnet or ssh), the local user password is required for authentication to
succeed. Although authentication succeeds, Access Manager will generate a username conflict warning.
In most cases, you should remove or convert local user accounts to avoid conflicts between Active Directory and local user accounts and to ensure Active
Directory password and configuration policies are enforced. If you need to keep local user accounts, you should ensure the logins are distinguishable from
Active Directory accounts. For more information, see the Planning and Deployment Guide.
To convert a local Mac user to an Active Directory user:
1. Open a Terminal window and run the following Directory Service command to delete the user’s record:
dscl /Local/Default -delete /Users/userName
where userName is a local user; for example, to delete the record for cain:
dscl /Local/Default -delete /Users/cain
Although the user record is deleted, the home directory for the user (/Users/cain), including all sub-directories and files, still exists. When you create an
Active Directory user with the same name, this user will have access to everything in the existing local home directory.
2. On a Windows computer, use Active Directory Users and Computers to create an Active Directory user account for the local user account (for example,
cain), if one does not already exist.
3. In the Access Manager console add the Active Directory user to the appropriate zone and define the Delinea Profile for the user. Set the home directory
for the user:
Note: The default home directory for Mac users is the /Users directory, unlike most UNIX systems where /home is the default by convention.
To a local home directory: /Users/userName; for example, /Users/cain.

To an appropriate network share using the /SMB/share/path or /AFP/share/path syntax. For example, /SMB/cain/server2003.myDomain.com/Users/cain. See
Configuring a network home directory.
To a network home directory. If you wish to create a mobile account for the user and synchronize the user’s folders the next time the user logs on,
see Configuring a Portable Home Directory.
4. Reboot the Mac computer, then log in as the new Active Directory user.
Migrating a User from Apple’s Active Directory Plugin to Delinea Active Directory
When you create an Active Directory user by using the Mac Directory Utility Active Directory plug-in it creates numeric user (UID) and group (GID) identifiers.
When you migrate a current Active Directory user to Delinea Management Services for Mac, the Access Manager console creates a UID and GID that are
different than the current UID and GID. When an Active Directory user attempts to log in after the agent is installed, the changed UID and GID cause ownership
and permission problems with the user’s home directory.
There are two basic approaches to solving this problem:
Changing the Delinea UIDs and GIDs

Modifying the Mac UID and GID to Match AD
Using Apple’s Scheme to Generate UIDs And GIDs For Mac Users
By default, Delinea uses a different scheme than the Apple Active Directory plugin to generate numeric user (UID) and group (GID) identifiers for Mac users
added to Active Directory. If you use the default Delinea scheme to generate identifiers, you must resolve UID and GID conflicts after migrating users. For
example, after migrating you can change ownership on the existing files (see Modifying the Mac UID and GID to Match AD otherwise users have Delinea-
generated UIDs whereas their files belong to Apple-generated UIDs so users will be unable to access files and folders in their home directories.
On the other hand, Delinea allows you to use the Apple scheme, rather than the default Delinea scheme, to create UIDs and GIDs for migrated users. This
method ensures compatibility with Mac tools, such as ExtremeZ-IP, that require UIDs and GIDs generated with the Apple scheme, not the Delinea scheme.
This section explains how to create Apple-generated UIDs and GIDs for Mac users who you are adding to Active Directory with Delinea Management Services
for Mac when a computer is connected to Delinea Active Directory through Auto Zone.
Note: If your computer is joined to a zone, however you are adding users to the zone, you can choose to use the Apple scheme to generate UID and
GID values. For example, you can specify the Apple scheme with adedit, with the Zone Provisioning Agent, and in the Access Manager Console.
Delinea provides the auto.schema.apple_scheme parameter to enable use of the Apple schema for generating UIDs for new users. The recommended way to set
this parameter is by way of group policy so that you can set it for a group of computers. You may also set the parameter on individual computers by editing the
Delinea configuration file
To use group policy to enable the Apple scheme for generating UIDs and GIDs:
1. If you are generating new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, back up the UIDs and GIDs on the computer where
the share resides by executing a command similar to the following:
adquery user > olduid
Note: You do not need to perform this step for Samba shares.
2. On a Windows computer, open the Group Policy Management Editor and edit a group policy object that applies to Mac computers.
3. Expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Direct Control Settings >
Adclient Settings, and double-click Generate New UID/GID using Apple scheme in Auto Zone.
4. Select Enabled and click O K to set the policy.
To edit the configuration file and enable the Apple scheme for generating UIDs and GIDs on a single computer:
1. If you are generating new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, back up the UIDs and GIDs on the server where the
computer resides by executing a command similar to the following:
2. Log in to a Mac computer.
3. Edit the Delinea configuration file: /etc/centrifydc/centrifydc.conf.
4. Find the following parameter, remove the comment and set its value to true:
auto.schema.apple_scheme: true
You may also enable the Apple scheme to set the primary GID for users if you wish.
Note: You may set the primary GID in this way only if the parameter auto.schema.private.group is set to false. Otherwise, the primary GID is set to the
value of the user’s UID.
To enable the Apple scheme for generating the primary GID:
1. If you are generating new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, back up the UIDs and GIDs on the computer where
the share resides by executing a command similar to the following:
2. In the Group Policy Management Editor, edit a group policy object that applies to Mac computers, expand Computer Configuration > Policies >
User Configuration > Policies > Centrify Settings > Direct Control Settings > Adclient Settings, and double-click Set user’s primary
gid in Auto Zone.
3. Select Enabled.
4. In Set user’s primary gid in Auto Zone, type -1.
The primary GID for each user will be generated by the Apple scheme, as specified with the “Generate New uid/gid using Apple scheme in Auto Zone”
group policy, which you enabled in the previous procedure.
5. Click O K to save the setting.
After setting these policies, run adgpupdate to update the group policies you just set, and flush the cache on each joined computer to update the UID and GID
values for any existing users.
To flush the cache on each Mac computer:
1. Log in to a Mac computer and open the Terminal application.
2. Execute the following command as root:
adflush
New users who you migrate to Active Directory from the Apple Active Directory plug-in will automatically keep the same UID, GID, and primary GID values that
they had before migration, and their home ownership will work properly.
After you flush the cache, any existing users and groups will have their UID, GID, and primary GID values changed from the Delinea scheme to the Apple
scheme. However, ownership of files and folders in home directories will still belong to the Delinea UID and GID. To change ownership to the new UID and GID
generated by the Apple scheme, run the fixhome.pl script as explained in the following procedure.
To correct file ownership by running fixhome.pl
Note: If you generated new UIDs and GIDs for files that reside remotely in AFP or NFS mounted shares, the fixhome.pl script does not have
permission to change UIDs and GIDs in the share, and you must manually update the UIDs and GIDs on the server where the share folders reside. In
this scenario, skip to Workaround for AFP and NFS Mounted Shares below and continue from there.
For Samba shares and local UIDs and GIDs:
1. Log in on a Mac computer for which you have changed UID and GID values to the Apple scheme.
2. Execute the following command as root:
/usr/local/share/centrifydc/sbin/fixhome.pl
The script changes ownership of files and folders in the home directory of all Active Directory users from the Delinea-generated UID or GID to the Apple-
generated UID or GID.
The script uses /Users as the root for all home directories. You may specify a different home root if necessary by using the --dir option. Use the --help option to
see a list of options that you can specify with this command:
/usr/local/share/centrifydc/sbin/fixhome.pl --help
For example, you can run the command in test mode to see the changes that will be made, but without committing the changes:
[root]#/usr/local/share/centrifydc/sbin/fixhome.pl --test
User Home UID Map GID Map
user1 /Users/user1 796918879=>558948313 20=>5287576209
Or you could update specific users rather than all users:
[root]#/usr/local/share/centrifydc/sbin/fixhome.pl --include user2
Workaround for AFP and NFS Mounted Shares
For AFP and NFS mounted share folders (or remote file systems), fixhome.pl does not have permission to change the UID/GID of files in the folder. Perform the
following steps to work around this issue:
1. On the server where the share folders reside, open the UID/GID backup file to have access to the old UID/GID strings.
2. On the server where the share folders reside, change the old UIDs and GIDs to the new UIDs and GIDs one at a time by executing commands similar to
the following:
find ShareFolder -user previous_uid -group previous_gid -exec chown new_uid:new_gid {} ;
To enable the Apple scheme for mobile users:
Additional steps are required to enable the Apple scheme for mobile users. After enabling the Apple scheme as described in the preceding sections, you must
ensure that the UID and PGID for the mobile user’s local user record match the UID and PGID used by the DirectControl agent.
1. Change the UID and PGID in the local user record so that they match the IDs used by the agent:
1. Open Users and Groups.
2. Right-click the mobile user account.
3. Choose Advanced Options, and change the UID and PGID so that they match the IDs used by the agent.
2. After changing the UIDs and PGIDs of mobile users, run the fixhome.pl script as described above in To correct file ownership by running fixhome.pl.
To use the Zone Provisioning Agent to enable the Apple scheme for generating UIDs and GIDs:
1. Ensure that the Zone Provisioning Agent is configured as described in the section “Configure the Zone Provisioning Agent” in the Planning and
Deployment Guide.
2. Ensure that zone provisioning groups are created and configured as described in Chapter 8, “Preparing the Environment for Migration of Existing Users
and Groups” in the Planning and Deployment Guide.
7. Click Enable auto-provisioning for group profiles.
8. Click the Find icon to search for and select the primary group (typically the Domain Users group) as the Source Group.
9. Select Generate using Apple scheme as the method for assigning a new GID to new UNIX group profiles.
This method generates group GIDs based on the Apple algorithm for generating numeric identifiers from the Active Directory group’s objectGuid. This
option is only supported for hierarchical zones.
10. Select a method for assigning a new group name to new UNIX group profiles:
SamAccountName attribute generates the group name for the new UNIX group profile based on the samAccountName value.
CN attribute can be used if you verify the common name does not contain spaces or special characters. Otherwise, you should not use this
option.
RFC 2307 attribute can be used if you have added the RFC 2307 groupName attribute to Active Directory group principals. Otherwise, you
should not use this option.
Zone default value to use the setting from the Group Defaults tab for the zone. In most cases, the default is a variable that uses the
sAMAccountName attribute.
By default, all UNIX group names are lowercase and invalid characters are replaced with underscores.
Configuring Auto-Enrollment
Delinea uses the Microsoft Windows certificate auto-enrollment feature to make certificates available to UNIX and Mac computers. If auto-enrollment is
enabled, when a UNIX or Mac computer joins a domain, certificates are requested from the Certification Authority based on particular templates, and the
certificates are installed on the joined computer
To enable auto-enrollment:
Enable auto-enrollment for the group policy.
Create a certificate template with auto-enrollment enabled.
Note: As of MacOS Big Sur (11.0), Apple no longer allows silently adding root certificates to Keychain with a trusted setting. If there are some
root certificates installed from your domain by the Delinea Agent, the Delinea Certificate Trust Setting Tool will open automatically. Please
follow the instructions to set certificates as trusted.
Configuring 802.1X Wireless Authentication
This section explains how to configure Active Directory and Mac to authenticate Active Directory users by using a Microsoft RADIUS server with the 802.1X
PEAP (MSCHAPv2) protocol over a wireless network from a Mac computer.
On Mac OS X, 802.1X wireless authentication does not rely on Delinea Access Manager or Apple's Active Directory plugin but is configured primarily through
group policies that apply to the Windows server and the Mac computers.
System Configuration for 802.1X Wireless Authentication
The following table summarizes the environment that is needed for 802.1X wireless authentication:
Environment Components / Configuration
Windows Server 2003 R2 Enterprise Edition Domain Controller (supports PEAP) with Internet Authentication Service (IAS) installed; on
Windows side Windows server 2003, RADIUS server is part of IAS. or Windows Server 2008 R2 Enterprise Edition Domain Controller (supports PEAP/TLS)
with Network Policy Server (NPS) installed; on Windows Server 2008, Radius server is part of NPS.
Active Directory on the Windows Server
Group Policy Management Console (GPMC), which is required to configure 802.1x group policies and deploy certificates.
Certificate Services, which is required to obtain the required certificates.
Access Manager console 5.1.x or later, which is required to set group policies that apply to Mac computer.
Mac side DirectControl agent 5.0.1-171 or later to enforce group policies on the Mac computer.
Wireless
Supports 802.1x wireless authentication through one of these protocols: * WPA Enterprise WPA2 Enterprise 802.1X WEP (the name can be
access point
different, for example, RADIUS)
device
Note: Although it is possible to configure other RADIUS servers for 802.1X wireless authentication, or use other protocols, this document focuses
on the Microsoft RADIUS server and the PEAP and TLS protocols.
These instructions assume that you have a RADIUS server properly configured for 802.1X wireless authentication, so that you can now proceed to configure
your Mac environment. For a description of how the RADIUS server must be configured to support 802.1X wireless authentication on Mac OS X, see the
section below named Confirming that Windows Server Supports Certificate Auto-enrollment. Click a link if you have questions about whether your RADIUS
server is configured properly with regard to any particular item:
Of course, there are other configuration steps that are required to set up a RADIUS server, such as configuring the RADIUS client and configuring a remote
access policy, however, the important consideration for Mac 802.1X authentication is that the specified certificate and private key have been created and
deployed to the domain. When a Mac computer joins a Windows domain, Access Manager automatically finds certificates on the Domain Controller and adds
them as trusted certificates to Keychain Access on the Mac computer.
Once you are certain that the RADIUS server is properly configured, you can configure your Mac environment; see the following section for instructions on
configuring OS X 10.7 or later.
Configuring Mac OS X 10.7 or Later for 802.1X Wireless Authentication
Mac OS X 10.7 changed the way to create and manage profiles such that configuring 802.1X wireless authentication varies significantly between 10.7 and
earlier versions of OS X. This section explains how to configure a Mac OS X 10.7 or later computer for 802.1X wireless authentication.
Before configuring your Mac environment, be certain that the RADIUS server is configured as described above in the section, System Configuration for 802.1X
Wireless Authentication. This configuration includes a domain root CA certificate or RAS/IAS server certificate, as well as a private key that are required to be
trusted on the Mac computer.
However, there are no manual steps that you must perform to trust these certificates on your Mac computers. As mentioned previously, when a computer is
joined to a domain, Access Manager automatically looks for certificates on the domain controller, and adds these certificates and the private key to the
system Keychain on the Mac computer.
Through group policy settings you can use these certificates to create two different types of system profiles
To create a system profile that allows users to authenticate to an 802.1X-protected ethernet network, see the next procedure, To configure Mac OS X
10.7 or Later to Create an 802.1X Ethernet Profile.
To create a system profile that allows users to authenticate to an 802.1X wireless network, see the procedure further down, To configure Mac OS X 10.7
or Later to Create an 802.1X WiFi Profile.
The certificate template — as well as a certificate chain file and private key — are pushed to /var/Centrify/net/certs on the Mac computer when it joins the domain.
Before you configure the group policy for the Mac computer, if you want to verify that auto-enrollment is operating correctly, you can open a Terminal window
on the Mac computer and run a command similar to the following to check that the certificate has been downloaded to the computer:
admin$ls /var/Centrify/net/certs |grep -i auto_
...
auto_TemplateName.cert
auto_TemplateName.chain
auto_TemplateName.key
You should see three auto_ files as shown in the example.
To configure Mac OS X 10.7 or later to create an 802.1X Ethernet profile
2. Expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X
Settings, and double-click Enable Ethernet Profile.
3. Select Enable, then click A d d.
4. Type the name of the auto-enrollment machine certificate that has been pushed down from the Windows domain server.
When pushed to a Mac computer, certificate names are prepended with auto_; for example:
auth_Centrify-1X
This group policy runs a script that looks for the specified certificate template in the /var/Centrify/net/certs directory (which contains the certificate
templates pushed down to Mac when they join the domain) and creates a WiFi profile from this certificate.
5. Click O K to save the profile information and O K again to save the policy setting.
Note: This group policy will take effect at the next group policy update interval, or you can run adgpupdate in a terminal window on the Mac
computer to have the policy take effect immediately.
When the group policy takes effect, it runs a script to create an ethernet profile for the computer from the certificate template and private key downloaded
from the domain controller. This policy supports the TLS protocol for certificate-based authentication. The Mac computer is now configured for access to
the radius access point.
On the Mac computer you can view the profile in System Preferences.
To configure Mac OS X 10.7 or later to create an 802.1X WiFi profile
2. Expand Computer Configuration > Policies > User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X
Settings, and double-click Enable Wi-Fi Profile.
3. Select Enable, then click A d d.
4. Enter the following information for the Wi-Fi profile:
Select
To do this
this
SSID Type the SSID for the wireless network.
Type the name of the auto-enrollment machine certificate that has been pushed down from the Windows domain server. When pushed to a Mac
Template computer, certificate names are prepended with auto_; for example: auth_Centrify-1X This group policy runs a script that looks for the
name specified certificate template in the /var/Centrify/net/certs directory (which contains the certificate templates pushed down from the domain
controller) and creates an ethernet profile from this certificate.
Security
Select the Security type from the drop-down list.
type
Select one or more of the following options: Auto join: Select this option to specify that the computer automatically join a Wi-Fi network that it
Other
recognizes. Do not select this option to specify that the logged in user must manually join a Wi-Fi network. Hidden network: Select this option
options
if the Wi-Fi network does not broadcast its SSID.
1. Click O K to save the profile information and O K again to save the policy setting.
Note: This group policy will take effect at the next group policy update interval, or you can run adgpupdate in a Terminal window on the Mac
computer to have the policy take effect immediately.
When the group policy takes effect, it runs a script to create a WiFi profile for the computer from the certificate template and private key downloaded from
the domain controller. This policy supports WEP or WPA/WPA2 security with the TLS protocol for certificate-based authentication. The Mac computer is now
configured for access to the radius access point.
On the Mac computer you can view the profile in System Preferences.
Confirming that Windows Server Supports Certificate Auto-enrollment
This section describes how the RADIUS server must be configured to support 802.1X wireless configuration for Mac computers.
Internet Information Services (IIS) Supports CertEnroll and CertSrv URLs
IIS must support the CertEnroll and CertSrv URLs to enable web-based access to certificate tasks.
To verify that IIs supports the CertEnroll and CertSrv URLs
1. On the Windows Certificate Authority server, click Start > Administrative Tools > Server Manager to open Server Manager.
2. Expand Roles > Web Server (IIS) and click Internet Information Services (IIS) Manager.
3. In the right, Connections pane, expand Sites > Default Web Site and you should see CertEnroll and CertSrv:
Windows Public Key Group Policies are Set to Trust the Root Certificate Authority and Enroll Certificates Automatically
Through group policy settings, the root certificate must be imported into the Trusted Root Certification Authorities group policy and set to enroll certificates
automatically.
To verify that Windows public key group policies are set to trust the root certificate authority and enroll certificates automatically
1. On the Windows Certificate Authority server, click Start > Administrative Tools > Server Manager to open the Group Policy Management Editor.
2. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and select Trusted Root
Certification Authorities.
You should see your root certificate:
3. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and double-click
Certificate Services Client - Auto-Enrollment.
4. In Configuration Model select Enabled.
5. Select both boxes, Renew expired certificates and Update certificates that use certificate templates.
A Certificate Template is Configured to Automatically Enroll Domain Computers
To automatically enroll domain computers, you must have a certificate template that supports auto-enrollment for domain computers.
To configure a certificate template to automatically enroll domain computers
1. On the Windows Certificate Authority server, open an mmc console that contains the Certification Authority and Certificates snap-ins (Start > Run >
mmc.exe).
2. If snap-ins for Certificate Templates, Certificates, and Certifications Authority are not displayed under Console Root in the navigation pane, add them
now. To do so, click File > Add/Remove Snap-in.
1. Select Certificate Templates and click A d d.

2. Click Certificates and click A d d.
3. Select Computer Account and click Next.
4. Select Local computer and click Finish.
5. Select Certification Authority and click A d d.
6. Select Local computer and click Finish.
7. Click O K.
3. Select Certificate Templates (domainController) in the navigation pane.
4. In Certificate Templates, duplicate the Workstation Authentication certificate. Right-click Workstation Authentication and select All Tasks >
Duplicate Template.
5. Perform the following steps in the Properties of New Template dialog:
1. In the General tab, type a template name of your choice (for example, Mac Auto-Enroll Certificates) in the Template name field (do not
use special characters such as brackets and asterisks). Type the same name in the Template display name field so that the template displays
by that name in the Certificate Templates list.
2. In the Extensions tab, select Application Policies > Edit. In the resulting dialog, select Add > Server Authentication and click O K.
3. In the Extensions tab, verify the Client Authentication is already in the application policy list. If it is not, add it in the same way that you added
the Server Authentication policy.
4. In the Subject Name tab, select Build from this Active Directory information. In the Subject name format field, select Fully
distinguished name. In the Include this information in alternate subject name list, select User Principle Name (UPN).
5. In the Security tab, select Domain Computers (domainController) and ensure that the template is enabled for Enroll and Autoenroll.
6. Click Apply and O K to save your settings.
6. Verify that the new template has been added to the certification authority.
Expand Console Root > Certification Authority > domainController and select Certificate Templates. You should see that the certificate
template that you have configured for auto-enrollment is contained in the certification authority for the domain:
If the new certificate template is not contained in the certification authority, add it now:
1. In the navigation pane, right-click Certification Templates under Console Root > Certification Authority > domainController.
2. Select New > Certificate Template to Issue.
3. Scroll to the newly created template, select it, and click O K.
7. Enable the following group policy:
On Windows 2008: Computer configuration > Policies > Windows Settings > Security Settings > Public Key Policies >
Certificate Services Client - Auto-Enrollment Settings.
On Windows 2012: Computer configuration > Policies > Windows Settings > Security Settings > Public Key Policies >
Certificate Services Client - Auto-Enrollment
Note: To enable a group policy, open the Group Policy Management console by selecting Start > Administrative Tools > Group
Policy Management. In the Group Policy Management console navigation pane, expand Group Policy Management >
ForestName > Domains > DomainName > Group Policy Objects. Right-click Default Domain Policy and select Edit. In the
resulting Group Policy Management Editor, navigate to the group policy described above and double-click the group policy. In the
resulting dialog, select Enabled in the Configuration Model field.
8. On the Mac computer, download the certificates by executing the following commands in a terminal window:
sudo adflush
adgpupdate
9. Verify that the certificates were downloaded:
1. On the Mac computer, open Keychain Access and verify that the certificates are there.
2. On the Mac computer, verify that the certificates are in /var/Centrify/net/certs.
3. On the Windows Certificate Authority server, open the Certification Authority console (Start > Run > certsrv.msc) and verify that the
certificates are in the Issued Certificates folder.
A Certificate Template is Configured to Automatically Enroll Domain Users
To automatically enroll domain users, you must have a certificate template that supports auto-enrollment for domain users.
To configure a certificate template to automatically enroll domain users
1. On the Windows Certificate Authority server, open an mmc console that contains the Certification Authority and Certificates snap-ins (Start > Run >
mmc.exe).
2. Verify that the snap-ins described in Step 2 are present under Console Root in the navigation pane. If they are not, add them now as described in Step 2.
3. Select Certificate Templates (domainController) in the navigation pane.
4. In Certificate Templates, duplicate the User certificate. Right-click User and select All Tasks > Duplicate Template.
5. Perform the following steps in the Properties of New Template dialog:
1. In the General tab, type a template name in the Template name field. Type the same name in the Template display name field so that the
template displays by that name in the Certificate Templates list. For Mac, you can specify a name of your choice (do not use special characters
such as brackets and asterisks). For mobile devices, the template name must be User-ClientAuth.
2. In the Security tab, select Domain Users (domainController) and ensure that the template is enabled for Enroll and Autoenroll.
3. Optionally, in the Subject Name tab, select Build from this Active Directory information. De-select the Include email in subject
name and E-mail name check boxes. If you perform this step, Active Directory users do not need an email address.
6. Verify that the new template has been added to the certification authority as described in Step 6. If the new certificate template is not contained in the
certification authority, add it now as described in Step 6.
7. Enable the following group policy:
On Windows 2008: Computer configuration > Windows Settings > Security Settings > Public Key Policies > Certificate
Services Client - Auto-Enrollment Settings.
On Windows 2012: Computer configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services
Client - Auto-Enrollment.
Note: See Step 7 for details about how to enable the group policy.
8. On the Mac computer, download the certificates by executing the following commands in a terminal window.
As the local Administrator:
sudo adflush
As an Active Directory user:
adgpupdate
9. Verify that the certificates were downloaded:
1. On the Mac computer, open Keychain Access and verify that the certificates are in the Login keychain.
2. On the Mac computer, verify that the certificates are in ~/.centrify/:
ls -l ~./centrify/
Configuring Single Sign-On for SSH and Screen Sharing
On OS X 10.10 and later, you can change configuration settings to allow single sign-on for SSH and Screen Sharing using Kerberos. Kerberos authorization for
SSH and Screen Sharing allows you to establish an SSH or Screen Sharing connection to configured target machines joined to the same domain within the
same single sign-on (SSO) session. In addition to authorizing SSH or Screen Sharing for the currently logged in user, you can authorize SSH or Screen Sharing
for a different smart card user (for example, an admin user) by obtaining that user’s Kerberos credentials.
To configure SSH SSO
Note: Smart card authentication for SSH sessions across different forests or domains is not supported.
1. Verify that all client and target machines are joined to the same AD domain.
See Joining an Active Directory Domain for more information.
2. Enable GSSAPIAuthentication and GSSAPIDelegateCredentials in the /etc/ssh/ssh_config (/etc/ssh_config on OS X 10.10) file on both the client and target machine.
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
3. Enable GSSAPIAuthentication and GSSAPIKeyExchange in the /etc/ssh/sshd_config (/etc/sshd_config on OS X 10.10) file on both the client and target machine.
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
Note: As of macOS 10.12, Apple's built-in ssh server no longer supports as the target machine. You can still use SSH SSO to login to other
server machines, such as Linux/UNIX machines.
4. Enable adclient.krb5.autoedit on the target machine.
The easiest way to do this is enabling the DirectControl Settings > Kerberos Settings > Manage Kerberos configuration group policy.
5. Restart Delinea Management Services on the target machine.
$ sudo /usr/local/share/centrifydc/bin/centrifydc restart
The logged in user can now open SSH connections to the target machine using a FQDN.
$ ssh hostname.domainname
To configure Screen Sharing SSO
Note: Single sign-on for Screen Sharing requires Mac OS X 10.11 or higher.
1. Verify that both the client and target machines are updated to at least Delinea Management Services 5.3.1.
$ adinfo -v
adinfo (CentrifyDC 5.3.1-xxx)
If an update is necessary, refer to Upgrading the Delinea DirectControl Agent for Mac for instructions and best practices.
2. Open System Preferences > Sharing, then select Screen Sharing and specify which users can initiate Screen Sharing sessions in the Allow
access for: list.
Note: Only Screen Sharing supports SSO, as Remote Management can not allow access for network users.
The logged in user can now open Screen Sharing connections to the target machine using a FQDN.
$ open vnc://hostname.domainname
To obtain Kerberos credentials for a smart card user for SSH or Screen Sharing SSO
1. Complete all the steps in To Configure SSH SSO and To Configure Screen Sharing SSO above.
2. Insert the user’s smart card into the reader.
3. Obtain Kerberos credentials from the smart card currently in the reader and use those credentials to authorize SSH.
For multi-user PIV cards or multi-user smart cards:
$ /usr/local/bin/sctool -a unixName
For all other smart cards:
$ /usr/local/bin/sctool -k userPrincipalName
Refer to Understanding sctool for more information about the sctool -a and -k options.
After unlocking the smart card, you can now open SSH or Screen Sharing connections to the target machine using the obtained Kerberos credentials.
Configuring FileVault 2
FileVault 2, available in OS X 10.8 and later, allows encryption of an entire drive to keep data secure. Although you can enable FileVault 2 through System
Preferences on your Mac computers, using Delinea Management Services for Mac to configure FileVault 2 through group policy provides the advantage of
creating an institutional recovery key for each of your Mac computers. Two different recovery key approaches—institutional and personal—guarantee that
you will always have access to all of your encrypted computers, even if users forget their passwords.
For more information about FileVault 2, see the following Apple Knowledge Base article: “OS X: About FileVault 2".
How Filevault2 Protection Is Enabled by Delinea
Delinea relies on two features to enable FileVault 2 protection
The "Managed By" user setting, which specifies an Active Directory user who can manage and unlock an encrypted disk.
You specify the “Managed By” user in Active Directory Users and Computers on the domain controller. The "Managed By" user is associated with the
Mac computer object, so it is possible for each computer to have its own "Managed By" user.
The FileVault recovery key, which can be either one “institutional” key that is applied to multiple Mac computers, or computer-specific keys which are
generated individually for each Mac computer.
If you choose to use one institutional key, you first create a FileVaultMaster certificate, which is applied to Mac computers through the Enable
FileVault 2 group policy.
When you enable the Enable FileVault 2 group policy, the FileVaultMaster certificate is applied to Mac computers automatically at the next scheduled group policy update interval.
Or, you can apply the FileVaultMaster certificate immediately by executing the adgpupdate command.
If you choose to use computer-specific keys that are unique to each Mac computer, you do not create a FileVaultMaster certificate.
Instead, the key is generated automatically when the “Managed By” user logs into the Mac computer for the first time and then logs out. The key, which is the “Managed By” user’s
personal key, is then stored in the computer’s computer object in Active Directory.
>**Note**: Enabling the Enable FileVault 2 group policy does not enable FileVault 2 protection on the Mac computers to which the group policy is applied. Instead, FileVault 2
protection is enabled on Mac computers as described in the remainder of this section.
The following list describes the overall process that results in FileVault 2 protection being enabled on a Mac computer.
1. The “Managed By” user is set in ADUC for one or more Mac computers.
2. The Enable FileVault 2 group policy is enabled.
If you select the Use Institutional Recovery Key option in the group policy, the FileVaultMaster certificate is applied to Mac computers. In this
situation, all of the Mac computers to which the group policy was applied use the same key.
If you did not select the Use Institutional Recovery Key option in the group policy, a recovery key is not generated until the “Managed By” user
logs into a Mac computer.
3. A user logs into a Mac computer. If FileVault 2 protection is not already enabled on the computer, the user’s Active Directory credentials are checked to
verify that the user is the “Managed By” user. For this step to complete successfully, one of the following conditions must exist:
The Mac computer must be able to communicate with the domain controller (that is, it must be in connected mode), or
If the Mac computer is disconnected from the domain controller, locally cached AD user credentials must be available in the Delinea cache.
4. When the user is verified to be the “Managed By” user, one of the following actions takes place:
If you selected the Use Institutional Recovery Key option in the Enable FileVault 2 group policy, the FileVaultMaster certificate data is used to
enable FileVault 2 protection on the computer.
If you did not select the Use Institutional Recovery Key option in the Enable FileVault 2 group policy, a personal recovery key is created for the
computer and stored in the computer object in Active Directory. The personal recovery key is used to enable FileVault2 protection on the
computer.
FileVault 2 Configuration Overview
Configuring a Mac computer for FileVault 2 protection requires configuration steps on both the Mac computer and the domain controller (or any Windows
computer on which you can configure Group Policy on the domain controller). The following is a list of the major steps in the process, with links to each
procedure that you must complete.
1. Create FileVault master keychain. The master keychain contains a private key that can be used to unlock the encrypted disk.
Note: This step is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific
(“personal”) keys, go to Step 4.
2. Export certificate from FileVault master keychain and upload it to a domain server. Uploading the certificate to a domain server allows you to select it
when you enable the “FileVault 2” group policy.
Note: This step is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific
(“personal”) keys, go to Step 4.
3. Enable BitLocker Recovery Password Viewer in Active Directory.
This step is required only if you are using computer-specific (“personal”) keys. If you are using one institutional key for multiple Mac computers, go to
Step 4.
4. Assign an Active Directory user who is authorized to manage an encrypted disk. FileVault 2 requires that you specify one or more “Managed By” users
who can manage the encrypted disk, including the ability to lock and unlock it.
5. Enable the Enable FileVault 2 group policy. Enabling the “FileVault 2” group policy applies the FileVaultMaster certificate to Mac computers.
6. Set up and verify FileVault 2 protection. After FileVault 2 protection is enabled, the disk encryption process begins after the FileVault-authorized user
logs off the computer.
Before You Begin Configuring Filevault 2
Be aware of the following requirements and limitations when configuring FileVault 2 through Delinea group policy:
The Mac computer must be running OS X 10.9 or above.
The Mac computer must have a recovery partition — generally, this partition is created by default during Mac OS X or macOS installation.
FileVault 2 must not be enabled on the Mac computer (through the Security & Privacy System Preference).
If it is already configured, configuring FileVault 2 through Delinea Management Services for Mac will have no effect.
Enabling FileVault 2 protection disables auto log on for the Mac computer.
FileVault 2 protection does not support smart card authentication at start up of the computer.
The Apple technical white paper, "Best Practices for Deploying FileVault2" provides more information about using FileVault 2; specifically, the section
“Two Factor Authentication” discusses the limitations of using FileVault 2 with alternate authentication methods such as smart cards.
Create Filevault Master Keychain
The procedure described in this section is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific
(“personal”) keys, go to the section below, Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk.
On the Mac computer, you create a FileVault master keychain, which contains a private key that can be used to unlock the encrypted drive on the computer.
You can create the master keychain through the Mac user interface, or by executing commands in the Terminal application. Instructions are provided for
each procedure.
Note: If the computer already has a FileVault master keychain, you can skip this procedure and go to Export certificate from FileVault master
keychain and upload it to a domain server.
To create a master keychain through the user interface
1. On a computer running OS X 10.9 or above, log on with an administrator’s account and open System Preferences, then double-click Users &
Groups.
2. If necessary, click the lock icon and enter credentials to authenticate.
3. Select an administrator’s account, then click the service icon ( ) and select Set Master Password from the pop-up menu.
4. Create a master password by typing it in Master password and re-typing in Verify.
5. Click O K to save the master password.
Setting a master password creates a keychain file in the following location:
/Library/Keychains/FileVaultMaster.keychain
This file contains the private key required to unlock the encrypted disc and is the only recovery method you will have for encrypted disc recovery. Store
FileVaultMaster.keychain in a safe location, such as an external drive or an encrypted disk image on another physical disk.
To create a master keychain by executing commands in the Terminal application
1. On a Mac computer, open the Terminal application.
sudo security create-filevaultmaster-keychain
3. Enter the password for the root account when prompted as follows:
To proceed, enter your password or type Ctrl-C to abort
4. Enter the master password to create when prompted to do so:
password for new keychain
5. Retype the new master password when prompted to do so:
retype password for new keychain
You will see a message that the new password is being created:
Generating a 2048 bit key pair; ...
Setting a master password creates a keychain file in the following location:
This file contains the private key required to unlock the encrypted disc and is the only recovery method you will have for encrypted disc recovery. Store
FileVaultMaster.keychain in a safe location, such as an external drive or an encrypted disk image on another physical disk.
Export Certificate from Filevault Master Keychain and Upload it to a Domain Server
The procedure described in this section is required only if you are using one institutional key for multiple Mac computers. If you are using computer-specific
(“personal”) keys, go to the section below Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk.
After you create a master password, as explained in the previous section, you must export the certificate associated with the master keychain to make it
available for upload to the domain controller.
You can export the certificate by using the Mac user interface, or by executing commands in the Terminal application. Instructions are provided for each
procedure.
To export the certificate by using the Keychain Access utility
1. On the Mac computer, open the Keychain Access utility, or double-click the FileVaultMaster.keychain file, which is at the following location:
2. Enter you password if prompted to do so.
3. In Keychains, select FileVaultMaster.
4. Select the certificate, FileVault Recovery Key in the right pane and expand it; then right-click and select Export “FileVault Recovery Key”.
5. Enter the following information for saving the certificate:
Save As: Type a name for the certificate, such as “FileVaultMasterCert”.
Where: Navigate to a folder in which to save the certificate.
File Format: Select Certificate (.cer) from the scroll-down list.
The certificate is now available for upload to a domain controller.
6. Copy the certificate to a location on a server that is accessible from the computer that you use to configure Group Policy for the domain.
Later, when you enable the group policy to turn on FileVault 2 protection (see Enable the Enable FileVault 2 Group Policy below), you must be able
to access this certificate from the domain controller on which you are running the Group Policy Editor.
To export the certificate by using Terminal commands
1. On the Mac computer, open the Terminal utility application.
sudo security export -k /PathToKeychain -t certs -f x509 -o /PathToCert
Note: The sudo command is required only if FileVaultMaster.keychain is owned by root.
where:
PathToKeychain is the path to FileVaultMaster.keychain; for example:
PathToCert is the path to the location in which to export the certificate; for example:
/Documents/FileVaultMaster.cer
The certificate is now available for upload to a domain controller.
1. Copy the certificate to a location on a server that is accessible from the computer that you are using to configure Group Policy for the domain.
Later, when you enable the group policy to turn on FileVault 2 protection (see Enable the Enable FileVault 2 Group Policy below), you must be able
to access this certificate from the domain controller on which you are running the Group Policy Editor.
Enable Bitlocker Recovery Password Viewer in Active Directory
The procedure described in this section is required only if you are using computer-specific (“personal”) keys. If you are using one institutional key for multiple
Mac computers, go to Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk, below.
To enable the BitLocker Recovery Password Viewer feature in Active Directory
1. On the domain controller, open Administrative Tools > Server Manager.

2. In the navigation pane, right-click Features and select Add Features.
3. In the Add Features wizard, expand Remote Server Administration Tools > Feature Administration Tools, select BitLocker Drive
Encryption Administration Utilities, click Next, and click Install.
4. After the BitLocker Drive Encryption Administration Utilities are installed, click Close.
5. To verify that the BitLocker Drive Encryption Administration Utilities are installed:
1. Open Active Directory Users and Computers.
2. Navigate to domaincontroller > Domain Controllers.
3. In the right-hand ADUC pane, right-click the domain controller and select Properties.
4. If the BitLocker Drive Encryption Administration Utilities installed correctly, the Properties dialog contains a Bitlocker Recovery tab. On that
tab, a “No items in this view” message displays. That message is normal, and does not indicate a problem with the BitLocker Drive Encryption
Administration Utilities installation.
Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk
Before enabling FileVault 2, you must assign a user account that is able to open the disk for the Mac computer after it is encrypted by FileVault 2. This setting
specifies the “Managed By” user for a computer.
Note: Enabling the “FileVault2” group policy, as explained in the next section, encrypts the entire disk for the computer. The user account that you
assign in the current procedure will be authorized to access the disk during boot up so that this account will be able to log on. You can later add
other accounts, but for now, this is the only account that will be able to log on to this computer.
The “Managed By” user account must be an Active Directory mobile user account. Configuring a Portable Home Directory for information about the steps you
must take to create a mobile user account.
Note: After you enable a user account to open an encrypted disk at start up, you cannot remove that account from the list. If you no longer want
this user account to be able to unlock the disk, you can delete the account from Active Directory. Before doing so, be certain that you have at least
one other account that can unlock the hard disk on this computer, otherwise you will no longer be able to access this computer.
To assign an account that can unlock the encrypted disk
1. On a domain controller, open Active Directory Users and Computers
2. Expand the domain object and navigate to the container that contains the Mac computer, for example, Computers.
3. Select the Mac computer that you plan to encrypt, right-click and select Properties.
4. Click the Managed By tab.
5. Click Change.
6. Enter the all or part of the name to search for (make certain that User is selected in Object Type) and click Check Names.
7. If the name is correct, click O K then O K again to save your changes.
Enable the Enable Filevault 2 Group Policy
Next, enable the “Enable FileVault 2” group policy to encrypt the disk. When you enable this group policy, you select whether to use one institutional key for
multiple Mac computers, or computer-specific (“personal”) keys.
To enable the Enable FileVault 2 group policy
1. On a Windows computer, open the Group Policy Management Editor.
2. Select a Group Policy Object that applies to the Mac computer you are planning to encrypt, then right-click and select Edit.
3. Open Computer Configuration > User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy, then
double-click Enable FileVault 2.
4. Click Enable.
5. Specify whether to use one institutional key for multiple Mac computers, or computer-specific (“personal”) keys:
To use one institutional key for multiple Mac computers, select Use Institutional Recovery Key. Then click Select to select the FileVault
keychain certificate that you created earlier as described above in Create FileVault Master Keychain. If you select this option, the
FileVaultMaster certificate is distributed to all of the Mac computers to which the group policy applies. Go to Step 6 and continue from there.
To use computer-specific (“personal”) keys, leave Use Institutional Recovery Key unchecked. In this situation, a personal recovery key is
created for the Mac computer and stored in the computer object in Active Directory. The key is created and sent to the computer object in Active
Directory after the “Managed By” user reboots the Mac computer (or restarts the agent), logs in, logs out, and provides the user password as
described below in Set Up and Verify FileVault 2 Protection. The personal recovery key is used to enable FileVault2 protection on the Mac
computer. Go to Step 8 and continue from there.
6. In the Explorer dialogue, navigate to the folder in which you uploaded the certificate.
7. Select the certificate and click Open.
8. Click O K to enable the group policy.
This group policy will automatically take effect at the next group policy update interval. To have it take effect immediately, run the following command
in the Terminal application on the Mac computer:
adgpudate
If you selected Use Institutional Recovery Key in Step 5, the FileVaultMaster certificate name, a thumbnail, and the expiration date are displayed in
the Group Policy.
Note: The expiration date is not important because OS X does no revocation checking on this certificate.
The selected certificate should have the following usages: “Digital Signature”, “Key Encipherment”, “Data Encipherment” and “Key Certificate Sign”. If
the certificate does not have these usages, an error message will appear:
Set Up and Verify Filevault 2 Protection
FileVault 2 protects a Mac computer by encrypting the entire hard drive when a FileVault-authorized user (the “Managed By” user) logs out. To set up FileVault
2 for the first time, you must log on to the Mac computer as the “Managed By” user, then log out, as explained in the following procedure. After FileVault 2 is
set up, only a FileVault 2-authorized user may start up the Mac computer. You may add more authorized users if you wish, or maintain a single account.
Note: Although starting up the Mac computer requires a user account that is authorized to decrypt the start up disk, after the computer has
started, this user account may log out to allow other user accounts to log in.
To set up FileVault 2 protection
1. Log on to the Mac computer with the “Managed By” account that you specified above in Assign an Active Directory User Who is Authorized to
Manage an Encrypted Disk.
2. Log the “Managed By” user out of the Mac computer, and when prompted, enter the user’s password to set up FileVault 2 protection.
The system displays a message that it is enabling FileVault protection, and when finished, restarts the computer.
3. Log back on to the Mac computer with the “Managed By” account.
The log on screen will show the FileVault 2-authorized user alone, because this is the only user authorized to open the start up disk.
4. Open System Preferences, click Security & Privacy and click the FileVault tab to verify details about FileVault protection.
5. Log out the FileVault-authorized user.
The log on screen now shows all users who are authorized for the computer.
A FileVault-authorized user is always required to start up the computer because the start up disk is encrypted. However, after the computer is running, any
authorized user can log on to the computer. At this point, you have specified a single authorized account. To add more FileVault-authorized users, see the
next section, Adding FileVault-Authorized Users.
Adding Filevault-Authorized Users
You can assign only one user as the “Managed By” user for the computer in Active Directory. If you want to authorize additional users to manage FileVault 2
protection, you must do so on the Mac computer by performing either one of the following procedures.
To authorize FileVault 2 users by using System Preferences
1. On the Mac computer, open System Preferences > Security & Privacy.
2. Click the FileVault tab, and if necessary, unlock the padlock.
3. Click the Enable Users button and an account list pops up.
4. Click Enable Users to add and enter password of that user.
To authorize FileVault 2 users by using Terminal commands
1. On the Mac computer, open the Terminal application.
sudo fdesetup add -usertoadd user1
If prompted, enter the sudo password.
3. When prompted, enter the primary FileVault-authorized user name — this is the user who you specified to manage FileVault 2 (in the section above,
Assign an Active Directory User Who is Authorized to Manage an Encrypted Disk).
4. When prompted, enter the password for the primary FileVault-authorized user.
5. When prompted, enter the password for the new user who you specified on the command line (user1 in this example).
Changing FileVault 2 Settings
After you enable FileVault 2, the settings that you are most likely to change at a later time are the “Managed By” user and the FileVaultMaster certificate.
To change the “Managed By” user on a Mac computer
1. Disable FileVault 2 manually on the Mac computer as described below in Disabling FileVault 2 Protection.
2. On the domain controller, change the “Managed By” user as described in the section above, Assign an Active Directory User Who is Authorized
to Manage an Encrypted Disk.
3. Ensure that the Mac computer can communicate with the domain controller (that is, it is in connected mode) so that it can fetch the new “Managed By”
user information from Active Directory.
After you complete these steps, FileVault 2 protection is enabled on the Mac computer the next time the new “Managed By” user logs into the Mac computer.
To change the FileVaultMaster certificate
Note: The procedure described in this section is supported only if you are using one institutional key for multiple Mac computers (that is, if you
selected Use Institutional Recovery Key in Enable the Enable FileVault 2 Group Policy, above).
1. Disable FileVault 2 manually on each Mac computer that will use the new FileVaultMaster certificate. In most situations, this includes all computers to
which the Enable FileVault 2 group policy is applied.
2. Specify a new FileVaultMaster certificate in the Enable FileVault 2 group policy as described in Enable the Enable FileVault 2 Group Policy, above.
3. Execute the adgpupdate command to have the Enable FileVault 2 group policy implement the new FileVaultMaster certificate on the Mac computers.
If you do not execute adgpupdate, the old FileVaultMaster certificate is used until the next scheduled group policy update interval.
After you complete these steps:
All Mac computers on which you disabled FileVault 2 (in Step 1) will use the new FileVaultMaster certificate the next time the “Managed By” user logs in.
FileVault 2 protection is enabled on a Mac computer the next time the “Managed By” user logs into that Mac computer.
Disabling FileVault 2 Protection
The only way to disable FileVault 2 protection is manually on the Mac computer. You cannot disable it by disabling the Enable FileVault 2 group policy.
You can disable FileVault 2 protection through the Security & Privacy System Preference, or by issuing commands in the Terminal application — view one or
the other of the two sets of instructions that follow.
To disable FileVault 2 protection by using Security & Privacy preferences
1. On the Mac computer, open System Preferences > Security & Privacy and click the FileVault tab.
2. Click the padlock and enter authentication information to unlock System Preferences.
3. Click Turn Off FileVault.
4. Click the padlock to secure the changes.
5. Restart the Mac computer.
The disk is no longer encrypted and all authorized users, not just FileVault-authorized users, should be visible on the log on screen.
To disable FileVault 2 protection by issuing Terminal commands
1. On the Mac computer, open the Terminal application.
2. Enter the following command:
sudo fdesetup disable
3. Enter the root password when prompted.
4. Enter the password for the user account that is authorized to lock or unlock the disk.
This is the password for the user who you assigned in Active Directory to manage the Mac OS X computer.
5. Restart the Mac computer.
The disk is no longer encrypted and all authorized users, not just FileVault-authorized users, should be visible on the log on screen.
What Happens if the Filevault-Authorized User’s Password is Reset?
If the password is reset while the computer is off or not connected to the domain, the password will not be immediately updated so the user must first log in
with the old password, then back in with the new password.
For example, follow these steps for a sample set up such as the following:
The Mac computer is turned off.

FileVault 2 is enabled.
user1 is the primary FileVault 2 authorized user.
1. An administrator changes the user1 password in Active Directory Users and Computers (through Reset Password), and informs user1 of the change.
2. You start up the computer, log on as user1, and enter the new password, which fails.
3. Enter the old password, which works.
4. Restart the computer, log on and enter the new password, which should be successful.
Restoring the Filevault User List After Adflush
In Server Suite, if your FileVault 2 user list contains mobile users from another forest with one-way trust (that is, cross-forest mobile users), it is possible that
those users will be removed from the FileVault 2 user list after you execute adflush or adflush -f.
After you upgrade to release 2015.1 or later, perform the following steps to ensure that cross-forest mobile users are added to the FileVault 2 user list
permanently:
1. Execute the following command:
adflush -f
Executing this command removes the 2015-format, temporary GUID from cross-forest mobile users.
2. Execute the following command for each cross-forest mobile user that you want to add permanently to the FileVault 2 user list:
adquery user -guid cross-forest-mobile-user-name
Executing this command assigns a new, permanent GUID to each user that you specify.
3. Execute the following command for each cross-forest mobile user that you want to add to the FileVault 2 user list:
fdesetup add -usertoadd cross-forest-mobile-user-name
Executing this command adds the specified user to the FileVault 2 user list.
4. Execute the following command to verify that the users are added to the FileVault 2 user list:
fdesetup list
How to Recover an Encrypted Disk
If a user forgets the password for their encrypted disk, you can unlock the disk for them using the institutional recovery key that you created. See the
following two Web articles for information:
Apple Support: “OS X: How to create and deploy a recovery key for FileVault 2”.
Note that you have already created the recovery key — you only need to read the information in the “Recovery” section.
“Unlock or decrypt your FileVault 2-encrypted boot drive from the command line”
Deploy Configuration Profiles to Multiple Computers
This section explains how to deploy mobile configuration profiles to multiple computers by using a group policy setting (Install mobileconfig Profiles).
Note: You can create mobile configuration profiles in a number of ways, for example by using the iPhone Config utility or OS X Server Profile
Manager. This document assumes that you have already created a profile that you want to deploy, but does not show you how to do so.
You can deploy either computer or user profiles. For computer profiles, this feature requires OS X 10.7 or higher. For user profiles, this feature requires OS X
10.9 and higher.
The process for deploying a mobile configuration profile is as follows:
1. Create the mobile configuration profile.

2. Create a subdirectory in SYSVOL on the domain controller and copy the mobile configuration profile file to this directory. SYSVOL is a well-known shared
directory on the domain controller that stores server copies of public files that must be shared throughout the domain.
3. Enable the “Install mobileconfig Profiles” group policy and specify the name of the file that you copied to SYSVOL.
4. The mapper script for the group policy runs on each Mac computer controlled by the GPO (when a user logs in or runs adupdate), downloads the profiles
from the Active Directory server, and installs them in the Profiles system preference.
To create a subdirectory in SYSVOL:
1. Log in to the domain controller.
2. Change to the SYSVOL directory.
For example, go to this directory:
C:WindowsSYSVOLdomain
3. Create a new folder named mobileconfig.
Note: Be certain that the name of the folder is exactly as shown in the step above. The group policy setting allows you to specify the name of
the file but it always looks in SYSVOL\mobileconfig. Likewise, do not create sub-folders — the group policy does not look in sub-folders.
To copy configuration files to SYSVOL on the domain controller:
1. In the Finder on the Mac computer navigate to the folder that contains the profile to copy.
2. Select the file, for example, settings_for_all.mobileconfig and copy it to the desktop. When prompted, enter your administrator password to copy the file.
3. On the desktop, change the file permissions for settings_for_all.mobileconfig as follows, so you can copy it to SYSVOL:
1. Select the file and click File > Get Info.
2. In the dialog box, expand Sharing & Permissions, then click the lock icon and provide administrator credentials for making changes. Set the
permissions for everyone to Read only.
3. Reset the lock and close the open dialog.
4. On the Mac computer, copy the file from the desktop to SYSVOL on the Windows domain controller. If you are connected to the domain, you should see
the domain controller in the Finder. If the domain controller is not visible in the Finder, connect to it:
2. When prompted select SYSVOL; for example:
3. Navigate to the mobileconfig directory you created, for example by clicking acme.com then mobileconfig.
4. Drag the settings_for_all.mobileconfig file to mobileconfig.
To configure the “Install MobileConfig Profiles” group policy:
1. On the Windows domain controller, open the Group Policy Management Editor and select the GPO that is used to manage Mac computers.
2. Navigate to Computer Configuration > Policies > Mac OS X Settings > Custom Settings and double-click Install MobileConfig Profiles
to install a machine profile.
To install a user profile, navigate to User Configuration > Policies > Mac OS X Settings > Custom Settings and double-click Install
MobileConfig Profiles.
3. Select Enabled.
4. Click A d d, then enter the name of the file that you copied to SYSVOL, for example, settings_for_all.mobileconfig.
Be certain to include the .mobileconfig suffix.
5. Click O K to add the settings_for_all.mobileconfig file.
6. Click O K to enable the policy.
This group policy will copy the settings_for_all.mobileconfg file, and install the profile, on every computer to which the GPO applies and that is joined to the
domain. Note that after the profile is installed, it is deleted from the Mac computer.
7. Run the adgpupdate command on each target Mac computer to trigger an update of group policies and execute the new Install MobileConfig Profiles policy
settings.
By default, group policies are updated automatically every 90 minutes, so you can skip this step and wait for the automatic update if you wish.
Note the following about this process:
If you add a profile file to SYSVOL, but do not specify it in the group policy setting, the profile will not be installed. Likewise, if you specify a file in the group
policy that does not exist in SYSVOL, the profile will not be installed.
If you add new files to the existing list in the group policy, those profiles will be installed — existing profiles will not be touched.
If you remove a file from the group policy list (after the profile for the file was installed), the profile for that file will be uninstalled from the managed Mac
computers.
If you modify a file, the corresponding profile will be reinstalled.
If two or more profile files have the same payloadIdentifier attribute, only one of them will be installed.
If you change the group policy to “Disabled” or “Not Configured”, all existing profiles that were installed previously by the group policy will now be
uninstalled from the managed Mac computers.
Note: The "Install MobileConfig Profiles" group policy only supports macOS 10.15 and lower.
Understanding Group Policies for Mac Users and Computers
Centrify group policies allow administrators to extend the configuration management capabilities of Windows Group Policy Objects to managed Mac
computers and to users who log on to Mac computers. This chapter provides an overview to using the Delinea Mac group policies that can be applied to Mac
computers and users
For reference information about the Mac OS X-specific computer and user policies that you can set, see the following topics.
Setting Computer-based Group Policies

Setting User-based Group Policies
For additional information about creating and using group policies and Group Policy Objects, see your Windows or Active Directory documentation, such as
https://technet.microsoft.com/en-us/windowsserver/bb310732.aspx.
For information about other Centrify group policies that are not specific to Mac computers and users, see the Group Policy Guide.
Understanding Group Policies and System Preferences
Linking Group Policy Objects
Installing Mac Group Policies
Setting Mac Group Policies
Applying Standard Windows Policies to Mac OS X
Configuring Mac-specific Parameters
Understanding Group Policies and System Preferences
In many organizations, administrators who have both Windows and Mac computers in their organization want to manage settings for their Windows and
Macintosh computers and users using a standard set of tools. In a Windows environment, the standard method for managing computer and user
configuration settings is through Group Policy Objects applied to the appropriate site, domain, or organizational unit (OU) for different sets of computer and
user accounts.
Delinea provides this capability for Mac computers and users through a group policy extension. The Delinea administrative template for Mac OS X
(centrify_mac_settings.xml or centrify_mac_settings.adm) provides group policies that can be applied from a Windows server to control Mac OS X settings and behavior.
These group policies can be applied to Mac OS X computers and to users who log on to those computers
Through the Delinea administrative template for Mac OS X, Windows administrators using the Group Policy Management Editor can centrally access and
control native Mac system preferences.
In the current Delinea administrative template for Mac OS X, Centrify group policies control settings for Personal, Hardware, Internet & Network, and System
preferences, including:
Accounts, (General) Appearance, Desktop & Screen Saver, Dock, Energy Saver, Network, Security & Privacy, Sharing, Software Update, and so on.
When you enable a group policy in a Windows Group Policy Object, you effectively set a corresponding system preference on the local Mac computer where
the group policy is applied. For example, if you enable the group policy Computer Configuration > Delinea Settings > Mac OS X Settings >
Security > Require password to unlock each secure system preference, it is the same as selecting the General tab of the Security & Privacy
system preference, then clicking the Require an administrator password to access system preferences with lock icons option on a local Mac OS
X computer. Once the group policy is enabled in the Windows Group Policy Object and updated on the local Mac computer, the corresponding option is
checked:
In addition to the system preferences that are typically set on individual computers, there are many Mac configuration settings that are typically set from a
Mac OS X server using the Workgroup Manager. These workgroup policies control application or media access, synchronization rules for mobile user
accounts, the look and operation of the Dock, and other settings. The Delinea administrative template for Mac provides centralized access to many of these
Workgroup Manager settings, including Applications, Dock, Media Access, Mobility, Software Update, and System Preferences.
Note: Not all group policies apply to all versions of the Mac operating environment or all computer models. If a particular system preference does
not exist, is not applicable to the installed operating system, or is implemented differently on some computers, the group policy setting may be
ignored or overridden by a local setting.
Group policies are available after you install the Delinea administrative template for Mac as described in Installing the Administrative Template, below.
After you install the administrative template, the Windows administrator can use Active Directory MMC snap-ins or the Group Policy Management Console to
create and link Group Policy Objects to sites, domains, or organizational units that include Mac computers that are joined to an Active Directory domain.
Administrators can then use the Group Policy Management Editor to enable and configure the specific policies they want to enforce on Mac computers that
are joined to the Active Directory domain.
See the Group Policy Guide for more information about using Active Directory Users and Computers or using the Group Policy Management Console or adding
other Delinea administrative templates to a Group Policy Object.
Linking Group Policy Objects
To apply group policies to Mac computers, you can link an existing group policy object (GPO) that you are using for a Windows or UNIX computer, or create a
new GPO to link to a domain or OU that contains your Mac computers and users. In general, it is recommended that you create an OU specifically for your Mac
computers and link a new GPO to that OU. However, there is no problem adding the Mac group policies to an existing GPO and configuring policies for Mac
computers; Mac OS X-specific policies that are applied to Windows or UNIX computers are simply ignored.
You apply GPOs to Mac users the same way; link the GPO to an OU containing the users. Group policies are only applied to users and computers in the
organizational unit (OU) linked to the Group Policy object (GPO) and any of the child OUs. If your users and computers are in different OUs (which is
common), Delinea recommends using user Group Policy loopback processing to make sure user policies are applied to everyone who logs on to a Mac. This is
a standard Microsoft Group Policy that applies to every user to the computer. See Setting User-based Group Policies for more information about applying
user policies.
Installing Mac Group Policies
Centrify group policies for Mac consist of two components
The DirectControl agent for Mac and its associated configuration and system plug-in files that reside on the Mac computer. The DirectControl agent
and related files determine the policies that have been applied to the local computer, or to the user who is logging on, and implement the policy through
system preferences or other local configuration settings. This guide assumes that you have installed the DirectControl agent on your Mac computers.
An administrative template (.xml or .admx file) that describes the policy settings available to the Group Policy Management Editor. The administrative
template must be installed on a Windows computer that has the Group Policy Management Editor and the Delinea Group Policy Management Editor
Extension. The Group Policy Management Editor and the Delinea Group Policy Management Editor Extension must be available for you to enable and
configure policies. See the Mac Quick Start Guide for more information.
Installing the Administrative Template
Delinea provides templates in both XML and ADMX format. In most cases it is best to use the XML templates, which provide greater flexibility, such as the
ability to edit settings after setting them initially, and in many cases contain validation scripts for the policies implemented in the template
However, in certain cases, you may want to add templates by using the ADMX files. For example, if you have implemented a set of custom tools for the
Windows ADMX-based policies, and want to extend those tools to work with the Delinea policies, you can implement the policies with ADMX template files.
The Group Policy Management Editor will automatically read all ADMX files stored in the %systemroot%PolicyDefinitions folder.
The ADMX templates do not support extended ASCII code for locales that require double-byte characters. For these locales, you should use the XML
templates.
To install the Delinea XML administrative template for Mac group policies
This procedure assumes that you are using the Group Policy Management Console and have created a Mac OS X-specific GPO. For information about using a
different console, such as ADUC, see the Group Policy Guide.
1. Open the Group Policy Management Console and select the Group Policy Object that you are using for Mac computers, right-click, then click Edit to
open the Group Policy Management Editor.
2. Expand Computer Configuration > Policies and select Delinea Settings. Right click and click Add/Remove Templates.
3. Click A d d, then navigate to the directory that contains the Delinea centrify_mac_settings.xml administrative template. By default, Delinea administrative
templates are located in the C:Program Files\Common Files\Centrify Shared\Group Policy Management Editor Extension\policy folder.
4. Select the centrify_mac_settings.xml file, then click Open to add this template to the list of Policy Templates.
5. Click O K.
You should now see the categories of Mac group policies listed as Mac OS X Settings under Delinea Settings in the Group Policy Management Editor. For
example:
Note: If you update Delinea to a new version, new templates may be included with the installation. To make any new policies included in the
templates available for use, you must reapply each template by following the steps in one of these procedures. If you see the message, The selected
XML file already exists. Do you want to overwrite it?, click Yes. This action overwrites the template with any new or modified group policies. It does not
affect any configuration in the template that has been applied; that is, any policies that you have enabled remain enabled.
Setting Mac Group Policies
Like other group policies, policies for Mac users and computers are organized into categories within the Group Policy Management Editor under Computer
Configuration > Policies > Centrify Settings > Mac OS X Settings (Setting Computer-based Group Policies) or Delinea Settings > Mac OS X
Settings (Setting User-based Group Policies). In general, these categories map directly to different types of Mac system preferences and individual policy
settings within the categories map to specific settings within the system preference.
Normally, once enabled, policies get applied at the next group policy refresh interval, after the user logs out and logs back in, or after the computer has been
rebooted. Some Mac group policies, however, require the user to log out and log back in or the computer to be rebooted. The description of each group policy
indicates whether the policy can be applied “dynamically” at the next refresh interval or requires a re-login or a reboot.
You may also update group policies manually by running the adgpupdate command on an individual computer. See the next section, Updating
Configuration Policies Manually.
Note: The system preference updated on an individual computer must be closed, then reopened for the group policy setting to be visible.
In most cases, group policies can be Enabled to activate the policy or Disabled to deactivate a previously enabled policy. Changing a policy to Not Configured
has no effect for any Mac group policies. Once a group policy is set on a local computer, it remains in effect even if the computer leaves the Active Directory
domain. The administrator or users with an administrative account can change settings manually at the local computer, but any manual changes are
overwritten when the group policy is applied.
Although there are Windows group policy settings that control whether group policies should be refreshed in the background at a set interval, Delinea also
provides a command line program to manually refresh group policy settings at any time. This command line program, adgpupdate, forces the adclient daemon to
contact Active Directory and collect group policy settings. With the adgpupdate command, you can specify whether you want to refresh computer configuration
policies, user configuration policies, or both.
When you run the adgpupdate command, the adclient daemon does the following:
Contacts Active Directory for computer configuration policies, user configuration policies, or both. By default, adclient collects both computer and user
configuration policies.
Determines all of the configuration settings that apply to the computer, the current user, or both, and retrieves those settings from the System Volume
(SYSVOL).
Starts the runmappers program to initiate the mapping of configuration settings using individual mapping programs for user and computer policies.
Resets the clock for the next refresh interval.
For more information about using the adgpupdate command, see the adgpupdate page or Using adgpupdate in the Administrator’s Guide for Linux and UNIX.
Applying Standard Windows Policies to Mac OS X
Every Group Policy Object includes several default Windows-based group policy categories and default Windows-based administrative templates for user
and computer configuration. Most of the settings in the default Windows policies and administrative templates only apply to Windows computers and
Windows user accounts. However, some of the common Windows configuration settings for password enforcement, such as the policies for minimum
password length and complexity, do apply to Mac computers. If these settings are enabled for a Group Policy Object applied to a site, domain, or OU that
includes Mac OS X computers, the settings are enforced for Mac users and computers.
The following sections describe the standard Windows group policies that you can apply to Mac computers and users and where you can find these policies
when viewing a Group Policy Object in the Group Policy Management Editor.
Group Policy Refresh and Loopback Processing
The Computer Configuration > Administrative Templates > System > Group Policy object contains the following policies that you can use to
control how group policies are refreshed and applied.
Turn off background refresh of Group Policy

Group Policy refresh interval for computers
User Group Policy loopback processing mode
Synchronizing Time
By default, the local Network Time Protocol (NTP) Client is enabled and synchronizes your computer’s clock to the Domain Controller. If you do not want your
local NTP service to synchronize to the NTP service on the Domain Controller, explicitly disable the (Windows) Enable Windows NTP Client group policy. You
can also synchronize to a different NTP server by specifying one in the Configure Windows NTP Client group policy.
To set these policies, in the Group Policy Editor, click Computer Configuration > Administrative Templates > System > Windows Time Service
> Time Providers. The following policies are available to control time synchronization settings.
Enable Windows NTP Client

Configure Windows NTP Client
Specifying Time Sync Polling Interval
The Computer Configuration > Administrative Templates > System > Windows Time Service > Global Configuration Settings policy
allows you to control the max polling interval with the MaxPollInterval option.
Configure Interactive Log On
Select the Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options object to configure the
following policies related to interactive log on.
Note: These policies apply to SSH login only, not to login through the graphical user interface.
Interactive logon: Message text for users attempting to log on

Interactive logon: Prompt user to change password before expiration
Set Password Requirements
Select the Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy object to set password
requirements.
Enforce password history

Maximum password age
Minimum password age
Minimum password length
Password must meet complexity requirements
Store passwords using reversible encryption
Configuring Mac-specific Parameters
Most configuration parameters apply to both Mac or only to actual UNIX or Linux systems. All these parameters are described in the Configuration and Tuning
Reference Guide. However, the following parameters apply only to Mac OS X and are described in this section.
adclient.autoedit.mac.netlogin
adclient.mac.map.home.to.users
adclient.network.wait.max
mac.auto.generate.new.login.keychain
mac.protected.keychain.enable
mac.protected.keychain.user.default
mac.protected.keychain.delete
mac.protected.keychain.lock.inactivity
mac.protected.keychain.lock.when.sleeping
mac.keychain.sync.enabled
mac.keychain.sync.polling.interval
smartcard.pin.caching.disable
logger.login.log
adclient.autoedit.mac.netlogin
System Preferences > Users & Groups (Accounts) has a login option: Allow network users to log in at login window:
If this option is deselected, Active Directory users will not be able to log into the computer. The configuration parameter adclient.autoedit.mac.netlogin controls
whether this option can be deselected by users. By default, the parameter is true in the /etc/centrifydc/centrifydc.conf file:
adclient.autoedit.mac.netlogin: true
In this case, even if a user deselects the box, the box is selected again when adclient is restarted, effectively preventing a user from deactivating network login.
If you want to allow a user to deactivate network login, set the parameter to false. If a user deselects network login in System Preferences > Accounts, the
next time adclient starts, network users will be unable to log in to the computer.
adclient.mac.map.home.to.users
On some versions of Mac OS X, /home is an automount point. If a zone user’s home directory is set to /home/username, the operating system cannot create the
home directory and the user cannot log in. Therefore, you should not specify /home/username as the home directory for any Mac OS X users, but since this is a
typical UNIX home directory, there may be Active Directory users who have a /home/username home directory.
To avoid potential problems, you can configure Delinea to change /home/username to /Users/username (the default Mac OS X home directory), in one of two ways:
Enable the group policy, Map /home to /Users.
Set the parameter, adclient.mac.map.home.to.users to true to enable the change for the local computer only; for example:
adclient.mac.map.home.to.users:true
adclient.network.wait.max
The Delinea agent for Mac OS X performs network checks during startup to determine whether the device is connected to the domain. The
adclient.network.wait.max parameter sets the maximum time the agent waits for the network before deciding to boot in either connected or disconnected mode.
The default value is five seconds.
If DNS latency is high in your environment, the agent might determine that the device is in a Disconnected state too soon.
You can increase the value for the adclient.network.wait.max parameter if it’s appropriate for your network environment; however, this might result in increased
boot times.
logger.login.log
Login events are captured in /var/log/centrifydc-login.log by default. You can turn off this feature by setting the logger.login.log parameter to off. Refer to Collecting
Information Specific to Login Events for more information about /var/log/centrifydc-login.
mac.auto.generate.new.login.keychain
Use this parameter to automatically generate a new login keychain if a user’s keychain password does not match the password they used to successfully
login.
Refer to Auto Generate New Login Keychain for more information about the group policy that controls this parameter.
mac.protected.keychain.enable
Setting this parameter to true creates a new keychain protected by either an asymmetric token stored on a smart card or by a password, depending on the log
in type.
Refer to Enable Protected Keychain for more information about the group policy that controls this parameter.
Note: Changing the group policy setting for this parameter does not change the parameter's value in this file. The two are set independently, with
the group policy setting taking priority.
mac.protected.keychain.user.default
Setting this parameter to true sets the protected keychain as the default keychain for that user.
Refer to Enable Protected Keychain for more information about the group policy setting that controls this parameter.
mac.protected.keychain.delete
Setting this parameter to true deletes the existing password-protected Login Keychain after logging in.
Note: This parameter only works if mac.protected.keychain.enable is set to true.
Refer to Enable Protected Keychain for more information about the group policy setting that controls this parameter.
mac.protected.keychain.lock.inactivity
Use this parameter to set the period of inactivity in minutes to automatically lock the protected keychain.
The default value is 0, which means the protected keychain is never automatically locked.
Refer to Lock Protected Keychain after Number of Minutes of Inactivity for more information about the group policy that controls this parameter.
mac.protected.keychain.lock.when.sleeping
Setting this parameter to true locks the protected keychain when the Mac sleeps.
Refer to Lock Protected Keychain When Sleeping for more information about the group policy that controls this parameter.
mac.keychain.sync.enabled
This configuration parameter enables Keychain synchronization for the users on a mac.
If this parameter is enabled, the current login user will receive a password change notification when his/her password is changed remotely. When the user
clicks on the notification, the Delinea Keychain Sync utility appears and allows the user to synchronize the Keychain password.
Note: Password changes can only be detected when the machine is in connected mode.
Refer to Enable Keychain Synchronization for more information about the related group policy.
mac.keychain.sync.polling.interval
This configuration parameter sets the password change detection interval when mac.keychain.sync.enabled is enabled.
This parameter determines the time (in minutes) between checking for changed passwords. There is a random zero to five minute variance in the actual
interval each device is checked for a changed password to maintain performance. As a result, the minimum interval is five minutes.
Note: Valid intervals are between 5 minutes and 1440 minutes (1 day).
Refer to Enable Keychain Synchronization for more information about the related group policy.
Setting Computer-Based Group Policies
computers and to users who log on to Mac computers. This chapter provides reference information for the Centrify Mac group policies that can be applied
specifically to Mac computers
The computer-based group policies are defined in the Centrify Mac administrative template (centrify_mac_settings.xml) and accessed from Computer
Configuration > Policies > Centrify Settings > Mac OS X Settings. See Understanding Group Policies for Mac Users and Computers for general
information about how Delinea uses group policies to manage Mac settings and for information on how to install the group policy administrative templates.
For reference information about user-based policies, see Setting User-based Group Policies.
For information, see Applying Standard Windows Policies to Mac OS X and Configuring Mac-specific Parameters.
Note: For more complete information about creating and using group policies and Group Policy Objects, see your Windows or Active Directory
documentation. For more information about adding and using other Centrify group policies that are not specific to Mac computers and users, see
the Group Policy Guide
Setting Computer-Based Policies for Mac
The following table provides a summary of the group policies you can set for Mac computers. These group policies are in the Centrify Mac administrative
template (centrify_mac_settings.xml) and accessed from Computer Configuration > Policies > Centrify Settings > Mac OS X Settings.
Allow Certificates with No For smart card log in, allow the use of certificates that do not contain the extended key usage (EKU) attribute. This is a
Extended Key Usage Windows policy that is defined in the Administrative Templates > Windows Components > Smart Card folder
Certificate Attribute using an adm template.
Map the /home/username directory to /Users/username. This is a Mac OS X-specific policy but defined in the Direct
Map /home to /Users
Control Settings > Adclient Settings folder using the centrifydc_settings.xml template.
Create login and system profiles for wireless authentication. These group policies correspond to 802.1X Options in the
802.1x Settings
Networks system preference.
Control the look and operation of the login window on Mac computers and map zone groups to the local administrator
Accounts
group. These group policies correspond to Login Options in the Accounts system preference.
App Store Settings Control the users and groups who can access the App Store. These group policies correspond to settings in the Sleep and
Deprecated Options panes in the Energy Saver system preference.
Custom Settings Customize and install configuration profiles.
Control sleep and wake-up option on Mac computers. These group policies correspond to settings in the Sleep and Options
Energy Saver
panes in the Energy Saver system preference.
Control the firewall configuration on Mac computers. These group policies correspond to settings in the Firewall pane of
Firewall
the Sharing system preference.
Manage Internet connections on Mac computers. These group policies correspond to settings in the Internet pane of the
Internet Sharing
Sharing system preference.
Control DNS searching and proxy settings. These group policies correspond to settings in the TCP/IP and Proxies panes of
Network
the Network system preference.
Control Apple Remote Desktop access for zone users. These group policies correspond to the Manage > Change
Remote Management
Client Settings options in Apple Remote Desktop.
Control security settings on Mac computers. These group policies correspond to settings in the Security system
Security & Privacy
preferences.
Control access to various services on Mac computers. These group policies correspond to settings in the Services pane of
Services
the Sharing system preference.
Control the options for automatic software updates on Mac computers. These group policies correspond to settings in the
Software Update Settings
Software Update system preference.
For information about specific policies and how to set them, see the policy description (Explain text) or the corresponding discussion of the specific system
preference or individual setting in the Mac Help.
Allow Certificates with no Extended Key Usage Certificate Attribute
Path
Computer Configuration > Policies > Administrative Templates: Policy Definitions> Windows Components> Smart Card.
Description
The group policy, “Allow certificates with no extended key usage certificate attribute” is defined in a Windows administrative template file (.adm), not in
centrify_mac_settings.xml, and is in Administrative Templates, not in Mac Settings.
To enable or disable this policy, click Computer Configuration > Policies > Administrative Templates: Policy Definitions > Windows
Components > Smart Card.
Enabling this policy setting allows the use of certificates for smart card login that do not have the Extended Key Usage (EKU) attribute set. Normally,
certificates that are used for smart card login require this attribute with a smart card logon object identifier.
When you enable this policy, it sets the smartcard.allow.noeku parameter to true in the Centrify configuration file. Certificates with the following attributes can
also be used to log on with a smart card:

If you disable or do not configure this policy setting (and do not set the smartcard.allow.noeku parameter to true in the Centrify configuration file) only certificates
that contain the smart card logon object identifier can be used with smart card log in.
After changing the value of this parameter, you must re-enable smart card support by running the following sctool command as root:
[root]$ sctool -E
Note: You must also specify the --altpkinit or --pkinit parameter when you run sctool with the -E option.
Map /home to /Users
Path
Computer Configuration > Policies > Centrify Settings > DirectControl Settings > Adclient Settings.
Description
The Mac group policy, Map /home to /Users is defined in the centrifydc_settings.xml file, not in centrify_mac_settings.xml, and is in Delinea Settings, not in Mac
Settings.
To enable or disable this policy, click Computer Configuration > Policies > Centrify Settings > DirectControl Settings > Adclient Settings.
On some versions of Mac OS X, /home is an automount point. If a zone user’s home directory is set to /home/username, the operating system cannot create
the home directory and the user cannot log in. Therefore, you should not specify /home/username as the home directory for any Mac users, but since this is a
typical UNIX home directory, there may be Active Directory users who have a /home/username home directory. To avoid potential problems, enable this
group policy, Map /home to /Users, to configure Delinea to change /home/username to /Users/username (the default Mac home directory). If you do not
enable this policy, the change does not take effect.
This policy modifies the adclient.mac.map.home.to.users parameter in the Centrify configuration file.
802.1X Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Settings to create profiles for wireless network
authentication. The profiles you specify with these group policies are created in the Network system preferences pane.
Enable Machine Ethernet Profile
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings > Enable Machine Ethernet Profile
Description
Enable this policy to create an 802.1X ethernet profile so users can authenticate to an 802.1X-protected network by using the specified machine certificate.
Note: This group policy only supports macOS 10.15 and lower.
This policy supports the TLS protocol for certificate-based authentication for computers.
Before you can enable this policy, you must have a Windows server configured for 802.1X wireless authentication. The configuration includes certificate
templates that are configured for auto-enrollment of domain computers and automatically downloaded to Mac computers when they join the domain. See
Configuring 802.1X Wireless Authentication for details about what you must configure before enabling the current policy.
After enabling this policy, set the following:
Template Name: Type the name of the auto-enrollment machine certificate that has been pushed down from the Windows domain server.
When pushed to a Mac computer, certificate names are prepended with auto_; for example:
auth_Centrify-1X
This group policy runs a script that looks for the specified certificate template in the /var/centrify/net/certs directory (which contains the certificate templates
pushed down from the domain controller) and creates an Ethernet profile from this certificate.
Once enabled, this policy takes effect dynamically at the next group policy refresh interval.
Enable Machine Wi-Fi Profile
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings Enable Machine Wi-Fi Profile
Description
Enable this policy to create an 802.1X Wi-Fi profile for wireless network authentication for a computer.
This policy supports WEP or WPA/WPA2 security with the TLS protocol for certificate-based authentication for computers.
SSID: Type the SSID for the wireless network.
Template Name: Type the name of the auto-enrollment machine certificate that has been pushed down from the Windows domain server.
When pushed to a Mac computer, certificate names are prepended with auto_; for example: auth_Centrify-1X
This group policy runs a script that looks for the specified certificate template in the /var/centrify/net/certs directory (which contains the certificate
templates downloaded from the domain controller) and creates a WiFi profile from this certificate.
Security Type: Select the security type from the drop-down list.
Other options: Select one or more of the following options:
Auto join: Select this option to specify that the computer automatically join a Wi-Fi network that it recognizes. Do not select this option to
specify that the logged in user must manually join a Wi-Fi network.
Hidden network: Select this option if the Wi-Fi network does not broadcast its SSID.
Proxy PAC URL: The URL of the PAC file that defines the proxy configuration. You can enter any string without spaces.
Proxy PAC Fallback: Allows the device to connect directly to the destination if the PAC file is unreachable. This option is disabled by default.
Enable User Ethernet Profile
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings > Enable User Ethernet Profile
Description
Enable this policy to create an 802.1X ethernet profile so users can authenticate to an 802.1X-protected network by using the specified user certificate.
This policy supports the TLS protocol for certificate-based authentication for users.
By default, the auto-enrolled user certificates are pushed down to ~/.centrify/autouser_(name).{cert.key.chain}. Certificates are also imported into each user’s login
keychain.
Users must perform these steps after login to authenticate to the network as the user:
1. Select System Preferences > Network > Ethernet.

2. If there are any pre-existing 802.1X connections, click Disconnect to disconnect the pre-existing connections. For example, if a machine 802.1X
Ethernet policy has been set, the computer will already be authenticated using the machine credential.
3. Click Connect. This action prompts the user with a list of available user identities in certificate-key pair format.
4. Choose the appropriate auto-enrolled user identity.
Enable User Wi-Fi Profile
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings > Enable User Wi-Fi Profile
Description
Enable this policy to create an 802.1X Wi-Fi profile for wireless network authentication for a user.
This policy supports the TLS protocol for certificate-based authentication for users.
By default, the auto-enrolled user certificates are pushed down to ~/.centrify/autouser_(name).{cert.key.chain}. Certificates are also imported into each user’s login
keychain.
The resulting profile is signed using the first available auto-enrolled machine certificates, which are under /var/centrify/net/certs/auto_(name).{cert.key.chain}. If an
auto-enrolled machine certificate is not available, the profile will be unsigned.
SSID: Type the SSID for the wireless network.

Security Type: Select the security type from the drop-down list.
Other options: Select one or more of the following options:
Auto join: Select this option to specify that the computer automatically join a Wi-Fi network that it recognizes. Do not select this option to
specify that the logged in user must manually join a Wi-Fi network.
Hidden network: Select this option if the Wi-Fi network does not broadcast its SSID.
Proxy PAC URL: The URL of the PAC file that defines the proxy configuration. You can enter any string without spaces.
Proxy PAC Fallback: Allows the device to connect directly to the destination if the PAC file is unreachable. This option is disabled by default.
Users must perform these steps after login to authenticate to the network as the user:
1. Select System Preferences > Network > Wi-Fi.

2. If there are any pre-existing 802.1X connections, click Disconnect to disconnect the pre-existing connections. For example, if a machine 802.1X
Ethernet policy has been set, the computer will already be authenticated using the machine credential.
3. Click Connect. This action prompts the user with a list of available user identities in certificate-key pair format.
4. Choose the appropriate auto-enrolled user identity (a certificate-key pair).
Specify System Profile (Deprecated)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings > Specify System Profile (Deprecated)
Description
This group policy is provided for backward compatibility with Mac OS X 10.6. If your environment does not contain any 10.6 computers, do not use this group
policy.
Enable this policy to specify 802.1X system profile for wireless network authentication.
System profile can establish a wireless connection without a user login.
To add a system profile, enable the policy and click A d d to enter the profile name and setting, then type a name for the profile.
The setting must follow this format:
Network;Security Type;Authentication Method, where each field is separated by a semi-colon (;)

Network is the wireless network name
Security type is one of 802.1X WEP, WPA Enterprise, WPA2 Enterprise
Authentication method is one or more of the following, separated by commas: TTLS, PEAP, LEAP, MD5
For example:
OFFICE1;WPA Enterprise;PEAP
OFFICE2;802.1X WEP;TTLS,PEAP
Automatically turn on Airport; to automatically turn on AirPort device if this type of profile is specified. Otherwise, the status of the AirPort device will
not change.
Accounts
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts settings to manage the options from the
Accounts ( ) system preference on Mac computers. These group policies correspond to the options displayed when you select the Accounts system
preference, then click Login Options. For example:
Set Login Window Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts > Set login window settings
Description
Configure the Login Options on a computer. If you enable this policy, you can configure the Login Window to:
Display a text string as a login banner. The Banner you specify is displayed when the user is prompted to log on.
Display a List of Users or a Name and Password field. Displaying the Name and Password requires users to provide their account name and password,
and is more secure than displaying a list of user names.
Show the Restart, Sleep, and Shut Down buttons.
Show the Input menu in the login window to allow users to change the current Keyboard Layout.
Show password hints in the login window.
Use VoiceOver at the login window.
Enable fast user switching.
Display the HostName, IP Address, and OS X or macOS Version. Users need to click the clock in the top right corner to view each field.
Disable reopening applications when logging back in. Check this to always uncheck the Reopen Windows when logging back in checkbox at
logout, restart, or shutdown.
Hide all Local Users with a UID less than 500.
Enabling the options in this group policy is the same as clicking Login Options in the Accounts system preference and setting the corresponding login
window options.
Note: This policy does not impact lock screens. It only impacts the login window.
Note: If you click Enable Fast User Switching, this setting does not take effect until the Login Options in the Accounts system
preference is opened manually by a user on the local host. This step is required to display the list of users in the upper-right corner of the
menu bar. After users log on, the user's full name, short name, or icon identifier is displayed in the menu bar. If you want to change how users
are displayed in the menu, you also must do so manually from the Login Options in the Accounts system preference.
Once enabled, this group policy takes effect when users log out and log back in or when the computer is rebooted.
Map Zone Groups to Local Admin Group
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone group to local admin group
Description
Specify one or more zone groups to map to the admin group on the local computer. Members of the groups you specify here have administrative privileges on
the local computer, including:
The use of sudo command in a shell

The ability to unlock and make changes to System Preferences.
Be certain to create a zone group in Access Manager (or adedit) and add users who you want to have administrative privileges on managed Mac computers.
Note: If the local computer is connected to the domain through Auto Zone, you cannot create a zone group because there are no zones. However,
all Active Directory groups are valid for the joined computer, so you can map any group to the local admin group, but you need to know the group’s
UNIX name, which you can retrieve on the local computer by using the adquery command, as shown in the following example.
To set this policy
1. Open the policy and select Enabled.

2. Click A d d.
3. Enter the name of a zone group in the box (or the UNIX group name if connected through Auto Zone). Then click O K.
Map Zone Groups to Local Group
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Accounts > Map zone group to local group
Description
Specify one or more zone groups to map to a Mac local group on the local computer. Members of the zone groups you specify here will be given the privileges
of the local group on the local computer; for example:
If you map to the _lpadmin and _lpoperator local groups, members of the zone group can manage printer settings on the local computer.
If you map to the admin local group, members of the zone group obtain administrator privileges on the local computer.
Note: To obtain administrator privileges for a zone group, you can either map to the local admin group with this policy, or use the Map zone
groups to local admin group policy. However, do not do both as the results are unpredictable.
Be certain to create a zone group in Access Manager (or adedit) and add users who you want to have administrative privileges on managed Mac computers.
Note: If the local computers is connected to the domain through Auto Zone, you cannot create a zone group because there are no zones.
However, all Active Directory groups are valid for the joined computer, so you can map any group to the local admin group, but you need to know
the group’s UNIX name, which you can retrieve on the local computer, by using the adquery command, as follows
To set this policy
1. Open the policy and select Enabled.
2. Click A d d.
3. Enter the name of a local group and of a zone group in the respective boxes (or the UNIX group name if connected through Auto Zone), then click O K.
You can repeat this step multiple times to map the zone group to more than one local group.
App Store Settings Deprecated
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > App Store Settings (Deprecated)
Description
Note: This policy has been deprecated and is no longer supported. Enabling it will have no effect. It is provided simply to allow you to disable the
policy if it was set in an earlier version of the product. You can use the Application Access Settings (deprecated) group policies to control
access to the App Store if you wish.
Prohibit Access to the App Store (Deprecated)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > App Store Settings (Deprecated) > Prohibit Access to the App Store
(Deprecated)
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > App Store > Prohibit Access to App Store group
policy to control access to the App Store.
By default, all users can access the App Store. Enable this group policy to prohibit access to App Store to all users except the root user and those you
specifically authorize with the options, Allow these users to access App store, and Allow these groups to access App Store.
You can set the following options with this policy:
Allow these users to The names of local or AD users who are allowed to access the App Store. When this policy is enabled, only users on this list and
access App Store the root user are allowed to access the App Store.
Allow these groups to The names of local or AD groups that are allowed to access the App Store. When this policy is enabled, only users in the
access App Store specified groups, and the root user, are allowed to access the App Store.
This policy can take effect dynamically at the next group policy refresh interval without rebooting the computer.
Custom Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings group policy settings to customize
and install configuration profiles. The “Install MobileConfig Profiles” policy installs a device profile. To install a user profile, use the same policy in User
Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings.
Enable Profile Custom Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Enable profile custom settings
Description
Enable this group policy to use the Custom payload to specify preference settings for applications that use the standard plist format for their preference files.
You can use this GP to add specific keys and values to an existing preferences plist file. However, not all applications work with managed preferences, and in
some cases only specific settings can be managed.
By default, you should place the plist files with preference settings in the folder \\domain\SYSVOL\<domain>\customsettings.
To add a file, click A d d and enter name of a file that you placed in the SYSVOL location. The file you specify is relative to this path:
\\domain\SYSVOL\domain\customsettings
For example, if you enter:
com.apple.plist
the file that is imported is:
\\domain\SYSVOL\domain\customsettings\com.apple.plist
Install MobileConfig Profiles
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig Profiles
Description
Enable this group policy to install mobile configuration profiles on managed Mac computers.
Note: There is a Computer Configuration version of this policy (which installs device profiles) and a User Configuration version (which installs
user profiles).
Before enabling this policy, you must create a directory and copy mobile configuration files to SYSVOL on the domain controller. SYSVOL is a well-known
shared directory on the domain computer that stores server copies of public files that must be shared throughout the domain.
Specifically, create the following directory on the domain controller:
\\domainName\SYSVOL\domainName\mobileconfig
and copy one or more mobile configuration profile files to this directory. See Deploy Configuration Profiles to Multiple Computers for details on how to do this.
To specify mobile configuration files to install, enable the policy, then click A d d. Enter the name of a mobile configuration file that you placed in SYSVOL on
the domain controller. Include the .mobileconfig suffix with the name.
If you specify a file that is not in the SYSVOL mobileconfig directory, the profile will not be installed.
If you add new files to the existing list in the group policy, those profiles will be installed — existing profiles will not be touched. If you remove previously
specified files, the profiles defined by these files will be uninstalled.
If you add two or more profile files that have the same payloadIdentifier, only one of them will be installed.
If you change the group policy to “Disabled” or “Not Configured”, all existing profiles that were installed previously by the group policy will now be uninstalled
from the managed Mac computers.
Energy Saver
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver settings to manage sleep and wake-up
options from the Energy Saver ( ) system preference on Mac computers. For example:
You can configure power options or schedule startup and shutdown times.
Open the appropriate folder to set power options when running on AC power or battery power. Each folder has the identical set of group policies:
On AC power
On battery power
Allow Power Button to Sleep the Computer
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Allow power button to sleep the computer
Description
Allow the power button to sleep the computer.
Enabling this group policy is the same as selecting the Allow power button to sleep the computer option in the Options pane of Energy Saver system
preference.
This policy can take effect dynamically at the next group policy refresh interval.
Put The Hard Disk(s) to Sleep When Possible
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Put the hard disk(s) to sleep when possible
Description
Put computer hard disks to sleep when they are inactive.
Enabling this group policy is the same as selecting the Put the hard disk(s) to sleep when possible option in the Sleep pane of Energy Saver system
preference.
Restart Automatically After a Power Failure
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Restart automatically after a power failure
Description
Enable to set the computer to automatically restart after a power failure.
Enabling this group policy is the same as selecting the Restart automatically after a power failure option in the Options pane of Energy Saver system
preference.
Set Computer Sleep Time
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Set computer sleep time
Description
Specify the number of minutes of inactivity to allow before automatically putting a computer into the sleep mode.
If you enable this group policy, the period of inactivity you specify applies only when the computer is using its power adapter. If the computer is inactive for the
number of minutes you specify, it is put in sleep mode.
Enabling this group policy is the same as selecting a time using the Put the computer to sleep when it is inactive for slider in the Sleep pane of Energy
Saver system preference.
To prevent the computer from ever going into sleep mode, enter 0 for the number of minutes, or disable the policy.
Set Display Sleep Time
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Set display sleep time
Description
Specify the number of minutes of inactivity to allow before automatically putting the display into the sleep mode.
If you enable this group policy, the period of inactivity you specify applies when the computer is using its power adapter. If the computer is inactive for the
number of minutes you specify, the display is put in sleep mode.
Enabling this group policy is the same as selecting a time using the Put the display to sleep when it is inactive for slider in the Sleep pane of Energy
Saver system preference.
To prevent the display from ever going into sleep mode, enter 0 for the number of minutes, or disable the policy.
Wake When the Modem Detects a Ring
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Wake when the modem detects a ring
Description
Automatically take a computer out of sleep mode when the modem detects a ring. This group policy allows a computer that has been put to sleep to remain
available to answer the modem.
Wake for Ethernet network administrator access
Automatically take a computer out of sleep mode when the computer receives a Wake-on-LAN packet from an administrator. This group policy allows a
computer that has been put to sleep to remain available to network administrator access.
Enabling this group policy is the same as selecting the Wake for Ethernet network administrator access option in the Options pane of Energy Saver
system preference.
Scheduled Events
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Scheduled events
Description
To configure sleep/shutdown times and startup times, open the Scheduled events folder (Computer Configuration Policies > Centrify Settings >
Mac OS X Settings > EnergySaver > Scheduled events).
Set Machine Sleep/Shutdown Time
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Scheduled events > Set machine sleep/shutdown time
Description
Specify a time to shut down or put the computer to sleep.
Enabling this group policy is the same as selecting the Schedule button in the Energy Saver system preference, then specifying times and days to shut down
or put the computer to sleep.
After enabling this policy, specify values for the following:
Action: Select sleep or shutdown

Set machine sleep/shutdown time: Enter a time in the format HH:mm using a 24 hour clock; for example, to shut down or put the computer to
sleep at 10:05 P.M:
22:05
Sleep/shutdown machine on every: Select the days of the week on which to shut down or sleep the computer at the specified time. All days are
selected by default.
Set Machine Startup Time
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Energy Saver > Scheduled events > Set machine startup time
Description
Specify a time to start up the computer.
Enabling this group policy is the same as selecting the Schedule button in the Energy Saver system preference, then specifying times and days to start up
the computer.
After enabling this policy, specify values for the following:
Set machine startup time: Enter a time in the format HH:mm using a 24 hour clock; for example, to start up the computer at 7:55 A.M.:
07:55
Start machine on every: Select the days of the week on which to start the computer at the specified time. All days are selected by default.
Firewall
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall settings to manage the firewall options on Mac
computers.
Enabling the Centrify firewall group policies is the same as setting options from System Preferences > Security > Firewall.
Note: With the Centrify Firewall Group Policies, you can allow all incoming connections, or limit connections to the specified services and
applications. You cannot block all connections:
In addition, group policies are available for the Advanced firewall settings, Enable Firewall Logging, and Enable Stealth Mode.
Enable Firewall
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Enable firewall
Description
Prevent incoming network communication to all services and ports other than those explicitly enabled for the services specified in the Services pane of the
Sharing system preferences.
This group policy turns on default firewall protection.
Block all incoming connections:
Block all incoming connections except those required for basic Internet services, such as DHCP, Bonjour, and IPSec.
Automatically allow signed software to receive incoming connections:
Allows software signed by a valid certificate authority to provide services accessed from the network. This setting will not take effect if Block all
incoming connections is selected.
This policy takes effect dynamically at the next group policy refresh interval without rebooting the computer.
Enable iChat
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Enable iChat
Description
On Mac OS X Servers, enabling this policy has no effect. If the firewall is enabled, the iChat service is not allowed through the firewall.
If the firewall is enabled, enabling this group policy is the same as clicking the O n checkbox to allow communication through the firewall for iChat Bonjour. If
you do not enable this group policy, traffic for iChat Bonjour will be blocked from the local computer.
Enable iPhoto Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Enable iPhoto Sharing
Description
On Mac OS X Servers, enabling this policy has no effect. If the firewall is enabled, the iPhoto Sharing service is not allowed through the firewall.
If the firewall is enabled, enabling this group policy is the same as clicking the O n checkbox to allow communication through the firewall for iPhoto Bonjour
Sharing. If you do not enable this group policy, traffic for iPhoto Bonjour Sharing will be blocked from the local computer. Users will be able to access iPhoto
collections on other computers, but the local computer cannot be used to serve any iPhoto collections.
Enable iTunes Music Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Enable iTunes Music Sharing
Description
Enabling this group policy is the same as clicking the O n checkbox to allow communication through the firewall for iTunes Music Sharing.
On Mac OS X Servers, enabling this policy has no effect. If the firewall is enabled, the iTunes Music Sharing service is not allowed through the firewall.
If you do not enable this group policy, traffic for iTunes Music Sharing will be blocked from the local computer. Users will be able to access iTunes collections
on other computers, but the local computer cannot be used to serve any iTunes collections.
Enable Network Time
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Enable network time
Description
On Mac OS X Servers, enabling this policy has no effect. If the firewall is enabled, the Network Time service is not allowed through the firewall.
If the firewall is enabled, enabling this group policy is the same as clicking the O n checkbox to allow communication through the firewall for Network Time. If
you do not enable this group policy, traffic from the Network Time service will be blocked.
Block UDP Traffic
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Block UDP traffic
Description
Enabling this group policy is the same as clicking the Block UDP Traffic checkbox in the Advanced firewall settings.
This group policy does not block UDP communications that are related to requests initiated on the local computer.
Enable Firewall Logging
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Firewall > Enable firewall logging
Description
Log information about firewall activity, including all of the sources, destinations, and access attempts that are blocked by the firewall. The activity is
recorded in the secure.log file on the local computer.
Enabling this group policy is the same as clicking the System Preferences > Security > Firewall then clicking Enable Firewall Logging in the
Advanced firewall settings.
On Mac OS X Servers, enabling this policy has no effect.
Enable Stealth Mode
Prevent uninvited traffic from receiving a response from the local computer.
Enabling this group policy is the same as clicking the System Preferences > Security > Firewall then clicking Enable Stealth Mode in the Advanced
firewall settings.
If you enable this group policy, the local computer will not respond to any network requests, including ping requests. Because the computer will not reply to
ping requests, using this policy may prevent you from using network diagnostic tools that require a response from the local computer.
Internet Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Internet Sharing
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings >Internet Sharing group policy to prevent any kind of
Internet sharing on the local computer. This group policy can only be used to prevent Internet sharing. Although this group policy corresponds to a setting on
the Internet pane of the Sharing ( ) system preference, you can not use it to start Internet sharing, configure the shared connection, or set any other
options. For example:
Disallow All Internet Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Internet Sharing > Disallow all Internet Sharing
Description
Prevent any kind of Internet sharing on the local computer. Enabling this group policy is the same as clicking S t o p to prevent other computers from sharing
an Internet connection on a local computer in the Internet pane of the Sharing system preference.
For this group policy, clicking Disabled or Not Configured has no effect. If you have previously Enabled the group policy, Internet sharing will remain off until
you manually start it on the local computer.
Once enabled, this group policy takes effect when users log out and log back in, or dynamically at the next group policy refresh interval without rebooting the
computer.
Network
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network settings to manage DNS search requests and
proxy settings. These group policies correspond to settings in the TCP/IP and Proxies panes of the Network ( ) system preference on Mac computers. For
example:
Legacy Location Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings
Description
Use Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings to configure
network settings for the Automatic network location.
Adjust List of DNS servers
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Adjust list of DNS servers
Description
Control the list of DNS servers when performing DNS lookups.
To use this policy, click Enabled, then click A d d, type the IP address for a DNS server, then click O K to add the server to the list of DNS servers. Add as many
servers as you want in this manner. When you are finished adding the servers, click O K to close the dialog box.
At any time while the policy is enabled, you can select an address in the list and click Edit to change the address, or Remove to remove it as a DNS server.
Adjust List of Searched Domains
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Adjust list of searched domains
Description
Control the list of domains to search when performing DNS lookups.
To use this policy, click Enabled, then click A d d, type a domain name, then click O K to add the domain to the list of domains to search. Add as many domains
as you want in this manner. When you are finished adding the domains to search, click O K to close the dialog box.
At any time while the policy is enabled, you can select a domain in the list and click Edit to change the name, or Remove to remove it as a domain to be
searched.
Configure Proxies
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Configure Proxies
Description
Configure proxy servers to provide access to services through a firewall.
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Configure Proxies settings to manage
settings on the Proxies panes of the Network system preference. For example:
These group policies enable you to configure the host names (or IP addresses) and port numbers for the computers providing specific services, such as File
Transfer Protocol (ftp), Hypertext Transfer Protocol (http), and HTTP over Secure Sockets Layer (https), through a firewall. A proxy server is a computer on a
local network that acts as an intermediary between computer users and the Internet to ensure the security and administrative control of the network.
Enable Proxies
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Configure Proxies > Enable Proxies
Description
Configure the host name (or IP address) and port number for the computers providing specific services. Within this category, you can enable the following
proxy servers:
Use the Enable FTP Proxy policy to configure the host name and port number for the FTP proxy server (FTP protocol).
Use the Enable Web Proxy policy to configure the host name and port number for the Web proxy server (HTTP protocol).
Use the Enable Secure Web Proxy policy to configure the host name and port number for the Secure Web proxy server (HTTPS protocol).
Use the Enable Streaming Proxy policy to configure the host name and port number for the Streaming proxy server (RTSP protocol).
Use the Enable SOCKS Proxy policy to configure the host name and port number for the Streaming proxy server (SOCKS protocol).
Use the Enable Gopher Proxy policy to configure the host name and port number for the Gopher proxy server.
Use the Enable Streaming Proxy policy to configure the host name and port number for the Streaming proxy server (RTSP protocol).
Use the Enable Proxies using a PAC file policy to configure proxy servers from a proxy configuration file.
These policies can take effect dynamically at the next group policy refresh interval without rebooting the computer.
Exclude Simple Hostnames
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Configure Proxies > Exclude simple
hostnames
Description
Prevent requests to unqualified host names from using proxy servers. If you enable this policy, users can enter unqualified host names to contact servers
directly rather than through a proxy.
Use Passive FTP Mode (PASV)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Configure Proxies > Use Passive FTP
Mode (PASV)
Description
Use the FTP passive mode (PASV) to access Internet sites when computers are protected by a firewall.
Bypass Proxy Settings for these Hosts & Domains
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Legacy location settings > Configure Proxies > Bypass Proxy settings
for these Hosts & Domains
Description
Specify fully-qualified host names and domains for which you want to bypass proxy settings.
You should use this policy to define the hosts or domains that should never be contacted by proxy.
To use this policy, click Enabled, then click A d d, type a host or domain name, and click O K to add the entry to the Show Contents list.
Each host or domain should be listed as a separate line in the Hosts and Domains list. For each host or domain, click A d d, type the host or domain name, and
click O K to add the host or domain as a new entry in the list. When you are finished adding items to the list, click O K to close the policy dialog box.
Location 1 and Location 2
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 1
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 2
Description
Use Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 1 to configure network settings for an
additional network location. The group policies in Location 2 are identical, and allow you to configure network settings for another network location.
Adjust List of DNS Servers
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 1/Location 2 > Adjust list of DNS servers
Description
Control the list of DNS servers when performing DNS lookups.
To use this policy, click Enabled, then click A d d, type the IP address for a DNS server, then click O K to add the server to the list of DNS servers. Add as many
servers as you want in this manner. When you are finished adding the servers, click O K to close the dialog box.
At any time while the policy is enabled, you can select an address in the list and click Edit to change the address, or Remove to remove it as a DNS server.
Adjust List of Searched Domains
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 1/Location 2 > Adjust list of searched domains
Description
Control the list of domains to search when performing DNS lookups.
To use this policy, click Enabled, then click A d d, type a domain name, then click O K to add the domain to the list of domains to search. Add as many domains
as you want in this manner. When you are finished adding the domains to search, click O K to close the dialog box.
At any time while the policy is enabled, you can select a domain in the list and click Edit to change the name, or Remove to remove it as a domain to be
searched.
Enable Network Location
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 1/Location 2 > Enable network location
Description
Enable all network location settings under the current location category and set its location name. This policy must be enabled to apply settings in this
location category (for example, Location1).
Configure Proxies
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Network > Location 1/Location 2 > Configure Proxies
Description
Configure proxy servers to provide access to services through a firewall. The group policies in this folder are the same as the ones in Computer Configuration
> Policies > Centrify Settings > Mac OS X Settings > Network > Legacy Location settings> Configure Proxies. Refer to Configure Proxies for more information.
Remote Management
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Remote Management
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Remote Management settings to control Apple
Remote Desktop access for zone users. You can use these group policies to give Active Directory group members permission to remotely control Mac
computers without physically having to activate the Apple Remote Desktop on the remote Mac computer.
The Remote Management group policies correspond to the Manage > Change Client Settings options in Apple Remote Desktop and are similar to
access privileges defined on a client computer using the Sharing system preference. For example:
Note: Because the group policies correspond to the Manage > Change Client Settings options in Apple Remote Desktop, the group policy
settings are not displayed in the local system preference on the Mac client. Although the tasks you can assign to different groups by group policy
correspond to tasks you can assign using the local Sharing system preference on a Mac client computer, the group policy settings do not update
the local system preference to display check marks for the tasks that the remote users have been given permission to perform.
Enable Administrator Access Groups
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Remote Management > Enable administrator access groups
Description
Allow all users who are members of the following Apple Remote Desktop administrator groups to access this computer using Apple Remote Desktop.
Before enabling this group policy, you should create each Active Directory security group you intend to use and add a UNIX profile for each group to the zone,
using the exact UNIX group names (ard_admin, ard_reports, ard_manage, ard_interact).
Note: Creating UNIX profiles with these group names displays a warning message because the names are longer than eight characters. You can
safely ignore this warning message.
Enabling this policy allows users in the following groups to manage Mac computers through Apple Remote Desktop:
ard_admin gives all members of the group the ability to remotely control the computer desktop.
ard_reports gives all members of the group the ability to remotely generate reports on the computer.
ard_manage gives all members of the group the ability to manage the computer using Apple Remote Desktop. Users in this group can perform the following
tasks by using Apple Remote Desktop:
Generate reports
Open and quit applications
Change settings
Copy Items
Delete and replace items
Send text messages
Restart and shut down
ard_interact gives all members of the group the ability to interactively observe or control the computer using Apple Remote Desktop.
Users in this group can perform the following tasks by using Apple Remote Desktop:
Send text messages

Observe
Control
See Setting Up Local and Remote Administrative Privileges for information on how to use this group policy with the Map Zone Groups to Local Admin Group
policy to enable both local and remote administrative access for the same group of users.
Scripts (Login/Logout)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout)
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout) > Specify multiple login
scripts group policy to deploy login scripts that run when an Active Directory or local user logs on. When you use this group policy, the login scripts are stored
in the Active Directory domain’s system volume (sysvol) and transferred to the Mac computer when the group policies are applied. Login scripts are useful for
performing common tasks such as mounting and un-mounting shares
This policy is also available as a user policy. If you specify scripts using both the computer and user policies, the computer scripts are executed first.
Specify Multiple Login Scripts
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout) > Specify multiple login scripts
Description
Specify the names of one or more login scripts to execute when an AD or local user logs on. The scripts you specify run simultaneously in no particular order.
Before enabling this policy, you should create the scripts and copy them to the system volume (sysvol) on the domain controller. By default, the login scripts
are stored in the system volume (SYSVOL) on the domain controller in the directory:
\\domain\SYSVOL\domain\Scripts
\scriptname1
\scriptname2
...
After enabling this policy, click A d d and enter the following information:
Script: The name of the script and an optional path, which are relative to \\domain\SYSVOL\domain\scripts\
For example, if the domain name is ajax.org and you enter a script name of start.sh, the script that gets executed on the domain controller is:
\\ajax.org\SYSVOL\ajax.org\Scripts\mlogin.sh
You can specify additional relative directories in the path, if needed; for example, if you type submlogin.sh, the file that gets executed is:
\\ajax.org\SYSVOL\ajax.org\Scripts\sub\mlogin.sh
Parameters: An optional set of arguments to pass to the script. These arguments are interpreted the same way as in a UNIX shell; that is, space is a
delimiter, and backslash is an escape character. You can also use $USER to represent the current user's name. For example:
arg1 arg2 arg3

arg1 'a r g 2' arg3
Note: Be certain authenticated users have permission to read these files so the scripts can run when they log in.
Once this group policy is enabled, it takes effect when users log out and log back in.
Scripts (LaunchDaemons)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (launchDaemons)
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (LaunchDaemons) > Specify multiple
LaunchDaemon scripts group policy to deploy scripts that run when launchd starts (system boot up). When you use this group policy, the LaunchDaemon
scripts are stored in the Active Directory domain’s system volume (sysvol) and transferred to the Mac computer when the group policies are applied. Using
LaunchDaemons to run scripts allows you to run the scripts as root, where the Specify multiple login scripts group policy can only be run as the logged in
user.
Refer to the following Apple resources to learn more about Launch Daemons and Agents.
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
https://developer.apple.com/library/content/technotes/tn2083/_index.html#//apple_ref/doc/uid/DTS10003794
Specify Multiple LaunchDaemon Scripts
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (launchDaemons) > Specify multiple LaunchDaemon scripts
Description
Enable this group policy to specify multiple scripts to run automatically when launchd starts (system boot up).
The scripts you specify run simultaneously in no particular order.
Before enabling this policy, you should create the scripts and copy them to the system volume (sysvol) on the domain controller. By default, the
LaunchDaemon scripts are stored in the system volume (SYSVOL) on the domain controller in the directory:
\scriptname1
\scriptname2
...
Script: The name of the script and an optional path, which are relative to \\domain\SYSVOL\domain\scripts\.
For example, if the domain name is ajax.org and you enter a script name of startup.sh, the script that gets executed on the domain controller is:
\\ajax.org\SYSVOL\ajax.org\Scripts\startup.sh
\\ajax.org\SYSVOL\ajax.org\Scripts\sub\startup.sh
Parameters: An optional set of arguments to pass to the script. These arguments are interpreted the same way as in a UNIX shell; that is, space is a
delimiter, and backslash is an escape character. For example:
arg1 arg2 arg3

arg1 'a r g 2' arg3
Security & Privacy
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy
Description
Use the Centrify group policies found in Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy to
manage the Keychain, public and private keys, and the options from the Security & Privacy ( ) system preference on Mac OS X computers.
Auto Generate New Login Keychain
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Auto Generate New Login Keychain
Description
Use this policy to automatically generate a new login keychain if a user’s keychain password does not match the password they used to successfully login,
resulting in the message “the system was unable to unlock your login keychain”.
This commonly occurs if someone has changed their account password on another system.
If this policy is enabled, a new keychain will be generated when a password sync issue is discovered. This new keychain will be set as the default login
keychain and the previous keychain will be moved to a backup.
Delinea recommends disabling this policy if you plan to use Enable Keychain Synchronization.
This policy is disabled by default.
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Certificate validation method
Description
Specify the certificate validation method to use for the Mac computer.
Note: This group policy has no effect on the “Keychain Access > Preferences > Certificates” settings. Keychain Access > Preferences are per-
user settings, which are not used by a Mac computer during login. This group policy changes Centrify SmartCardTool > Revocation settings, which
represent the system settings used by a Mac computer during login.
This policy allows you to choose either one, or both of the two common methods for verifying the validity of a certificate:
Certificate Revocation List: Use a certificate revocation list (CRL) from a revocation server.
Online Certificate Status Protocol: Use an online certificate status protocol (OCSP) responder to validate certificates.
If you select this option, you can specify a local responder to override the one provided in the certificates.
For each validation option, you can select one of the following settings:
O f f: No revocation checking is performed.
Best attempt: The certificate passes unless the server returns an indication of a bad certificate.
This setting is recommended for most environments.
Require if cert indicates: If the URL to the revocation server is provided in the certificate, this setting requires a successful connection to a
revocation server as well as no indication of a bad certificate.
Specify this option only in a tightly controlled environment that guarantees the presence of a CRL server or OCSP responder. If a CRL server or OCSP
responder is not available, SSL and S/MIME evaluations could hang or fail.
Require for all certs: This setting requires successful validation of all certificates.
Use only in a tightly controlled environment that guarantees the presence of a CRL server or OCSP responder. If a CRL server or OCSP responder is not
available, SSL and S/MIME evaluations could hang or fail.
Local Responder: If you choose to validate the certificate via OCSP, you can specify a local responder to override that provided in the certificates.
Priority: The priority determines which method (OCSP or CRL) is attempted first.
If the first method chosen returns a successful validation, the second method is not attempted, unless you choose to require both.
Disable Automatic Login
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Disable automatic login
Description
Disable the automatic login setting. If you enable this group policy, it overrides the Login Options set in the General tab of the Security & Privacy system
preference.
For this group policy, clicking Disabled or Not Configured has no effect.
Once enabled, this group policy takes effect when the computer is rebooted.
Disable Location Services
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Disable Location Services
Description
Disable the “Enable Location Services” setting. If you enable this group policy, it overrides the Enable Location Services setting in the Privacy tab of the
Security & Privacy system preference.
Note: As of MacOS Catalina, it is not enough to wait for the next group policy refresh or execute adgpupdate. You also need to restart the Mac for
this GP to take effect.
For this group policy, clicking Disabled or Not Configured has no effect.
Once enabled, this group policy takes effect at the next group policy refresh interval.
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Enable smart card support
Description
Enable users to logon with smart cards. If you enable this group policy, it adds smart card support to the authorization database on Mac computers that are
linked to the group policy object.
Delinea smart card support for macOS is based on the macOS modern native framework, CryptoTokenKit
See Configuring a Mac Computer for Smart Card Login for details.
Select Enable smart card support for the SUDO command, then when executing the SUDO command, smart card user can authenticate identity by
smart card PIN.
Select Enable smart card support for the SU command, then when executing the SU command, smart card user can authenticate identity by smart
card PIN.
Select Enable smart card support for the LOGIN command, then when executing the LOGIN command, smart card user can authenticate identity by
smart card PIN.
Select Enforce smart card login, then only smart card users with a smart card can log in to the Mac machine.
Edit Exception group to add a exception group for the "Enforce smart card login", then any users belong to this group always can log in to the Mac machine
by a username and password. In general, we recommend set a exception group, for example, admin, when Enforce smart card login is selected.
Select one of options in Certificate trust behavior to set smart card certificate trust behavior, the meaning of number:
0: Smart card certificate trust isn’t required.
1: Smart card certificate and chain must be trusted.
2: Certificate and chain must be trusted and not receive a revoked status.
3: Certificate and chain must be trusted and revocation status is returned valid.
Enable FileVault 2
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Enable FileVault 2
Description
This group policy allows you to select whether to use one institutional key for multiple Mac computers, or computer-specific (“personal”) keys.
To use one institutional key for multiple Mac computers, select Use Institutional Recovery Key. Then click Select to select the certificate that contains
the FileVault master keychain that can unlock the encrypted disk. You must already have created a FileVault master keychain and exported the certificate for
the master keychain to a Windows domain server before you perform this step.
To use computer-specific (“personal”) keys instead of one institutional key, leave Use Institutional Recovery Key unchecked. In this situation, a
personal recovery key is created for the Mac computer and stored in the computer object in Active Directory. The key is created and sent to the computer
object in Active Directory after the “Managed By” user logs in, logs out, and provides the user password.
This policy is available only for OS X 10.9 and later.
For complete instructions, see Configuring Filevault 2.
Note: Enabling this group policy does not immediately enable FileVault 2 protection on a Mac computer. FileVault 2 protection is enabled when the
FileVault-enabled user (that is, the “Managed By” user) logs on to the computer. Disabling this group policy does not disable FileVault 2 protection
— disabling FileVault 2 can only be done manually.
Once enabled, this group policy takes effect at the next group policy update interval or when you execute the adgpupdate command.
Enable Gatekeeper
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Enable Gatekeeper
Description
Enable the Gatekeeper feature, which controls access to the Mac App store. This policy overrides the “Allow applications downloaded from” setting on the
General tab of the Security & Privacy system preference pane.
After enabling the policy, select one of the following options:
Mac App Store Only allow installation of applications that have been downloaded from the Mac App store.
Mac App Store and identified developers. Only allow installation of applications that have been downloaded from the Mac App Store or were created
by Apple-sanctioned developers.
Anywhere Allow installation of any applications.
Enable Keychain Synchronization
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Enable Keychain synchronization
Description
This group policy controls whether to enable keychain synchronization, which synchronizes the login keychain to the login user’s AD password when a
password change is detected.
Note: Keychain synchronization is password-focused and should not be used in smart card environments.
Set the Password change detection interval (minutes) option to determine the time (in minutes) between checking for changed passwords. There is
a random zero to five minute variance in the actual interval each device is checked for a changed password to maintain performance. As a result, the
minimum interval is five minutes.
The default value is 30 minutes.
The Store AD password in the login Keychain option is used to streamline updates of the user's login Keychain password. If this option is enabled the
Keychain Sync utility stores the user's AD password in the login keychain the next time the user logs in. If the password is changed after the policy is enabled
but before the previous password is stored in the login keychain, the keychain sync application requests the previous password.
When this option is selected, the user's AD password is encrypted using a static AES256 key that is unique to that user and stored in the login Keychain as an
application password. The key and password are added to the keychain using the SecItemAdd API. In addition, an Access Control List ensures that only the
Keychain Sync utility can access the key used to encrypt and decrypt the password.
Delinea recommends disabling Auto Generate New Login Keychain before enabling this policy
Please note the following limitations with the Store AD Password in the login Keychain option:
This option only works on macOS 10.12 or later.
The user’s AD password is inaccessible when the login keychain is locked.
The most common scenario that causes this is if a user’s AD password is changed and the user logs out before synchronizing the keychain, then logs
back in. When the user logs back in, the password check fails due to the new password, locking the login Keychain and preventing the Keychain Sync
utility from accessing it.
Password changes can only be detected when the machine is in connected mode.
User experience when the AD password is already stored in the login Keychain
1. The login user receives a password change notification when his/her password is changed remotely.
2. When the user clicks Yes on the notification, the Delinea Keychain Sync utility appears and asks for the current password to synchronize the keychain.
After entering the current password and clicking O K, the Keychain

Sync utility synchronizes the login keychain with the new password.
User experience when the AD password is not yet stored in the login Keychain
1. The login user receives a password change notification when his/her password is changed remotely.
2. When the user clicks Yes on the notification, the Delinea Keychain Sync utility appears and asks if the user remembers the previous password.
3. The user clicks Yes or N o.
If the user clicks N o, the Keychain Sync utility creates a new login keychain.
If the user clicks Yes, the Keychain Sync utility asks for the previous and current passwords.
After entering the previous and current passwords and clicking O K, the Keychain Sync utility synchronizes the login keychain with the new password.
Log Out After Number of Minutes of Inactivity
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Log out after number of minutes of inactivity
Description
Specify the number of minutes of inactivity to allow on a computer before automatically logging out the current user. The default value is 5 minutes.
Setting the value to less than 5 minutes disables automatic logout. If you plan to disable automatic logout, it is recommended that you set the value to 0 to
preserve backward compatibility.
Note: Disabling this policy does not disable automatic logout.
This policy takes effect when users log out and log back in after the next group policy refresh.
Require a Password to Wake this Computer from Sleep or Screen Saver
##P a t h
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Require a password to wake this computer from
sleep or screen saver
##Description
Lock the computer screen when the computer goes into sleep or screen saver mode and requires users to enter a user name and password to unlock the
screen.
Enabling this group policy is the same as clicking the Require a password to wake this computer from sleep or screen saver option in the Security system
preference.
After this group policy is enabled, it takes effect dynamically at the next group policy refresh interval.
Require Password to Unlock Each Secure System Preference
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Require password to unlock each secure system
preference
Description
Lock sensitive system preferences to prevent users who aren’t administrators from changing them. This group policy requires users to provide an
administrator’s password to unlock each secure system preference before they can make changes.
If you enable this policy, users must provide an administrator password to access any secure system preference. If the current user is logged on as an
administrator and this policy is not configured or disabled, the user can access and change secure system preferences without providing the administrator
password.
Use Secure Virtual Memory
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Use secure virtual memory
Description
Prevent passwords from being recoverable from virtual memory.
Any time a password is entered, it is possible for system to write that password in a block of memory that it dumps to a file in /var/vm, making the password
recoverable.
Enabling this group policy ensures that the virtual memory /var/vm files are encrypted, preventing any passwords written there from being recovered.
Allow All Applications to Access the Auto-Enrollment Private Key(S)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Allow all applications to access the
auto-enrollment private key(s)
Description
Enabling this policy allows all applications to access the auto-enrollment private key(s) in the System keychain.
See Configuring Auto-Enrollment for more information about auto-enrollment keys.
Note: This setting only applies to a new auto-enrollment private key(s); it will not update already imported auto-enrollment private key(s) that
are in the System keychain.
Allow Specific Applications to Access the Auto-Enrollment Private Key(S)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Allow specific applications to use the
Description
Enabling this policy allows specified applications to access the auto-enrollment private key(s) in System keychain.
After you enable this policy, click A d d to enter the path to the application you want to allow access to the auto-enrollment private key, then click O K. You can
click A d d again to add additional applications.
For example, to give Google Chrome and Delinea Agent access to the auto-enrollment private key, enter the application path for Google Chrome:
/Applications/Google Chrome.app
Click O K. Then click A d d and enter the application path for Delinea Agent:
/Applications/Centrify Agent.app
After this group policy is enabled, the list of applications specified in the group policy are added to the access control list of the auto-enrollment private key in
System keychain.
Note: This setting only applies to a new auto-enrollment private key. It does not change auto-enrolled private keys that are already in the
keychain.
If the group policy Allow all applications to access the auto-enrollment private key(s) (above) is enabled, this group policy will be ignored.
Do Not Allow the Private Key(S) to be Extractable
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Do not allow private key(s) to be
extractable
Description
Enabling this policy prevents exporting the auto-enrollment private key(s).
Note: This setting only applies to a new auto-enrollment private key. It does not change the auto-enrolled private key(s) that are already in the
keychain.
Store The Private and Public Key(S) Only in the Keychain
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Store the private and public key(s)
only in the keychain
Description
Enable this group policy to store the auto-enrollment key(s) only in the keychain.
User certificate auto-enrollment always uses the Keychain and is not controlled by any Group Policy.
Note: 802.1X profiles installed through the "Mac OSX Settings -> 802.1X Settings" Group Policies will no longer be signed if this GP is enabled
before profiles are installed.
Services
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services settings to manage access to the service
options from the Sharing ( ) system preference on Mac computers. These group policies correspond to the options displayed on the Services pane. For
example:
Enable Personal File Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Personal File Sharing
Description
Allow users on other Mac computers access to Public folders on the local computer. If you enable this group policy, all users can access files in the Public folder
through the Apple File Sharing protocol. Users with appropriate permission can also access other folders on the local computer if properly authenticated.
Enabling this group policy is the same as opening the Sharing system preference, selecting File Sharing, then clicking the Options button and selecting the
Share Files and Folders using AFP option.
Enable Windows Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Windows Sharing
Description
Allow users on Windows computers access to shared folders on the local computer through SMB/CIFS file shares.
Share Files and Folders using SMB option.
On Mac OS X Servers, this policy has no effect.
Enable Personal Web Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Personal Web Sharing
Description
Allow users on other computers to view Web pages in each user’s sites folder on the local computer.
Enabling this group policy is the same as opening the Sharing system preference and selecting the Web Sharing option.
Enable Remote Login
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Remote Login
Description
Allow users on other computers to access this computer using SSH.
Enabling this group policy is the same as opening the Sharing system preference and selecting the Remote Login option.
Enable FTP Access (deprecated)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable FTP Access
Description
Allow users on other computers to exchange files with this computer using FTP applications.
Share Files and Folders using FTP option.
On Mac OS X Servers enabling this policy has no effect.
Enable Apple Remote Desktop
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Apple Remote Desktop
Description
Allow others to access this computer using the Apple Remote Desktop program.
Enabling this group policy is the same as opening the Sharing system preference and selecting the Remote Management option.
If you enable this group policy, you can set the following access privileges:
Allow guest users to request permission to control the screen

Prevent VNC viewers from controlling the screen.
Because allowing VNC viewers to control the screen requires setting a password to take control of the screen and this behavior presents a potential security
issue, this group policy can only be used to disallow VNC access.
Enable Remote Apple Events
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Remote Apple Events
Description
Allow applications on other Mac computers to send Apple Events to the local computer.
Enabling this group policy is the same as opening the Sharing system preference and selecting the Remote Apple Events option.
Enable Printer Sharing
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Printer Sharing
Description
Allow other people to use printers connected to the local computer.
Enabling this group policy is the same as opening the Sharing system preference and selecting the Printer Sharing option.
Enable Xgrid
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Services > Enable Xgrid
Description
Allow clustered Mac OS Xgrid controllers to distribute tasks to the local computer for completion.
Enabling this group policy is the same as opening the Sharing system preference and selecting the Xgrid Sharing option.
On Mac OS X Servers enabling this policy has no effect.
Software Update Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Software Update Settings
Description
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Software Update Settings group policies to manage
software updates. The group policies in this category enable you to set the interval for checking for software updates and to identify a specific server from
which updates should be received.
These group policies correspond to settings you make using the Software Update ( ) system preference on client Mac OS X computers and the Software
Update preference in the Workgroup Manager on Mac OS X servers. For example, the interval for checking for software updates is typically configured
Software Update system preference on client Mac computers:
Note: Identifying a software update server to use for downloading updates is configured on a Mac OS X server using the Software Update
preference in the Workgroup Manager. For example:
The software update group policies are computer policies, applied as the root user, and apply to all users of the computer. Setting these group policies
updates the plist files for individual users with the group policy parameters, such as update server URL, update interval, and so on. However, to prevent local
users from using Software Update in System Preferences to manually set software update server parameters, an administrator should also limit access to
the Software Update Preferences Pane by setting the group policy, Limit Items Shown in System Preferences, and then enabling the group policy,
Enable System Preferences Pane: System > Enable Software Update.
Otherwise, you may see anomalous behavior. For example, a user can open Software Update and change parameters, such as disabling software updates (by
deselecting Check for updates). If the user then re-enables software updates, the update server resets to the Apple software update server, not the server
specified in the software update server group policy. However, at the next login, or at the next adgpupdate period, the Server URL and other group parameters
will be re-applied.
The Software Update Settings contain separate folders that allow you to specify a different update server for each operating system version that you are
running. For example, if you have computers with different versions of OS X in your environment, you can specify a different update server for each one by
enabling the Specify software update server policy in each of the version-specific folders. In order to do this you must enable Use version specific settings.
If you do not enable Use version specific settings, Legacy Settings are used instead. If you applied Software Update Settings to computers running previous
versions of the product, those settings are in Legacy Settings, though you may update them if you wish.
Note: The Automatically download and install software updates policy applies to all computers, regardless of version.
Automatically Check For Software Updates (Legacy, Currently Supported)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Software Update Settings > Automatically check for software updates (Legacy,
Currently supported)
Description
Note: There are actually separate versions of this policy in version-specific folders.
Periodically check for updated versions of the software installed on the local computer and automatically download and install newer versions. You can
configure the version-specific versions of this policy the same way you can configure the Software Update system preference for the corresponding
operating system version.
This policy takes effect when users log out and log back in.
Use Version Specific Settings
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Software Update Settings > Use version specific settings
Description
Enable the use of version-specific settings.
You can then set platform-specific preferences settings for each platform in your environment, which enables you to specify a different update server
depending on the version of Mac OS X running on a computer. For example, if you have only 10.10 computers, you can enable this policy and then use Mac OS X
10.10 settings. If you have 10.10 and 10.9 computers, enable this policy, and then configure the version-specific policies as appropriate:
Mac OS X 10.10 Settings

If this policy is disabled or not configured, Legacy Settings are used instead of version-specific settings. Likewise, Delinea versions prior to 4.4.2 always use
Legacy Settings and ignore this policy setting.
If you configured Software Update Settings with a version of the product prior to 4.4.2, these settings are saved to Legacy Settings when you upgrade to the
current Delinea version. You can keep or edit these settings as you wish.
Specify Software Update Server (Legacy, Currently Supported)
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Software Update Settings > Specify software update server (Legacy, Currently
supported)
Description
Note: There are actually separate versions of this policy in version-specific folders.
This enables you to specify a separate update server based on the version of the Mac OS X computer.
Type the URL that identifies the computer you are using as the software update server. It is recommended that you specify the hostname of the server rather
than the IP address; for example:
http://myHost.local:8088
In addition, to ensure that DNS associates the hostname of the update server with the IP address, add a line such as the following to the /etc/hosts file:
192.168.2.79 myHost.local
where: 192.168.2.79 is the IP address of the update server and myHost.local is the hostname.
Setting User-Based Group Policies
computers and to users who log on to Mac computers. This chapter describes the Mac group policies that can be applied to Mac users
The user-based group policies are defined in the Centrify Mac administrative template (centrify_mac_settings.xml) and accessed from User Configuration >
Policies > Centrify Settings > Mac OS X Settings.
Group policies are only applied to users and computers in the GPO’s linked OU and any child OUs. If your users and computers are in different OUs (which is
common), Delinea recommends using user Group Policy loopback processing to make sure user policies are applied to everyone who logs on to a Mac. This is
a standard Microsoft Group Policy that applies to every user to the computer.
To implement user Group Policy loopback processing mode
1. In the Group Policy Management Editor, navigate to Computer Configuration > Administrative Templates > System > Group Policy >
Configure user Group Policy loopback processing mode.
2. Enable the policy, set Mode: to Merge, then click O K.
See https://technet.microsoft.com/en-us/library/cc978513.aspx for more information about loopback processing.
See Understanding Group Policies for Mac Users and Computers for general information about how to use group policies to manage Mac settings and for
information on how to install the group policy administrative templates.
Note: For additional information about creating and using group policies and Group Policy Objects, see your Windows or Active Directory
documentation. For more information about adding and using other Centrify group policies that are not specific to Mac computers and users, see
the Group Policy Guide.
Setting User-Based Policies
This section describes user-based policies for Mac that you can set. The following table provides a summary of the group policies you can set for Mac users.
These group policies are in the Centrify Mac administrative template (centrify_mac_settings.xml) and accessed from User Configuration > Policies >
Centrify Settings > Mac OS X Settings.
Note: Group policies are only applied to users and computers in the GPO’s linked OU and any child OUs. Enable Computer Configuration >
Administrative Templates > System > Group Policy > Configure user Group Policy loopback processing mode in Merge mode to
make sure user policies are applied to everyone who logs on to a Mac.
Create user profiles for wireless authentication. This group policy corresponds to 802.1X Options in the Networks system
802.1X Wireless Settings
preference.
Application Access Control the specific applications users are either permitted to use or prohibited from using. These group policies correspond
Settings (deprecated) to Applications preferences set in the Workgroup Manager.
Control the desktop and screen saver options for users on Mac computers. These group policies correspond to settings in the
Desktop Settings
Desktop & Screen Saver system preference.
Control the look and operation of the Dock displayed on the user’s desktop. These group policies correspond to Dock
Dock Settings
preferences set in the Workgroup Manager.
Finder Settings Specify whether to use the standard Finder, or the Simple Finder, which restricts users to applications and folders in the Dock.
Folder Redirection Redirect specified network home folders to the local computer to improve performance.
Specify plist files to import preferences from another computer. This group policy corresponds to the import plist
Import Settings
functionality in Workgroup Manager.
Specify frequently used applications, folders, and server connections to open when a user logs in. This group policy
Login Settings
corresponds to the login functionality in Workgroup Manager.
Control the specific media types users are either permitted to use or prohibited from using. These group policies correspond
Media Access Settings
to Media Access preferences set in the Workgroup Manager.
Control the synchronization rules applied for users access services from mobile devices. These group policies correspond to
Mobility Settings
Mobility preferences set in the Workgroup Manager.
Scripts (Login/Logout) Specify login and logout scripts that run when Active Directory users log on or log out.
Control the secure login options for users on Mac computers. These group policies correspond to settings in the Security
Security & Privacy Settings
system preference.
System Preference Control the specific system preferences displayed for users. These group policies correspond to System Preferences set
Settings in the Workgroup Manager.
802.1X Wireless Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X settings to create profiles for wireless network
authentication. The profiles you specify with these group policies are created in the Network system preferences pane.
Specify User Profiles (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1X Wireless Settings > Specify User Profiles (Deprecated)
Description
Enable this policy to specify 802.1X User Profiles for wireless network authentication.
When using a user profile, a user will be prompted for username and password to authenticate to a wireless network after login.
To add a user profile
1. Enable the policy and click A d d to enter the profile name and setting.
2. Type a name for the profile.
3. Type the setting using the following format:
Network;Security Type;Authentication Method, where each field is separated by a semi-colon ; .
Network is the wireless network name
Security type is one of 802.1X WEP, WPAEnterprise, WPA2 Enterprise
Authentication method is one or more of the following, separated by commas: TTLS, PEAP, TLS, EAP-FAST, LEAP, MD5
For example:
OFFICE1;WPA Enterprise;PEAP
OFFICE2;802.1X WEP;TTLS,PEAP
Set the Automatically turn on Airport option to automatically turn on AirPort device if this type of profile is specified. Otherwise, the status of the AirPort
device will not change.
Application Access Settings (deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings group policies to manage the
applications Mac users are allowed to open or prevented from opening.
These group policies correspond to settings you can make using the Applications preference in the Workgroup Manager.
Permit/Prohibit Access to Application List: Applescript (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to application list: AppleScript
Description
Select the specific applications in the Finder’s Applications/AppleScript folder that users are permitted to use if you selected Users can only open these
applications, or not allowed to use if you selected Users can open all applications except these.
This policy is only effective if the Permit/prohibit access to applications group policy is enabled. If the Permit/prohibit access to applications
group policy is not configured or disabled, this group policy is ignored.
Permit/Prohibit Access to Application List: Applications (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to application list: Applications
Description
Select the specific applications in the Finder’s Applications folder that users are permitted to use if you selected Users can only open these
Permit/Prohibit Access to Application List: Server (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to application list: Server
Description
Select the specific applications in the Finder’s Applications/Server folder that users are permitted to use if you selected Users can only open these
group policy is not configured or disabled, this group policy is ignored. In addition, this policy is only applicable for Mac OS X Server computers.
Permit/Prohibit Accesst to Application List: Utilities (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to application list: Utilities
Description
Select the specific applications in the Finder’s Applications/Utilities folder that users are permitted to use if you selected Users can only open these
Permit/Prohibit Access to Applications (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to applications
Description
Allow other policies to specify the applications that users are permitted to access or prohibited from accessing. You must enable this policy for any other
application access group policies to take effect. Once enabled, only the applications explicitly specified in Application List policies are permitted or
prohibited.
If you enable this policy, in Access mode, select one of the following:
Users can only open these applications to grant access only to the applications you select with the other application access policies.
Note: If you select the option, User can also open all applications on local volumes, users can access any local applications.
Restrictions only apply to applications on CDs, DVDs, or external disks.
Users can open all applications except these to prevent access only to the applications you select with the other application access policies.
You can also set the following options in this group policy:
Select User can also open all applications on local volumes to allow access to applications on a computer’s local hard drive.
If selected, users can access any local applications in addition to the applications explicitly approved using the other application access policies. If you
uncheck this option, users can only access applications on CDs, DVDs, or external disks that have been explicitly approved.
Select Allow approved applications to launch non-approved applications to allow approved applications to open applications that aren't
explicitly approved.
For example, if users click a link in an email message, this option allows the email application to open a browser to display the Web page even if the
browser is not listed as an approved application. To prevent approved applications from opening applications that aren’t explicitly approved, uncheck
this option.
Select Allow UNIX tools to run to allow applications or the operating system to run tools, such as the QuickTime Image Converter, without explicitly
listing them as approved applications.
These tools usually operate in the background, but can be run from the command line. If you want to prevent access to these tools, do not check this
option.
Permit/Prohibit Access to the User-Specific Applications (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Application Access Settings > Permit/prohibit access to the user-specific
applications
Description
Define a list of additional applications that users are permitted to run if you selected Users can only open these applications, or not allowed to use if
you selected Users can open all applications except these. If enabled, you must specify the CFBundleIdentifier to identify the application; for
example, for the Firefox browser, the CFBundleIdentifier is: org.mozilla.firefox. To find the CFBundleIdentifier complete the following steps:
1. In the Finder, locate the application to control.
2. Control-click or right-click the application, then select Show Package Contents.
3. If necessary, expand the Contents folder, then open info.plist with a text editor.
4. Find the string: CFBundleIdentifier.
On the next line is the application’s CFBundleIdentifier; for example:
org.mozilla.firefox
1. Use org.mozilla.firefox to identify the Firefox browser.
To add an application to the list, select Enabled, then click A d d and enter the CFBundleIdentifier and click O K.
You may also control access to system preference panes by using the CFBundleIdentifier. You can find the CFBundleIdentifier for system preference panes in
/System/Library/PreferencePanes. You can specify any application object that has a CFBundleIdentifier in its info.plist file.
Note: Some applications may not have a CFBundleIdentifier (when you right-click the application name, there is no Show Package Contents
menu item). In this case, you cannot add the application to the list of permitted or prohibited applications.
Once enabled, this group policy takes effect when users log out and log back in.
Automount Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Automount Settings
Description
Use the Automount Settings to automatically mount network shares and the user’s Windows home directory when a user logs in.
Automount Network Shares
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Automount Settings > Automount network shares
Description
Specify the network shares to automatically mount when a user logs in. The default network share mount location is User_Home/Network Share.
This policy supports SMB, AFP, and NFS shares.
To add a share
1. Enter a path to mount the share in the Mount to: field.
The path should start with / or ~. The default value is ~/Network Shares. In this case, network share folders would be mounted under the directory Network
Shares of user's home directory.
2. Click Enabled, then click A d d and enter the share in one of the following formats:
keyword://server/share
where:
keyword is one of smb, nfs, afp

server is the name or IP address of the server and can include a user or user and password in the form: user:@server or user:password@server.
share can include spaces and be followed by a subdirectory.
For example, the following are all valid share specifications:
smb://acme.com/MacUsers
smb://acme.com/Mac Users
smb://acme.com/MacUsers/Shared_resources
smb://jsmith:pass1234@acme.com/MacUsers
afp://acme.com/Users_server
nfs://acme.com/MacUsers
nfs://192.168.0.1/MacUsers
1. (Optional) Select Create Dock icon to create a link to the network share in the user’s Dock.
Once enabled, this policy takes effect when a user logs out and back in to a computer.
Automount User’s Windows Home
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Automount Settings > Automount user’s Windows home
Description
Automatically mount the user’s Windows home directory when the user logs in.
Specify the Windows home directory by using the Profile tab for a user in Active Directory Users and Computers (ADUC).
Create Alias Instead of Symbolic Link
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Automount Settings > Create alias instead of symbolic link
Description
This group policy is provided for compatibility with Delinea releases earlier than 2015. If you are using release 2015 or later, do not use this group policy.
In releases prior to 2015, the default mount point for network shares was /var/centrify/mnt/user. Starting with release 2015, the default mount point for network
shares is User_Home/Network Share.
In Delinea releases prior to 2015, the “Automount network shares” group policy creates symbolic links to the specified shared network directories. However,
certain versions of Microsoft Office are unable to save files to a shared folder by using the symbolic link (the link is greyed-out). The “Create alias instead of
symbolic link” group policy corrects the problem by creating an alias instead of a symbolic link. In release 2015 or later, because of the new mount location,
symbolic links are not required, and this group policy has no effect.
If you enable this group policy, the alias points to network shares that are automatically mounted when a user logs in.
Note: The operating system treats an alias as a file, which means that you cannot use the Terminal program to access files or folders that are
pointed to by the alias.
Custom Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig Profiles group
policy to install mobile configuration profiles. This policy installs a user profile. To install a device profile, use the same policy in Computer Configuration
> Centrify Settings > Mac OS X Settings > Custom Settings.
Install MobileConfig Profiles
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig profiles
Description
Enable this group policy to install mobile configuration profiles on managed Mac computers.
Note: There is a Computer Configuration version of this policy (which installs device profiles) and a User Configuration version (which installs
user profiles).
Before enabling this policy, you must create a directory and copy mobile configuration files to SYSVOL on the domain controller. SYSVOL is a well-known
shared directory on the domain computer that stores server copies of public files that must be shared throughout the domain.
Specifically, create the following directory on the domain controller: \\domainName\SYSVOL\domainName\mobileconfig
and copy one or more mobile configuration profile files to this directory. See Deploy Configuration Profiles to Multiple Computers for details on how to do this.
To specify mobile configuration files to install, enable the policy, then click A d d. Enter the name of a mobile configuration file that you placed in SYSVOL on
the domain controller. Include the .mobileconfig suffix with the name.
If you specify a file that is not in the SYSVOL mobileconfig directory, the profile will not be installed.
If you add new files to the existing list in the group policy, those profiles will be installed — existing profiles will not be touched. If you remove previously
specified files, the profiles defined by these files will be uninstalled.
If you add two or more profile files that have the same payloadIdentifier, only one of them will be installed.
If you change the group policy to “Disabled” or “Not Configured”, all existing profiles that were installed previously by the group policy will now be uninstalled
from the managed Mac computers.
Desktop Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Desktop Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Desktop Settings group policy to manage the start time for
the screen saver from the Desktop & Screen Saver ( ) system preference on Mac computers. This group policy corresponds to the Start screen saver
option displayed on the Screen Saver pane. For example:
Set Computer Idle Time for Starting Screen Saver
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Desktop Settings > Set computer idle time for starting screen saver
Description
Select the length of time to wait before starting the screen saver. If you enable this group policy, you can specify the number of minutes to wait while a
computer is not in use before starting the screen saver. For example, if you want the screen saver to start after a computer has been idle for 10 minutes, you
can set Start screen saver to 10 minutes.
Disabling this policy does not disable the screen saver. To disable the screen saver, enable this policy and set the value to 0.
Although you may specify values greater than 60 minutes, and the screen saver works appropriately, the Macintosh Screen Saver dialog box shows values
that are greater than 60 as Never.
Enabling this group policy is the same as selecting when to start the screen saver using the Start screen saver slider in the Desktop & Screen Saver system
preference.
Dock Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings group policies to manage the characteristics
of the Dock for Mac users. These settings correspond to the Dock preferences you can manage using the Workgroup Manager. In the Workgroup Manager,
the Dock Items pane controls the items placed in the Dock and whether the workgroup Dock is merged with the user’s Dock, and the Dock Display pane
controls attributes such as the Dock size, magnification, position, and animation. For example:
Add Other Folders to the Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Add other folders to the Dock
Description
Add icons for the other commonly-used folders to the Dock. You can choose to add the following folder icons to the Dock:
My Applications
Documents
The My Applications folder contains aliases to all approved applications you have defined in the Application list. If you do not manage access to
applications, all available applications are included in the My Applications folder. If you enable Simple Finder, you should display the My Applications folder.
The Documents folder is the Documents folder found in the user’s home folder. For example, the /Users/username/Documents folder for local user accounts.
Adjust the Dock’s Icon Size
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Adjust the Dock’s icon size
Description
Set the approximate size of Dock icons in pixels. The valid settings for the Dock size range from 16 pixels (small) to 128 pixels (large). The default size is 80
pixels.
Note: This setting is approximate because the actual size of Dock icons depends on screen resolution and the number of icons in the Dock.
Adjust the Dock’s Magnified Icon Size
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Adjust the Dock’s magnified icon size
Description
Set the level of magnification to use for items in the Dock. If you enable this group policy, icons in the Dock are magnified to display in a larger size as the
pointer moves over them. The valid settings for Dock magnification range from 16 pixels for minimum magnification to 128 pixels for maximum magnification.
The default size is 80 pixels.
If you do not configure or disable this group policy, icons in the Dock are not magnified when the pointer moves over them.
Adjust the Dock’s Position on Screen
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Adjust the Dock’s position on screen
Description
Specify the location for displaying the Dock on the screen. If you enable this group policy, you can position the Dock on the left, bottom, or right of the screen.
The default location for displaying the Dock is at the bottom of the screen.
Adjust The Effect Shown When Minimizing the Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Adjust the effect shown when minimizing the Dock
Description
Specify the effect to use when a window or application is minimized and placed in the Dock. The valid effects are:
Genie
Scale
Suck
Animate Opening Applications
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Animate opening applications
Description
Animate application icons so that the icon displayed in the Dock bounces when the user opens the application.
Automatically Hide and Show the Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Automatically hide and show the Dock
Description
Hide the Dock from view automatically. If you enable this policy, the Dock is hidden during normal operation. The Dock is then automatically displayed again if
the pointer moves over the position on the screen where the Dock is located.
Lock the Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Lock the Dock
Description
Lock the applications displayed in the Dock. If you enable this policy, icons cannot be moved into or out of the Dock.
Place Applications in Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Place applications in Dock
Description
List the applications to include in the Dock. After you enable this policy, click A d d to enter the path to the application you want included in the Dock. Then
click O K. You can click A d d again to add additional applications. For example, to add Firefox and Chess icons to the Dock, type the application paths:
/Applications/Firefox.app
Click O K. Then click A d d and enter:
/Applications/Chess.app
The icons for the applications you specify are placed to the left or above the separator line in the Dock in the order you enter them, up to 10 items. if you add
more than 10 the order may be random. If the path to an application is incorrect, a question mark (?) is displayed in the Dock in place of the application’s icon.
This group policy does not sort icons from the initial system list. To sort these items, such as the Mail application icon, you can add the item to the list.
Place Documents and Folders in Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Place documents and folders in Dock
Description
List the documents or folders to include in the Dock. After you enable this policy, click A d d to enter the path to the folder or document you want to include in
the Dock. Then click O K. You can specify additional folders or documents by clicking A d d again. For example, to add the Users folder and the Copyright.txt
document to the Dock, type the paths to each:
/Users
Click O K, then click Add and type:
/Documents/Copyright.txt
The icons for the items you specify are placed to the left or above the separator line in the Dock. Items are sorted in the order you enter them up to 10 items. If
you specify more than 10 items the order may be random. If the path to an item is incorrect, a question mark (?) is displayed in the Dock.
Note: You may not specify the path to a network share; for example, smb://serverName. Network share paths are implemented as aliases, which work
differently than folder and document paths. If you specify a network share, a question mark (?) is displayed in the Dock.
Merge with User’s Dock
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Dock Settings > Merge with user’s Dock
Description
Merge the Workgroup Dock settings with the user’s Dock.
Finder Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Finder Settings
Description
Use the User Configuration> Policies > Centrify Settings > Mac OS X Settings > Finder Settings group policies to configure Finder commands,
preferences and views.
The Configure Finder Commands (Deprecated) policy, below, allows you to control which commands are available in the Apple menu and Finder
menus for users.
The Configure Finder Preferences (Deprecated) policy, below, enables you to specify the type of Finder for the user environment. After enabling the
policy, you can choose one of two types from the drop-down list:
Normal Finder applies the standard Mac desktop. This is the default value, and is the environment that all users will have if the policy is not enabled.
Simple Finder restricts users to applications that are in the Dock.
When Simple Finder is enabled, users cannot open applications, open, modify, or delete documents, or create folders in the Finder. They also cannot mount
network drives. They can only use items that are in the Dock. Use the Dock Settings policies above to configure the Dock; for example, enable Place
Applications in Dock and Place Documents and Folders in Dock to control the applications and folders that users can access.
The Configure Finder Preferences (Deprecated) policy, below, enables you to control the arrangement and appearance of items on the user’s
desktop, in Finder windows, and in the top-level folder of the computer.
Configure Finder Commands (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Finder Settings > Configure Finder commands (Deprecated)
Description
Specify the commands in Finder menus and the Apple menu that are available to users. Select commands from the following list:
Connect to Server
Select to allow users to connect to a remote server by choosing 'Connect to Server' in the Finder Go menu. Deselect to prevent users from accessing
this command.
Go to iDisk
Select to allow users to connect to an iDisk by choosing 'Go to iDisk' in the Finder Go menu. Deselect to prevent users from accessing this command.
Eject
Select to allow users to eject discs (for example, CDs, DVDs, floppy disks, or FireWire drives). Deselect to prevent users from ejecting disks.
Burn Disc
Select to allow user on computers with relevant hardware to burn discs. Deselect to prevent users from burning disks.
Go to Folder
Select to allow users to open a specific folder by choosing the 'Go to Folder' command in the Finder Go menu. Deselect to prevent users from using the
'Go to Folder' command.
Restart
Select to allow users to restart the computer they're using, or deselect to prevent them from restarting the computer.
Shut Down
Select to allow users to shut down the computer they're using, or deselect to prevent them from shutting down the computer.
Once enabled, this group policy takes effect when users log out and back in.
Configure Finder Preferences (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Finder Settings > Configure Finder preferences (Deprecated)
Description
Configure Finder preferences, including whether to use normal or Simple Finder, which items to show on the desktop, how a new window behaves, and
whether to show filename extensions and the Empty Trash warning.
Select from the following options:
Finder type
Select the normal Finder or Simple Finder as the user environment. The normal Finder looks and acts like the standard Mac desktop. Simple Finder
removes the ability to use a Finder window to access applications or modify files, limiting users' access to only what is in the Dock. In addition, users
can't mount network volumes, create folders, or delete files.
Show these items on the Desktop
Choose whether users see icons for local hard disks, external disks, CDs (DVDs and iPods), and connected servers on the desktop.
If you hide them, icons for disks and servers still appear in the top-level folder when a user clicks the Computer icon in a Finder window's toolbar.
New Finder window shows
Select Home to show items in the user's home folder, or select Computer to show the top-level folder, which includes local disks and mounted
volumes.
Always open folders in a new window
Select this option to display folder contents in a separate window when a user opens a folder.
Always open windows in column view
Select this option to display folders in column view, which maintains a consistent view across windows.
Show warning before emptying the Trash
Select this option to display the normal warning when a user empties the Trash, or deselect it if you don't want users to see this message.
Always show file extensions
Select this option to show filename extensions (such as .txt or .jpg) that identify the file type; or deselect it to hide filename extensions.
Configure Finder views
Enable this group policy to control Finder views, for example the arrangement and appearance of items on a user's desktop, in Finder windows, and in the
top-level folder of the computer.
The options in Desktop View allow you to adjust the size and arrangement of icons on the desktop.
Use Icon Size to adjust the icon size.
Use Icon Arrangement to specify how to arrange icons:
To keep items aligned in rows and columns, select Snap to grid.

To arrange items by criteria such as name or type (for example, all folders grouped together), select Keep arranged by.
Items in Finder windows are viewed in a list or as icons and you can control aspects of how these items look.
Default View settings control the overall appearance of all Finder windows. Computer View settings control the view for the top-level computer folder,
showing hard disks and disk partitions, external hard drives, mounted volumes, and removable media (such as CDs or DVDs).
In Icon View, use Icon Size to adjust the size of icons.
Use Icon Arrangement to specify how to arrange icons:
To keep items aligned in rows and columns, select Snap to grid.

To arrange items by criteria such as name or type (for example, all folders grouped together), select Keep arranged by.
In List View, set the following:
Select relative dates to show an item's creation or modification date relative to today, rather than as a fixed date; for example, Today or Yesterday,
instead of 3/24/10.
Select Calculate folder sizes to calculate the total size of each folder shown in a Finder window, which can take a lot of time depending on the size of
the folder.
In Icon Size, select Select small or b i g for the size of icons in list view.
Folder Redirection
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Folder Redirection
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Folder Redirection group policies to redirect specified
folders from a network home directory to the local computer.
When you set up a network home directory, all home directory files are written to the network share. Some folders, such as /Library/Caches, get heavy I/O from
Apple and third-party applications, which may cause performance issues. The folder redirection policies enable you to redirect specific folders, such as
/Library/Caches, to the local computers, which can result in dramatic performance improvements.
Folder Redirection contains two folders with identical sets of four policies:
Folder redirection actions at login time applies the specified policy when the user logs in. For example, at login delete a folder in the network
home directory and create a symbolic link to it on the local computer.
Folder redirection actions at logout time applies the specified policy when the user logs out. For example, at logout, delete the symbolic link on
the local computer (created at login) and restore the original folder to the network home directory.
After enabling the policy, click A d d, then enter the following:
P a t h The path to the folder on the network share. You do not need to specify the actual network share location — you can simply use the tilde (~) for the
user’s home directory; for example, ~/Library/Caches specifies the /Library/Caches directory in the user’s network home directory.
Link The location to create or delete on the local computer. For example:
/tmp/Library/Caches
If you wish, you can use the syntax %@ to specify the logged in user’s name. For example:
/tmp/%@/Library/Caches
If cain is the logged in user, the folder that is created is:
`/tmp/cain/Library/Caches`
The Folder Redirection policies are listed here and explained below:
Delete path
Delete symbolic link and restore
Delete and create symbolic link
Rename and create symbolic link
Delete path
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Folder Redirection > Folder Redirect Actions at Login/Logout Time > Delete path
Description
Deletes the specified directory from the network home directory. For example, to delete the /Library/Caches file from each user’s home directory, enter the
following in the P a t h box:
~/Library/Caches
Typically, you enable this policy for the login time folder.
Note: You are not required to enter anything in the Link box for this group policy, and in fact, anything you enter in this box will be ignored. All the
policies in this folder are implemented with the same UI and the other policies require the Link box so it appears for this policy as well.
Once this group policy is enabled, it takes effect when users log in (enabled for login time folder) or log out (enabled for logout time folder).
Delete Symbolic Link and Restore
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Folder Redirection > Folder Redirect Actions at Login/Logout Time > Delete symbolic
link and restore
Description
Deletes a previously defined symbolic link on the local computer and restores the specified directory to the network home directory. Typically, you use this
policy with the Rename and create symbolic link policy. For example:
At login (using Rename and create symbolic link) you save ~/Library/Caches in the network home directory to a temporary folder and redirect it to a folder on the
local computer, for example /tmp/user/Library/Caches. At logout, you can enable Delete symbolic link and restore to delete the symbolic link and restore the folder
on the network home directory, by specifying the following:
P a t h: ~/Library/Caches
Link: /tmp/%@/Library/Caches
where: %@ specifies the logged in user’s name on the local computer.
Delete and Create Symbolic Link
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Folder Redirection > Folder Redirect Actions at Login/Logout Time > Delete and
create symbolic link
Description
Deletes the specified directory from the network home directory and creates a symbolic link to it on the local computer.
For example, to delete the user’s /Library/Caches policy from the network home directory and create a link to it on the local computer, specify the following after
enabling the policy:
P a t h: ~/Library/Caches
where %@ specifies the logged in user’s name on the local computer. For example, if cain is the logged in user, the cache files are written to:
/tmp/cain/Library/Caches
Rename And Create Symbolic Link
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Folder Redirection > Folder Redirect Actions at Login/Logout Time > Rename and
create symbolic link
Description
Renames the specified directory in the network home directory to a temporary folder and creates a symbolic link to it on the local computer.
For example, to rename the user’s /Library/Caches policy on the network home directory and create a link to it on the local computer, specify the following after
enabling the policy for the login time folder:
Path: ~/Library/Caches
where %@ specifies the logged in user’s name on the local computer. For example, if cain is the logged in user, the cache files are written to:
/tmp/cain/Library/Caches
To restore the original /Library/Caches directory, use the Delete symbolic link and restore policy (enabled for the logout time folder).
Import Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Import Settings
Description
Mac OS X uses plist files to store application and other preferences. Use the User Configuration > Policies > Centrify Settings > Mac OS X
Settings > Import Settings group policies to import plist files to customize your preferences:
Import plist files. This group policy allows you to import preferences from another computer to computers in your Delinea-managed domain. To do
so you:
Copy the plist files you want to use to the system volume on the domain controller.
Use the Import plist files group policy to import the plist files to computers in the domain.
This group policy automatically processes plist files to extract MCX settings when the files are imported.
Import MCX setting plist files. This group policy is similar to the Import plist file group policy, except that it does not process any data from the
inputted plist files. This group policy copies the exact content (that is, the “raw” content) from the plist file and imports it to the Active Directory user
record.
When you import the plist files, Delinea copies them to the appropriate directories on the local computers to implement the preferences that they control.
You can gather and copy plist files from multiple computers and paste them to the sysvol directory on the domain controller, but a more structured approach is
to set up a preferences ‘template’ computer, that is, a computer that is set up with your desired preferences. Then you can copy the appropriate plist files to
sysvol on the domain controller. Finally, you can use either of the group policies described here to import the plist files to Delinea-managed computers in the
domain.
Mac OS X stores plist files in the /Library/Preferences directory and in the /Users/userName/Library/Preferences directory.
The following section shows specifics of using these group policies.
Import plist Files
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Import Settings > Import plist files
Description
Specify the names of plist files to import from the system volume (SYSVOL) — similar to importing plist files in Mac Workgroup Manager. By default, the
system volume folder is at: \\domain\SYSVOL\domain\plist.
Before enabling this policy, you should copy all the plist files to import to the system volume (sysvol) on the domain controller.
To add a file, select Enabled, click A d d, then type a filename.
The path you type in plist file is relative to \\domain\SYSVOL\domain\plist. For example, if the domain name is ajax.org and you enter a plist file named
com.apple.MCX.plist, the file that gets imported is:
\\ajax.org\sysvol\ajax.org \com.apple.MCX.plist
You can specify additional relative directories in the path, if needed.
Import MCX Setting plist Files
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Import Settings > Import MCX setting plist files
Description
Enable this group policy to import raw MCX settings plist files from SYSVOL. By default the folder is \\<domain>\SYSVOL\<domain>\mcxplist, similar to importing plist
files in Mac Workgroup Manager.
The plist file path that you specify is relative to this path:
\\<domain>\SYSVOL\<domain>\mcxplist
For example, if you specify this path:
com.apple.MCX.plist
the following plist file is imported:
\\<domain>\SYSVOL\<domain>\mcxplist\com.apple.MCX.plist
This group policy is similar to "Import plist files". However, instead of extracting MCX settings from the plist file like "Import plist files" does, this policy imports
the entire plist file without processing it.
An example plist file format is as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>mcx_application_data</key>
<dict>
<key>TARGET</key>
<dict>
<key>Forced</key>
<array>
<dict>
Settings
</dict>
</array>
</dict>
</dict>
</dict>
</plist>
In this example, TARGET is the targeted MCX settings (such as com.apple.dock or com.apple.finder)
The recommended way to obtain the plist file with the correct format is by using the dscl command, and reading the MCX settings attribute of the user object
that has the same MCX settings configured. Then copy the exact MCX settings and paste them into a plist file.
For example:
dscl /CentrifyDC read /Users/XXXX MCXSettings
where XXXX is an Active Directory user with the desired MCX settings.
Login Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Login Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Login Settings group policy to specify frequently used items,
such as applications, folders, or server connections to automatically open when a user logs in.
After enabling this policy, you can do the following:
Use the A d d button to specify the path to applications to open.

In the Network Home area, use the A d d button to specify URLs for servers to connect to; use the check box to specify whether to automatically
connect the logged in user to the specified servers.
Use the other check boxes to control whether users have the ability to add or remove login items.
The following table shows specifics of using this group policy.
Note: Only the Login items area is visible when you first open the properties page for the group policy. Use the scroll bar to see the Network
share area and other items that you can configure with this policy.
Enable Login Items
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Login Settings > Enable login items
Description
Specify the names of applications, folders, and server locations to open automatically when a user logs in. Select Enable, then do any or all of the following:
Login items. To add an application to open automatically, click A d d, then type the path to the application; for example:
/Applications/TextEdit.app
To initially hide the application, select Hide. The application will open, but its window and menu bar remain hidden until the user activates the application (for
example, by clicking the application icon in the doc).
Click O K to save the item you entered. You can click A d d as often as necessary to add multiple applications. You can also select an item in the window and
click Edit to change it, or Remove to delete it.
Network share. To add access to a network share, click A d d, then type the URL in one of the following formats:
smb://server/share
smb://server/hidden$
smb://server/share/subdir
smb://user:password@server/share
smb://user:@server/share
afp://server/share
nfs://server/share
nfs://192.168.0.1/share
To automatically connect the user to the share with the user's login name and password, select Authenticate selected share point with user’s login
name and password.
Note: If you uncheck this option, the share name must comply with RFC 1738 - Uniform Resource Locators (URL), which specifies that special
characters need to be encoded, for example, by using %20 instead of a space.
If the network share can be authenticated using Kerberos, this option can be ignored. If the network share cannot be authenticated using Kerberos, and this
option is unchecked, then the user will be prompted for a username and password.
If a username is specified in the URL for the network share, then checking this option will still mount the share as the login user, while deselecting this option
will mount the share as the user specified in the URL. For example, if network share is smb://mount_user:password@server/share, checking the option will mount the
share as login_user, while deselecting the option will mount the share as mount_user.
Click O K to save the item you entered. You can click A d d as often as necessary to add multiple shares. You can also select an item in the window and click
Edit to change it, or Remove to delete it.
Select User may add and remove additional items to allow users to add items to the list and remove items from the list.
Deselect this box to prevent users from adding items or removing the items that you have specified. Note that they can remove login items that they
specified on their own.
Select User may press Shift to keep items from opening to allow user’s to stop items from opening by holding down the Shift key during login
until the Finder appears on the desktop.
Deselect this option to prevent users from stopping applications from opening automatically.
Media Access Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings group policies to manage the access
to discs and other media for Mac users. These group policies enable you to control access to specific types of media, such as CDs or DVDs, but you cannot
restrict access to specific discs or to specific items, such as music or movies, on a disc type users are permitted to access. These settings correspond to the
Media Access preferences you can manage using the Workgroup Manager. For example:
Permit/Prohibit Access: CDs and CD-ROMs
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: CDs and CD-ROMs
Description
Control whether users can access data and applications on CDs and CD-ROMs. The valid options are:
allow to allow access to CDs and CD-ROMs without authentication.

allow, require authentication to require users to provide credentials for authentication before allowing them access to CDs and CD-ROMs.
deny to prevent users from accessing any data or applications on CDs and CD-ROMs.
Permit/Prohibit Access: DVDs
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: DVDs
Description
Control whether users can access data and applications on DVDs. The valid options are:
allow to allow access to DVDs without authentication.

allow, require authentication to require users to provide credentials for authentication before allowing them access to DVDs.
deny to prevent users from accessing any data or applications on DVDs.
Permit/Prohibit Access: Recordable Discs
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: Recordable Discs
Description
Control whether users can record or access data and applications on recordable discs. The valid options are:
allow to allow access to recordable discs without authentication.

allow, require authentication to require users to provide credentials for authentication before allowing them access to recordable discs.
deny to prevent users from accessing any data or applications on recordable discs.
Allowing users access to recordable discs enables users to burn CDs and DVDs. Recordable discs can be blank or rewritable disc media.
Permit/Prohibit Access: Internal Discs
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: Internal Discs
Description
Control whether users can access data and applications on internal discs. The valid options are:
allow to allow read and write access to internal discs without authentication.
allow, read-only to allow read-only access to the media.
allow, require authentication to require users to provide credentials for authentication before allowing them access to the media.
allow, require authentication, read-only to require users to provide credentials for authentication before allowing them access to internal discs,
and grant read-only access to the media if authentication is successful.
deny to prevent users from accessing any data or applications on internal discs.
Permit/Prohibit Access: External Discs
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Permit/prohibit access: External Discs
Description
Control whether users can access data and applications on external discs. External disks include floppy disks, FireWire drives, and all other external storage
devices except CDs and DVDs. The valid options are:
allow to allow read and write access to external discs without authentication.
allow, read-only to allow read-only access to external discs.
allow, require authentication to require users to provide credentials for authentication before allowing them access to external discs.
allow, require authentication, read-only to require users to provide credentials for authentication before allowing them access to external discs,
and grant read-only access to the media if authentication is successful.
deny to prevent users from accessing any data or applications on external discs.
Eject All Removable Media at Logout
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Media Access Settings > Eject all removable media at logout
Description
Control whether removable media, such as CDs, DVDs, Zip disks, or FireWire drives, are automatically ejected when users log out. If you enable this group
policy, CDs, DVDs, and other disk media are automatically ejected when users log out to ensure removable media is properly disconnected and put away when
users end their sessions.
Mobility Settings
Use the Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Mobility Settings group policies to control if macOS
creates a Mobile Account for the Active Directory user when logging in.
Configure Mobile Account Creation
Path
Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Mobility Settings > Configure mobile account creation
Description
Configure whether mobile accounts are created when users log in.
Check Require confirmation before creating mobile account to allow users to decide whether to enable a mobile account at login. Users see a
confirmation dialog when logging in and can click one of the following:
“Create Now” to create a local home folder and enable the mobile account.
“Don't Create” to log in as a network user without enabling the mobile account.
“Cancel Login” to return to the login window.
Select Show “Don't ask me again” checkbox to provide a check box that allows users to prevent display of the mobile account creation dialog on that
computer in the future. Users who select “Don't ask me again” and click “Don't Create”, are not asked to create a mobile account on that computer (unless
they hold down the Option key during login to redisplay the dialog).
Select Bypass the SecureToken dialog so that the system will bypass the secure token authorization dialog. The Active Directory user can continue to
create a mobile account. However, if this volume is encrypted, the Active Directory mobile user may not be able to log in with this account when the computer
starts. This dialog only affects APFS volumes.
Select Delete mobile accounts automatically at specified time after user's next login so that MacOS will delete the mobile account and its local
home folder automatically after a period of inactivity.
Printing settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Printing Settings > Specify printer list (with model)
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Printing Settings > Specify printer list (with model)
group policy to specify a list of printers for a user.
The printers that are available to a user are a combination of those specified in this policy and those added through System Preferences on the local
computer. Note that this policy allows an administrator to control whether the user can add or see printers on the local computer, or is only allowed to use the
managed printers specified by this policy.
Specify a managed list of network printers that are available to a user on this computer. Printers specified by this policy use a generic PostScript driver.
To add a printer, click A d d and enter the following information:
Name: A name of your choosing for the printer.

DeviceURI: The device Uniform Resource Identifier, which specifies the device that is assigned to the printer (see Specifying the Device URI,
below); for example:
socket://192.168.0.20:9100 (which identifies the protocol, IP address, and port number)
cdcsmb://dc1.acme.com/HPLaserJet2 (which identifies a Windows printer added using the Delinea protocol and identified by hostname.)
(Optional) Model: The printer driver for the printer model (see Specifying the Model (printer driver), below); for example: HP Photosmart C6100
series. Fax
You can use the following options to control access to the printers on the local computer:
Allow user to modify the printer list: Check this option to allow local users to make changes in System Preferences to the printers that have been
added by this policy, including deleting them.
Deselect this option to prevent local users from modifying the printers added by this policy.
Allow printers that connect directly to user’s computer: Check this option to allow users to add their own local printers.
Deselect this option to prevent users from adding local printers.
Require an administrator password: Check this option to require an administrator’s password when adding local printers.
Only show managed printers: Check this option to allow local users to use only the managed printers specified by this option.
Printers added locally, for example, through System Preferences, will not be visible.
Deselect this option to allow local users to use printers added locally, as well as the managed printers added by this policy.
Printers added through this group policy appear after the next group policy refresh interval.
Specifying the Device URI
When you add a printer through the Specify printer list group policy, or locally by using the Print & Scan, Add Printer advanced options, the printer is
implemented through the Common UNIX Printing System (CUPS), which was developed by Apple for Mac OS X and other UNIX-like operating systems.
The CUPS system supports the following device Uniform Resource Identifier (URI) protocols that you can use to specify the printers to add.
AppSocket or Jetdirect Protocol
The AppSocket, or JetDirect, protocol normally prints over port 9100 and uses the socket URI scheme:
socket://ip-address-or-hostname
socket://ip-address-or-hostname:port-number
Internet Printing Protocol (IPP)
CUPS supports IPP natively. IPP printing normally happens over port 631 and uses the http and ipp URI schemes:
ipp://ip-address-or-hostname/resource
ipp://ip-address-or-hostname:port-number/resource
http://ip-address-or-hostname:port-number/resource
Line Printer Daemon Protocol (LPD)
LPD is the original network printing protocol and is supported by many network printers. LPD printing normally happens over port 515 and uses the lpd URI
scheme:
lpd://ip-address-or-hostname/queue
lpd://username@ip-address-or-hostname/queue
Windows Printer via Delinea
When Mac users print on a Windows network printer, they must authenticate separately. Specifying a Windows printer via Delinea allows users to access the
printer without providing credentials as they have already been authenticated through Active Directory.
Delinea printing normally happens over port 445 and uses the cdcsmb URI scheme
cdcsmb://server_fqdn/printersharename
Windows
Windows printing normally happens over port 445 and uses the smb URI scheme:
Note: You can use the Delinea protocol (cdcsmb), if you want to use Windows network printers without providing credentials each time.
smb://workgroup/server/printersharename
smb://ip-address-or-hostname/printersharename
smb://username:password@workgroup/ip-address-or-hostname/printersharename
smb://username:password@ip-address-or-hostname/printersharename
Specifying the Model (printer driver)
Model specifies the model name of the added printer and is used to determine which device driver to associate with the printer. Be certain to specify model
correctly, otherwise, if model is not specified, or does not match a driver installed on the client Mac OX X computer, Generic PostScript driver will be selected
for the printer, which may result in fewer printing options.
To find the correct model name, take one of these two approaches:
Use Printers & Scanners to identify the model:
1. On a Mac OX X computer, open System Preferences > Printers & Scanners.

2. Click Add (+) to add a printer.
3. When you select a printer, the correct model name appears on the "Use" drop down menu.
Use lpinfo to identify the model
1. On a Mac OX X computer, open the Terminal application.
2. Run the following command to obtain the list of all the models available:
"lpinfo -m" command
In the output from lpinfo, the correct model string appears right after *.ppd.gz. For example:
Library/Printers/PPDs/Contents/Resources/HP Photosmart C6100 Series Fax.ppd.gz HP Photosmart C6100 series. Fax
The model string is:
HP Photosmart C6100 series. Fax
3. Type this in the group policy’s Model field.
Scripts (Login/Logout)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout)
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout) group policies to deploy login and
logout scripts that run when an Active Directory user logs on or logs out. When you use these group policies, the login and logout scripts are stored in the
Active Directory domain’s system volume (sysvol) and transferred to the Mac computer when the group policies are applied. Login and logout scripts are
useful for performing common tasks such as mounting and un-mounting shares.
Note: When these group policies are enabled, the first login by an AD user will restart the login script and return the user to the login window.
Subsequent logins by this user or a different user occur normally and the changes generated by the script happen immediately.
Specify Login Script (Deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout) > Specify login script
Description
Specify the name of a login script to execute when users log on. You can specify only one file as the login script.
Before enabling this policy, you should create the login script and copy it to the system volume (sysvol) on the domain controller. By default, the login script is
stored in the system volume (SYSVOL) on the domain controller in the directory:
\\domain\SYSVOL\domain\Scripts\scriptname
The script path you type in Login script is relative to \\domain\SYSVOL\domain\scripts\. For example, if the domain name is ajax.org and you enter a script name of
mlogin.sh, the script that gets executed on the domain controller is:
\\ajax.org\SYSVOL\ajax.org\Scripts\mlogin.sh
You can specify additional relative directories in the path, if needed.
Note: Be certain authenticated users have permission to read this file so the script can run when they log in.
By default, the script runs with the Active Directory user’s permissions. If the script contains commands that require root permission to run, select Run with
root user privileges.
Note: The first AD user to log in is taken back to the login screen. Subsequent logins by this user or a different user occur normally and changes
generated by the script happen immediately.
Specify Logout Script
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout) > Specify logout script
Description
Specify the name of a logout script to execute when users log out. You can specify only one file as the logout script.
Before enabling this policy, you should create the logout script and copy it to the system volume (SYSVOL) on the domain controller. By default, the logout
script is stored in the system volume (SYSVOL) on the domain controller in the following directory:
\\domain\SYSVOL\domain\Scripts\scriptname
The script path you type in Logout script is relative to: \domain\SYSVOL\domain\scripts\.
For example, if the domain name is ajax.org and you enter a script name of mlogout.sh, the script that gets executed on the domain controller is:
\\ajax.org\SYSVOL\ajax.org\Scripts\mlogout.sh
Note: Be certain authenticated users have permission to read this file so the script can run when they log out.
By default, the script runs with the Active Directory user’s permissions. If the script contains commands that require root permission to run, select Run with
root user privileges.
Specify Multiple Login Scripts
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Scripts (Login/Logout) > Specify multiple login scripts
Description
Specify the names of one or more login scripts to execute when a user logs on. The scripts you specify run simultaneously in no particular order.
This policy is also available as a computer policy. If you specify scripts using both the computer and user policies, the computer scripts are executed first.
Before enabling this policy, you should create the scripts and copy them to the system volume (sysvol) on the domain controller. By default, the login scripts
are stored in the system volume (SYSVOL) on the domain controller in the directory:
\scriptname1
\scriptname
...
__Script:__The name of the script and an optional path, which are relative to \\domain\SYSVOL\domain\scripts\.
For example, if the domain name is ajax.org and you enter a script name of mlogin.sh, the script that gets executed on the domain controller is:
`\ajax.org\SYSVOL\ajax.org\Scripts\mlogin.sh``
\\ajax.org\SYSVOL\ajax.org\Scripts\sub\mlogin.sh
Parameters: An optional set of arguments to pass to the script.
These arguments are interpreted the same way as in a UNIX shell; that is, space is a delimiter, and backslash is an escape character. You can also use $USER
to represent the current user's name. For example:
arg1 arg2 arg3

arg1 'a r g 2' arg3
arg' $USER.
Note: Be certain authenticated users have permission to read these files so the scripts can run when they log in.
Security & Privacy Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy
Description
Use the Security & Privacy group policies to control user security and privacy settings.
Disable Dictation
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Disable Dictation
Description
Enable this policy to turn off Dictation in the System Preferences > Keyboard pane.
Require a Password to Wake this Computer from Sleep or Screen Saver (Deprecated)
Note: This group policy is deprecated, and will not work anymore. Please use the new same name group policy under "Computer Configuration >
Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Require a password to wake this computer from sleep or screen
saver" instead.
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Require a password to wake this computer from sleep or
screen saver
Description
Lock the computer screen when the computer goes into sleep or screen saver mode and requires users to enter a user name and password to unlock the
screen.
Enabling this group policy is the same as clicking the Require a password to wake this computer from sleep or screen saver option in the Security
system preference.
After this group policy is enabled, it takes effect when the computer is rebooted.
Prohibit Authentication with Expired Password
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Prohibit authentication with expired password
Description
Prohibit a user from unlocking the screen if a password change is required while the screen is locked. If a user logs in with a password that must be changed,
and the computer goes into sleep or screen saver mode before the user updates the password, the user is locked out. Disabling this policy allows a user to
specify the old password to remove the screen lock.
Keychain Policies
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Keychain Policies
Description
On OS X 10.11, you can create a keychain protected by a smart card token or a password. Once the Enable smart card protected keychain group policy takes
effect, the token-protected keychain can only be unlocked with a PIN when the associated smart card is present. This group policy can be configured to allow
users who lose or forget their smart card to continue to log in with a password. In this case, a new password-protected keychain is created to ensure users
can continue to log in to their account; however, keychain items are not transferred from the token-protected keychain to the password-protected keychain.
This feature is not supported on OS X 10.10 and earlier.
Enable Protected Keychain
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Keychain Policies > Enable protected keychain
Description
Create a new keychain protected by either an asymmetric token stored on a smart card or by a password, depending on the log in type. Enabling this policy
requires users to have the smart card present to unlock the token-protected keychain.
When the smart card is renewed it will no longer unlock the protected keychain. There is no way to export a token-protected keychain; you will have to
recreate the keychain items in the new token-protected keychain. In addition, if a smart card is lost, there is no way to recover items from the token-
protected keychain.
The Set as user default keychain option is selected by default. This option is required to be able to log in with a password after this group policy takes
effect. With this option set, the default keychain will be switched based on the login type (smart card login or password login). Deselect this option to leave
the existing login keychain as the default keychain.
The Delete the Password protected ‘Login’ Keychain after login option is deselected by default. Select this option to delete the existing password-
protected ‘Login’ Keychain after logging in with a smart card, leaving no keychains that can be unlocked without a smart card. This option is required to be
able to log in with a password after this group policy takes effect without seeing keychain errors.
Note: This feature is not supported on OS X 10.10 and earlier.
Lock Protected Keychain After Number of Minutes of Inactivity
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Keychain Policies > Lock protected keychain after
number of minutes of inactivity
Description
Lock the protected keychain after a period of inactivity that you specify in minutes.
This policy only works if you have enabled the Enable protected keychain group policy.
This policy takes effect at the next user login using smart card authentication.
Lock Protected Keychain When Sleeping
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > Keychain Policies > Lock protected keychain when
sleeping
Description
Lock the protected keychain when the machine sleeps.
This policy only works if you have enabled the Enable protected keychain group policy.
This policy takes effect at the next user login using smart card authentication.
Allow All Applications to Access The Auto-Enrollment Private Key(S)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Allow all applications to access the auto-
enrollment private key(s)
Description
Enabling this policy allows all applications to access the auto-enrollment private key(s) in the System keychain.
Note: This setting only applies to new auto-enrollment private key(s); it will not update already imported auto-enrollment private key(s) that are
in the System keychain.
Allow Specific Applications to Access the Auto-Enrollment Private Key(S)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Allow specific applications to access the
Description
Enabling this policy allows specified applications to access the auto-enrollment private key(s) in System keychain.
After you enable this policy, click A d d to enter the path to the application you want to allow access to the auto-enrollment private key, then click O K. You can
click A d d again to add additional applications.
For example, to give Google Chrome and Delinea Agent access to the auto-enrollment private key, enter the application path for Google Chrome:
/Applications/Google Chrome.app
Click O K. Then click A d d and enter the application path for Delinea Agent:
/Applications/Centrify Agent.app
After this group policy is enabled, the list of applications specified in the group policy are added to the access control list of the auto-enrollment private key in
system keychain.
Note: This setting only applies to a new auto-enrollment private key. It does not change auto-enrolled private keys that are already in the
keychain.
If the group policy above, Allow All Applications to Access the Auto-enrollment Private Key(s) is enabled, this group policy will be ignored.
Do Not Allow the Private Key(S) To Be Extractable
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Public Key Policies > Do not allow private key(s) to be
extractable
Description
Enabling this policy prevents exporting the auto-enrollment private key(s).
Note: This setting only applies to new auto-enrollment private key(s). It does not change auto-enrolled private keys that are already in the
keychain.
System Preference Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > System Preference Settings
Description
Use the User Configuration > Policies > Centrify Settings > Mac OS X Settings > System Preference Settings group policies to specify which
preferences are enabled for use in System Preferences for Mac OS X users. Enabling a preference for use does not enable non-admin users to modify that
preference. For example, some preferences, such as Startup Disk preferences, require an administrator name and password before a user can modify its
settings. Displaying a preference does enable a user to view the preference’s current settings.
By default, no system preference panes are displayed unless explicitly enabled. The group policies in this category correspond to System Preferences you
can select for display in the Workgroup Manager. For example:
The user interface for System Preferences Settings differs significantly between different versions of Mac OS X. Therefore, there are separate System
Preferences policies for each supported version of Mac OS X. In addition, to support existing installations that configured group policies by using a previous
centrifydc_mac_settings template, the Centrify group policies provide a set of legacy preferences settings.
The Use Version Specific Settings group policy below determines whether to use legacy settings or platform-specific system preferences settings. By
default (if you do not configure or disable this policy) legacy settings are used.
If you enable this policy, you can then enable platform-specific system preferences settings for each platform in your environment; see the following
sections for information on each set of policies:
Use Version Specific Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > System Preference Settings > Use version specific
settings
Description
Enable the use of version-specific System Preferences settings.
If you enable this policy, you can then set platform-specific preferences settings for each platform in your environment. For example, if you have only 10.10
computers, you can enable this policy and then use Mac OS X 10.10 settings. If you have 10.9 and 10.10 computers, enable this policy, and then configure the
version-specific policies as appropriate:

When a computer joins the domain, Delinea Management Services determines the OS version and applies the appropriate Preferences settings.
If this policy is disabled or not configured, Legacy Settings are used instead of version-specific settings. Likewise, Delinea versions prior to 4.4.2 always use
Legacy Settings and ignore this policy setting.
If you configured System Preferences settings with a version of the product prior to 4.4.2, these settings are saved to Legacy Settings when you upgrade to
the current version. You can keep or edit these settings as you wish.
Note: The Legacy Settings may not match exactly the settings for each OS version; for example, some settings may be missing while others may
be redundant for a particular OS version.
Legacy Settings
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > System Preference Settings > Legacy Settings
Description
When you upgrade from a version of Delinea prior to 4.4.2, your System Preferences settings are saved to Legacy Settings. You can keep or edit the individual
legacy system preferences group policy settings as you wish.
Note: The legacy settings may not match exactly the settings for each OS version; for example, some settings may be missing while others may
be redundant for a particular OS version.
Showing items in the Personal pane

Select the items to display in the Personal pane of System Preferences.
of System Preferences
Showing items in the Hardware

Select the items to display in the Hardware pane of System Preferences.
System pane of Preferences
Showing items in the Internet &

Network pane of System Select the items to display in the Internet & Network pane of System Preferences.
Preferences
Showing items in the System pane

Select the items to display in the System pane of System Preferences.
of System Preferences
Showing items in the Other pane of

Select the items to display in the Other pane of System Preferences.
System Preferences
Limit items usage in System Limit the usage of items in System Preferences. You must enable this group policy for any of the other group policy
Preferences (deprecated) settings to take effect. Once this group policy is enabled, it takes effect when users log out and log back in.
Showing items in the Personal pane of System Preferences
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > System Preference Settings > Enable System
Preferences Pane: Personal
Description
Use the group policies in this category to choose which items to display in the Personal pane of System Preferences.
Enable Appearance
Enable usage of Appearance preferences in the Personal pane of System Preferences.
Enable Dashboard & Expose
Enable usage of Dashboard & ExposE preferences in the Personal pane of System Preferences.
Enable Desktop & Screen Saver
Enable usage of Desktop & Screen Saver preferences in the Personal pane of System Preferences.
Enable Dock
Enable usage of Dock preferences in the Personal pane of System Preferences.
Enable International (Language & Text)
Enable usage of International preferences in the Personal pane of System Preferences.
Enable Security
Enable usage of Security preferences in the Personal pane of System Preferences.
Enable Spotlight
Enable usage of Spotlight preferences in the Personal pane of System Preferences.
Showing items in the Hardware System pane of Preferences
Use the group policies in this category to display items in the Hardware pane of System Preferences.
Enable Bluetooth
Enable usage of Bluetooth preferences in the Hardware pane of System Preferences.
Enable CDs & DVDs
Enable usage of CDs & DVDs preferences in the Hardware pane of System Preferences.
Enable Displays
Enable usage of Displays preferences in the Hardware pane of System Preferences.
Enable Energy Saver
Enable usage of Energy Saver preferences in the Hardware pane of System Preferences.
Enable Ink
Enable usage of Ink preferences in the Hardware pane of System Preferences.
Note: Ink preferences are only shown if a graphics tablet is connected to the Mac computer.
Enable Keyboard & Mouse (Keyboard)
Enable usage of Keyboard & Mouse preferences in the Hardware pane of System Preferences.
Enable Mouse
Enable usage of Mouse preferences in the Hardware pane of System Preferences.
Enable Print & FAX
Enable usage of Print & FAX preferences in the Hardware pane of System Preferences.
Enable Sound
Enable usage of Sound preferences in the Hardware pane of System Preferences.
Enable Trackpad
Enable usage of Trackpad preferences in the Hardware pane of System Preferences.
Showing Items in the Internet & Network Pane of System Preferences
Path
Preferences Pane: Internet & Network
Description
Use the group policies in this category to display items in the Internet & Network pane of System Preferences.
Enable .Mac (MobileMe)
Enable usage of .Mac preferences in the Internet & Network pane of System Preferences.
Enable Fibre Channel
Enable usage of Fibre Channel preferences in the Internet & Network pane of System Preferences.
Enable Network
Enable usage of Network preferences in the Internet & Network pane of System Preferences.
Enable QuickTime
Enable usage of QuickTime preferences in the Internet & Network pane of System Preferences.
Enable Sharing
Enable usage of Sharing preferences in the Internet & Network pane of System Preferences.
Showing items in the System pane of System Preferences
Path
Preferences Pane: System
Description
Use the group policies in this category to display items in the System pane of System Preferences.
Enable Accounts
Enable usage of Accounts preferences in the System pane of System Preferences.
Enable Classic
Enable usage of Classic preferences in the System pane of System Preferences.
Enable Date & Time
Enable usage of Date & Time preferences in the System pane of System Preferences.
Enable Parental Controls
Enable usage of Parental Controls preferences in the System pane of System Preferences.
Enable Software Update
Enable usage of Software Update preferences in the System pane of System Preferences.
Enable Speech
Enable usage of Speech preferences in the System pane of System Preferences.
Enable Startup Disk
Enable usage of Startup Disk preferences in the System pane of System Preferences.
Enable Time Machine
Enable usage of Time Machine preferences in the System pane of System Preferences.
Enable Universal Access
Enable usage of Universal Access preferences in the System pane of System Preferences.
Showing Items in the Other Pane of System Preferences
Path
Preferences Pane: Other
Description
Use the group policies in this category to display the items you specify in the Other pane of System Preferences.
Other Preferences Panes
Enable usage of additional preferences panes of System Preferences.
System Preferences Mac OS X 10.5 Settings (deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > System Preference Settings > Mac OS X 10.5 Settings
Description
If your environment does not contain Mac OS X 10.5 computers, you can ignore the group policies in this folder.
Path
Description
If your environment does not contain Mac OS X 10.6 computers, you can ignore the group policies in this folder.
Path
Description
The Mac OS X 10.7 Settings allow you to configure system preferences policies that apply specifically to Mac OS X 10.7 computers. Because the user
interface varies between different versions of Mac OS X, separate policies are provided for each version. See Legacy Settings, above, for older versions of
Mac OS X.
If your environment does not contain Mac OS X 10.7 computers, you can ignore these settings.
Limit Items Usage in System Preferences (deprecated)
Path
User Configuration > Policies > Centrify Settings > Mac OS X Settings > Security & Privacy Settings > System Preference Settings > Mac OS X 10.7 Settings >
Limit items usage in System Preferences
Description
Limit the usage of items in the System Preferences panel.
Enable System Preferences Panes 10.7 (deprecated)
Path
Enable System Preferences Panes
Description
Use Enable built-in System Preferences Panes, below, to select the items to add to the standard System Preferences panes.
Use Enable other System Preferences Panes, below, to add preferences for third-party applications to the Other pane of the System Preferences.
Enable Built-in System Preferences Panes (deprecated)
Path
Enable System Preferences Panes > Enable built-in System Preferences Panes
Description
Select items to add to the System Preferences panel.
This policy is only effective if the Limit items usage in System Preferences group policy, above, is enabled. Otherwise this group policy is ignored.
Enable Other System Preferences Panes (deprecated)
Path
Enable System Preferences Panes > Enable other System Preferences panes
Description
Define a list of additional items to add to the Other pane of the System Preferences panel.
Preference pane applications are actually collections of files inside a directory (called bundles). Inside the Contents directory of every preference pane
application is the info.plist file, and inside that file is the CFBundleIdentifier key that identifies the preference pane application. You need to use the value for this
key when adding a preference pane application.
Generally, installed third party preference panes can be found in /System/Library/PreferencePanes, /Library/PreferencePanes or ~/Library/PreferencePanes.
You can find the CFBundleIdentifier key by using the defaults command. For example, to find the value for the QuickTime pane, use the following command in a
terminal window:
defaults read /System/Library/PreferencePanes/QuickTime.prefPane /Contents/info CFBundleIdentifier
which returns:
com.apple.preference.quicktime
To display the QuickTime icon in the Other pane of the System Preferences Panel, enable this policy, then click A d d and enter com.apple.preference.quicktime.
This policy is effective only if the Limit Items Usage on System Preferences group policy, below, is enabled. Otherwise, this group policy is ignored.
Path
Description
interface varies between different versions of Mac OS X, separate policies are provided for each version. See Legacy Settings for older versions of Mac OS X.
Path
Description
Enable System Preferences Panes 10.8 (deprecated)
Path
Enable System Preferences Panes
Description
Use Enable Built-in System Preferences Panes, below, to select the items to add to the standard System Preferences panes.
Use Enable Other System Preferences Panes, below, to add preferences for third-party applications to the Other pane of the System Preferences.
Path
Enable System Preferences Panes > Enable built-in System Preferences panes
Description
This policy is effective only if the Limit Items Usage on System Preferences group policy is enabled. Otherwise, this group policy is ignored.
Path
Description
Generally, installed third party preference panes can be found in /System/Library/PreferencePanes, /Library/PreferencePanes, or ~/Library/PreferencePanes.
terminal window:
which returns:
To display the QuickTime icon in the Other pane of the System Preferences Panel, enable this policy, then click A d d and enter com.apple.preference.quicktime.
Path
Description
interface varies between different versions of Mac OS X, separate policies are provided for each version. See Legacy Settings, above, for older versions of
Mac OS X.
Path
Description
Path
Enable System Preferences Panes > Enable built-in System Preferences panes
Description
Path
Description
terminal window:
which returns:
To display the QuickTime icon in the Other pane of the System Preferences Panel, enable this policy, then click A d d and enter
com.apple.preference.quicktime.
System Preferences Mac OS X 10.10 or Above Settings
Path
Description
The Mac OS X 10. 10 or above Settings allow you to configure system preferences policies that apply specifically to Mac OS X 10.10 and above computers.
Because the user interface varies between different versions of Mac OS X, separate policies are provided for each version. See Legacy Settings, above, for
other versions of Mac OS X.
If your environment does not contain Mac OS X 10.10 or above computers, you can ignore these settings.
Limit Items Usage on System Preferences
Path
> Limit items usage on System Preferences
Description
Enable System Preferences Panes 10.10
Path
> Enable System Preferences Panes
Description
Use Enable other System Preferences Panes, below, to add preferences for third-party applications to the Other pane of the System Preferences.
Enable Built-in System Preferences Panes
Path
> Enable System Preferences Panes > Enable built-in System Preferences panes
Description
Enable this group policy to enable the built-in System Preferences panes.
Enable or disable usage of items in the built-in System Preferences panes by checking or unchecking boxes corresponding to the items.
This policy is effective only if the Limit Items Usage on System Preferences group policy, above, is enabled. Otherwise, this group policy is ignored.
Enable Other System Preferences Panes
Path
> Enable System Preferences Panes > Enable other System Preferences panes
Description
terminal window:
which returns:
To display the QuickTime icon in the Other pane of the System Preferences Panel, enable this policy, then click A d d and enter
com.apple.preference.quicktime.
This policy is effective only if the Limit Items Usage on System Preferences group policy, above, is enabled. Otherwise, this group policy is ignored.
Configuring a Mac Computer for Smart Card Login
This section explains how to set up smart card login for a Mac computer:
Understanding Smart Card Login Supported Smart Card Types Configuring Smart Card Login Using smart card login Troubleshooting Smart Card Login Other
Functions of Smart Card Support on macOS Known Issues of Using SmartC with macOS
Understanding Smart Card Login
Smart cards provide an enhanced level of security authentication for logging into an Active Directory domain. To configure a smart card for use on a Mac
computer that is running the DirectControl agent, requires that you have already set up a smart card for use in a Windows domain. You do not need to add any
smart card infrastructure to the Mac computer, other than a smart card reader and a provisioned smart card.
If you have set up smart card login for Windows clients in a domain, you can use Access Manager to configure smart card login for Mac clients joined to the
same domain. If you have provisioned a smart card for use on a Windows computer once you configure smart card support for a Mac computer, you can use
the same smart card to log in to a Mac computer.
Supported Smart Card Types
Delinea Smart Card Support for MacOS is based on the MacOS modern native framework, CryptoTokenKit. TokenD is no longer supported.
For macOS 10.15 and later, Delinea supports personal identity verification (PIV) smart cards, USB CCID class-compliant readers, and hard tokens that support
the PIV standard.
Configuring Smart Card Login
Delinea provides group policies, configuration options, and account options to perform the smart card configuration tasks desribed below.
Note: Before configuring smart card login, refer to the next section, Verifying Prerequisites for Configuring Smart Card Login to ensure
your environment meets all the prerequisites.
Verifying Prerequisites for Configuring Smart Card Login
Make sure that your smart card is supported by MacOS.
MacOS 10.15 and later supports personal identity verification (PIV) smart cards, USB CCID class-compliant readers, and hard tokens that support the
PIV standard.
Provision a smart card with an NT principal name and PIN.

Verify that the Active Directory user’s UPN matches the UPN on the smart card.
Make sure that there are at least two certificates in your smart card; these two certificates are for two different purposes: "Signature and
smartcard logon" and "Encryption." MacOS will use the certificate which purpose is "Signature and smartcard logon" to logon, and use the
certificate which purpose is "Encryption" to encrypt and decrypt the user's Keychain automatically. If there is no certificate which is for
"Encryption", the user will need to input the Keychain password every time when that they log in.
Make sure that your smart card is able to log in to a Windows computer.
If a user is able to log in to a Windows computer with a smart card, and you have a card reader and a fully-provisioned card for the Mac computer, the
user should be able to log in to the Mac computer once you configure it for smart card support.
Enabling Smart Card Support
To enable smart card support for logging on
1. Make sure that you have configured the Delinea Agent to have full disk access.
2. Create or edit an existing Group Policy Object linked to a site, domain, or OU that includes Mac computers.
3. In the Group Policy Management Editor, expand Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Security &
Privacy, then double-click Enable smart card support.
4. Select Enabled to enable smart card support.
5. Select any of the following smart card options:
Enable smart card support for the SUDO command: When executing the SUDO command, the smart card user can authenticate by
entering their smart card PIN.
Enable smart card support for the SU command: When executing the SU command, the smart card user can authenticate by entering
their smart card PIN.
Enable smart card support for the LOGIN command: When executing the LOGIN command, the smart card user can authenticate by
entering their smart card PIN.
Enforce smart card login: Users can only log in to the Mac computer by way of smart card login.
Exception group: Any users who belong to this group can always log in to the Mac computer with user name and password (no smart card
required). In general, we recommend that you set an exception group, such as admins, when you select the option to enforce smart card login.
Certificate trust behavior: You can select one of these numbers to set smart card certificate behavior. The numbers mean the following:
0: Smart card certificate trust isn’t required.
1: Smart card certificate and certificate chain must be trusted.
2: Certificate and certificate chain must be trusted and not receive a revoked status.
3: Certificate and certificate chain must be trusted and revocation status is returned valid.
6. Because smart card login is not password-based, do not enable the "Enable Keychain synchronization" group policy: Computer Configuration >
Policies > Centrify Settings > Mac OS X Settings > Security & Privacy > Enable Keychain synchronization
7. If FileVault is enabled on your Mac, please enable the "Disable automatic login" group policy: Computer Configuration > Policies > Centrify Settings >
Mac OS X Settings > Security & Privacy > FileVault2 > Disable automatic login.
The policy takes effect dynamically at the next group policy refresh interval or after you run adgpupdate.
Verifying Smart Card Configuration
After enabling smart card support as described above in Configuring Smart Card Login, do the following to verify that a smart card is working:
1. Insert the smart card into the reader.
2. Open the Terminal.app and run the following command:
% sc_auth identities
You should see that the smart card has paired to the Active Directory user. For example:
SmartCard: com.apple.pivtoken:00000000000000000000000000000000
Paired identities which are used for authentication:
9800A35AD2A41AEFB03CF431B76BA194E22F48EE pivau1 - Certificate For PIV Authentication (PIV AU 1)
Note: You never need to pair your smart card manually. If you see the following SmartCard Pairing dialog, that means that the smart card support
is not ready. Please re-check the smart card support GP and then excute the command adgpupdate.
Enabling the Sscreen Saver for Smart Card removal
Currently, we don't have a group policy to enable the screen saver when the smart card is removed. Please use the group policy entitled "Specify multiple
login scripts" to deploy the following script:
#!/bin/bash
user_name=`ls -l /dev/console | cut -d " " -f 4`
defaults write /Users/$user_name/Library/Preferences/com.apple.screensaver tokenRemovalAction -int 1
chown $user_name:staff /Users/$user_name/Library/Preferences/com.apple.screensaver.plist
exit 0
The script sets the Mac to start the screen saver automatically when the smart card is removed.
To disable smart card support:
1. Edit the Group Policy Object linked to a site, domain, or OU that includes Mac computers, expand Computer Configuration > Policies > Centrify
Settings > Mac OS X Settings > Security & Privacy, then double-click Enable smart card support.
Using Smart Card Login
When a user inserts a smart card into the card reader attached to a Mac computer that is waiting for login, the login screen is replaced by a smart card
enabled login screen.
To log in with a smart card:
1. Insert the smart card into the smart card reader.
A login screen displays, prompting you to enter your PIN.
2. If the "Configure mobile account creation" group policy is enabled, you are prompted to create a mobile account.
If the Bypass the SecureToken dialog is not enabled, after creating the mobile account, you are prompted to authenticate the SecureToken.
3. The system will then prompt you to set a password for Keychain.
The password can be the same as or different than your Active Directory password. For security reasons, the password here should not be the same as
your smart card PIN.
If you have problems with smart card logon, Access Manager provides a command-line tool, sctool, which you can run to configure smart card logon, as well as
to provide diagnostic information. See the sctool man page.
Additional smart card diagnostic procedures are provided in Diagnosing Smart Card Login Problems.
Other Functions of Smart Card Support on MacOS
MacOS 10.15 includes built-in support for the following capabilities:
Authentication: LoginWindow, PKINIT, SSH, Screensaver, Safari, authorization dialogs, and in third-party apps supporting CTK
Signing: Mail and third-party apps supporting CTK
Encryption: Mail, Keychain Access, and third-party apps supporting CTK
For more information, please see https://support.apple.com/guide/deployment-reference-macos/intro-to-smart-card-integration-

apd1fa5245b2/1/web/1.0.
Known Issues of Using Smart Cards with Macos
Due to a limitation of MacOS, a smart card user cannot get the User Group Policy automatically. The Computer Group Policy works normally. The workaround
is to run the following commands after logging in with a smart card:
% sctool -k
% adgpupdate
After you run the above commands, log out and log back in. Most User Group Policy should work normally.
Troubleshooting Tips
This section provides troubleshooting tips for administrators using the Delinea DirectControl Agent for Mac.
Using Common Account Management Commands Viewing the Agent Version on the Macs Joined to Active Directory Enabling Logging for the Delinea
Directcontrol Agent for Mac Enabling Logging for the Mac Directory Service Using the Agent on a Dual-Boot System Using Adgpupdate Appropriately
Understanding Delays when Logging On the First Time with a New User Account Configuring Single-Sign On to Work with Non-Mac Computers Restricting
Login Using FTP Logging On Using Localhost Changing the Password for Active Directory Users Disabling the Apple Built-In Active Directory Plug-In Showing
the Correct Status of the Delinea Plug-In Resolving VPN Access Issues with Mac OS X 10.7 and Later Diagnosing Smart Card Log In Problems Opening a
Support Case Online Collecting Information for Support Cases
Using Common Account Management Commands
Most UNIX-based platforms store account information in the local /etc/passwd file, and use commands such as getent command to query that information.
On Mac computers, however, you would typically use the Directory Service application to manage local accounts and retrieve user information. For
troubleshooting purposes, therefore, you should be familiar with the commands to use for retrieving information about Active Directory users and groups.
The following table describes several common Directory Service Command Line (dscl) commands that you may find useful.
Use this command To do this
dscl /Search –list /Users List all of the users in the Directory Service and in Active Directory for the zone.
dscl /CentrifyDC –list /Users List only the Active Directory users enabled for the zone.
dscl /CentrifyDC –read /Users/username Display detailed information about the specified Active Directory username.
dscl /Search –list /Groups List all of the groups in the Directory Service and in Active Directory for the zone.
dscl /CentrifyDC –list /Groups List only the Active Directory groups enabled for the zone.
dscl /CentrifyDC –read /Groups/groupname Display detailed information about the specified Active Directory groupname.
To get detailed information for all users or groups recognized on the Mac computer, you can use the following commands:
lookupd –q user –a name
lookupd –q group –a name
To get detailed information for a specific user or group, you can use the following commands:
lookupd –q user –a name username
lookupd –q group –a name groupname
To clear the Directory Service cache, you can use the following command:
lookupd -flushcache
To completely clear the cache of Active Directory login credentials, you should also run the `adflush command:
adflush
To retrieve Mac OS version and build information that uname -a does not provide, you can run the following command:
/usr/bin/sw_vers
Viewing the Agent Version on the Macs Joined to Active Directory
You can use the Active Directory module for Windows PowerShell to view the version of the Delinea DirectControl Agent for Mac on the Macs joined to your
AD domain. This is useful to verify that all Macs joined to your AD have an appropriate version of the Delinea DirectControl Agent for Mac to avoid
compatibility issues with OS updates.
Install the Active Directory Module for Windows PowerShell
The Active Directory module for Windows PowerShell is already installed on domain controllers. If you are using a member server, you will have to install it.
To install the Active Directory module for Windows PowerShell
Open an elevated PowerShell session on a Windows server in the domain and run the following command:
Add-WindowsFeature RSAT-AD-PowerShell
When the installation finishes it returns the following:
Once installed, on Windows Server 2012 and 2012 R2 the module automatically loads when you use one of its cmdlets; you do not need to import it.
Show PowerShell Output of Agent Versions for AD-joined computers
If you have a small environment, or just want to see a sample of the information that will be in the report, run the following from a Windows server with the AD
PowerShell module installed:
Get-ADComputer -Filter * -Properties OperatingSystem,OperatingSystemServicePack | Format-Table Name,OperatingSystem,OperatingSystemServicePack -wrap -auto
For example:
The report includes all AD-joined computers in the domain. The example above shows a mix of Windows, Linux, and Mac computers. Where
OperatingSystemServicePack is empty, it means there is no Service Pack installed (Windows computers), or there is no DirectControl agent installed (Mac or
Linux/Unix).
In most cases there are too many computers for the PowerShell output to be easily readable. In these cases, refer to the next section, Export the Report
of Agent Versions to a CSV File.
Export the Report of Agent Versions to a CSV file
You can export a report of Delinea DirectControl Agent for Mac versions on AD-joined computers to a CSV file for easier manipulation by running the
following:
Get-ADComputer -Filter * -Properties OperatingSystem,OperatingSystemServicePack | Select-Object Name,OperatingSystem,OperatingSystemServicePack | Export-CSV CDCVersion.csv -

NoTypeInformation -Encoding UTF8
In this example, PowerShell exports the data described above in Show PowerShell Output of Agent Versions for AD-joined Computers to a CSV
file named CDCVersion.csv in the current directory. You can then open that CSV file using a spreadsheet application such as Excel to more easily analyze the
data.
Enabling Logging for the Delinea DirectControl Agent for Mac
The Delinea DirectControl Agent for Mac installation includes some basic diagnostic tools and a logging mechanism to help you trace the source of problems
if they occur. These diagnostic tools and log files allow you to periodically check your environment and view information about the agent operation, your
Active Directory connections, and the configuration settings for individual computers.
In most cases, logging is not enabled by default for performance reasons. Once enabled, however, log files provide a detailed record of Delinea DirectControl
Agent for Mac activity and can be used to analyze the behavior of Delinea Management Services and communication with Active Directory to locate points of
failure.
For performance and security reasons, you should only enable agent logging when necessary, for example, when requested to do so by Delinea Corporation
Technical Support, and for short periods of time to diagnose a problem. Keep in mind that sensitive information may be written to this file and you should
evaluate the contents of the file before giving others access to it.
You can enable logging either by using the cdcdebug command or the Delinea for Mac Diagnostic Tool application.
To enable logging with the cdcdebug command:
1. Log in to the Mac as Local Admin and open the Terminal.
2. Run the following commands to clear and then enable the Delinea DirectControl Agent for Mac log file:
% sudo /usr/local/share/centrifydc/bin/cdcdebug clear
% sudo /usr/local/share/centrifydc/bin/cdcdebug on
3. Record the start time point:
% date +%s
For example: the output is 1610614011, please remember this output, it is the start time point.
4. Log out of the local admin user account.
5. Reproduce the issue: try to log in as the affected Active Directory user. Let it fail.
6. Log back in as Local Admin and open the Terminal again.
7. Record the end time point:
% date +%s
For example: the output is 1610614043, please remember this output, it is the end time point)
8. Enter the following commands to collect the Delinea DirectControl Agent for Mac log file:
% sudo /usr/local/share/centrifydc/bin/cdcdebug -f pack [affected_AD_user_name] [start_time_point] [end_time_point]
% adquery user -A [affected_AD_user_name] > /tmp/adquery.log
9. Send us the following files for analysis:
/var/centrify/tmp/cdcdebug.tar.gz
/tmp/adquery.log
10. Disable the Delinea DirectControl Agent for Mac log:
% sudo /usr/local/share/centrifydc/bin/cdcdebug off
To enable logging with the Delinea for Mac Diagnostic Tool:
1. Log in to the Mac as Local Admin and open the application MacDiagnosticTool.app.
The location of this app is “/Library/Application Support/Centrify/MacDiagnosticTool.app.” You can run the following command to open it:
% open /Library/Application Support/Centrify/MacDiagnosticTool.app
2. Click the Debug/Logs tab.
3. Click 0. Clear Debug Log Files.
4. Click 1. Enable Debugger.
5. Click 2. Get Start Time Point.
Note: You do not need to remember the start time point; it will be saved automatically.
6. Click Q u i t to close the application.
7. Log out of the Local Admin account.
8. Reproduce the issue: try to log in as the affected Active Directory user. Let it fail.
9. Log back in as Local Admin and open the application MacDiagnosticTool.app again.
10. Click 4. Get End Time Point and enter input the affected Active Directory user name.
11. Click 5. Save Debug Log Files to Desktop, the tool will start to collect agent log files.
Note: You might see a message display about installing the “otool” command; you can select Cancel or Install; either choice works.
The log file “CENTRIFY_FULL_LOG_PACK.zip” will be on the Desktop. Send the file to Delinea Technical Support for analysis.
12. Click 6. Disable Debugger, then click Q u i t to close the application.
Enabling Logging for the Mac Directory Service
In addition to enabling logging for the agent, you may find it necessary to enable logging for the Open Directory Service.
To create a log file for the Open Directory Service:
1. Log in as or switch to the root or admin user.

odutil set log debug
After running this command, you can find the resulting log files at: /var/log/opendirectoryd.log*. You can then provide both the agent log file and the Directory
Service log file to Delinea Support if you need assistance troubleshooting issues.
Using the Agent on a Dual-boot System
If you are using a dual-boot system, and the computer name is the same for each version of the operating system, the Delinea DirectControl Agent for
Mac(adclient) will not launch when you reboot and switch operating systems. The problem is that each operating system sets its own password for adclient and
the password does not work for the other operating system.
The best way to avoid this problem is to provide a different computer name for each operating system. Because the computer names are different, the
password for one operating system is not changed by the other operating system.
If you want to use the same computer name for both operating systems, you can work around the problem, as follows:
1. Leave the domain (adleave) before rebooting and switching operating systems.
Note: You may leave and join the domain after rebooting and switching the operating system. However, you will experience some delay while
adclient attempts to launch and fails.
2. Reboot with the other operating system.
3. Rejoin the domain (adjoin).
Using adgpupdate Appropriately
If adgpupdate is run multiple times in succession, it is possible that not all group policies will be applied correctly. To avoid this problem, do not run adgpupdate
more than once per minute.
Understanding Delays when Logging on the First Time with a New User Account
Depending on the configuration of your startup services, you may find that new users are unable to log on to a computer immediately (within the first 15 to 30
seconds) after a computer is rebooted.
By default, the Mac login window only requires the Disks and SecurityService startup services to start successfully to prompt for the user to log in. Authenticating
users to Active Directory, however, requires the additional DirectoryServices startup service to be available. Starting the DirectoryServices startup service causes a
10 to 15 second delay before the LoginWindow can successfully authenticate new Active Directory users.
Configuring Single-sign on to Work with Non-Mac Computers
On a Mac computer, the ssh client does not forward (delegate) credentials to the server by default. Therefore, when attempting to use ssh from a Mac
computer with DirectControl agent installed to a non-Mac computer with DirectControl agent installed, single sign-on (SSO) does not work. To fix this
problem, set the configuration parameter, GSSAPIDelegateCredentials, to yes in the /etc/ssh_config file on the Mac computer.
Restricting Login Using FTP
In Active Directory, you can set properties to prevent a user from logging in to other Macintosh computers. However, this restriction will not prevent a user
from logging in via FTP to Macintosh computers with the DirectControl agent installed. It does restrict logging in with telnet, ssh, rlogin, and rsh.
Logging on Using localhost
For many UNIX platforms, you can log on using localhost to refer to the local computer; for example:
root@localhost
This syntax does not work when logging on to a Macintosh computer, whether using the Macintosh UI, or remotely through ssh or FTP.
Changing the Password for Active Directory Users
In the Mac OS X, the passwd command authenticates the user only after you type the user password. Because of this, the passwd command does not recognize
the user as an Active Directory user until after the password is entered and the password prompts defined for Active Directory users, which are typically set
through group policy or by modifying the Delinea configuration file, are not displayed. You can still use the passwd or chpass command to change the Active
Directory password for a user, but you will not see any visual indication that you are modifying an Active Directory account rather than a local user account.
Disabling the Apple Built-in Active Directory Plug-in
Apple provides a built-in Apple Directory plug-in that may interfere with the Delinea DirectControl Agent for Macinstallation and operation. Therefore, before
installing the agent, disable Apple’s built-in Active Directory plug-in. In addition, remove Active Directory from the Authentication and Contacts search paths.
If this plug-in is enabled and the Delinea DirectControl Agent for Mac has been installed, disable the plug-in, then reboot the Macintosh computer for reliable
operation.
To disable the Apple Directory plug-in and remove Apple Directory from the Authentication and Contacts search paths:
1. On a Mac computer, open the Directory Utility.
You can find the Directory Utility in one of these folders depending on the operating system that you are running:
/System/Library/CoreServices
/Applications/Utilities
2. Click the lock icon and enter credentials to allow you to make changes.
3. Click the Search Policy icon.
4. Click the Authentication tab, then select Custom path in the Search box.
If Active Directory was previously enabled, Active Directory appears in the Directory Domains box; for example:
/Active Directory/All Domains
5. Select /Active Directory/All Domains and click Remove — or select the minus - sign). Then click Apply.
6. Click the Contacts tab, then select Custom path in the Search box. If Active Directory was previously enabled, Active Directory shows (in red font) in
the Directory Domains box; for example:
/Active Directory/All Domains
7. Select /Active Directory/All Domains and click Remove. Then click Apply.
8. Close the window.
9. If you have already installed the Delinea DirectControl Agent for Mac, reboot the computer.
Showing the Correct Status of the Delinea Plug-in
The Delinea plug-in is automatically added to the list of Apple Directory Utility plug-ins that are used for lookup and authentication. However, if the Apple
Directory Utility tool is running when you install the Delinea DirectControl Agent for Mac, or when you join or leave a domain before updating to a new version
of the agent, it will incorrectly display the status of the plug-in. For example, it will show the status as disabled, when in fact, the plug-in is enabled.
To avoid this problem, before launching the installer, be certain that the Apple Directory Utility tool is closed.
If the Directory Utility was open during installation, simply close and re-open Directory Utility, then make certain that the Delinea plug-in is enabled.
You may also restart the Delinea plug-in from the command line, as follows:
1. Close the Directory Utility.
2. Open a terminal.
3. Enter the following command:
/usr/local/share/centrifydc/bin/dsconfig restart
4. Open the Directory Utility. The status of Delinea should be enabled.
Resolving VPN Access Issues with Mac OS X 10.7 and Later
Starting with Mac OS X 10.7, /etc/resolv.conf is no longer used for domain controller name resolution. Therefore, some VPN programs no longer update DNS
server information in /etc/resolv.conf when signing on. On computers running Mac OS X 10.7 and later, this can result in the computer not being able to connect
to a domain controller through a VPN.
To resolve this issue, explicitly specify in centrifydc.conf the location of DNS servers that are used to resolve domain controller names:
1. Open /etc/centrifydc/centrifydc.conf for editing.
2. Specify the IP addresses of DNS servers in the dns.servers parameter (if the parameter does not exist yet, create it now):
dns.servers: x.x.x.x y.y.y.y
where x.x.x.x y.y.y.y are the IP addresses of the DNS servers to use. This example shows two IP addresses; note that each IP address is separated by a
space.
3. Save your changes to centrifydc.conf.
4. Restart the agent for the changes to take effect:
sudo /usr/local/share/centrifydc/bin/centrifydcrestart
Diagnosing Smart Card Login Problems
Two general methods for diagnosing smart card log in problems are provided:
By using the sctool utility as described in the sctool man page.

By performing the diagnostic procedures described in this section.
The following procedures are intended to diagnose multiple causes of smart card log in failure. It is recommended that you retest smart card login at regular
intervals (such as after each step) as you perform this procedure.
1. Ensure that macOS built-in PIV token is not disabled.
% defaults read /Library/Preferences/com.apple.security.smartcard DisabledTokens
It should not exist.
2. Ensure that smart card support is enabled.
% sctool -s
It should show that smart card support is enabled.
3. Ensure that the smart card can be recognized by MacOS.
% sc_auth identities
It should show your card and the card has been paired to the Active Directory user.
4. Collect support information.
% sctool -S
Send the file /tmp/sctool.support to Delinea Support.
Opening a Support Case Online
If you need assistance with troubleshooting an issue, you may need to open a case with Delinea Support. Before opening a new case, Delinea recommends
searching the Delinea Support Portal to see if your problem is a known issue or something for which there is a recommended solution.
To search the Delinea Support Portal
1. Open https://www.delinea.com/support/ in a Web browser.
2. Click in the search field and type one or more key words to describe the issue, then click the search icon to view potential answers to your question.
If your issue is not covered in one of the search results, you should open a case with Delinea Support.
To open a new support case
1. Log in to the Delinea support portal.
2. Click Manage Cases, then click Open a New Support Case.
The NEW CASE DETAIL page appears.
3. Enter your case details, then click Next.
Provide as much information as possible about your case, including the operating environment where you encountered the issue, and the version of the
Delinea product you are working with.
A new page appears showing Suggest Knowledge Articles and Technical Resources. You can click Show More to see additional resources that might
solve your problem.
4. Click No Thanks, Submit a Case to open a new case.
Collecting Information for Support Cases
To help ensure your issue gets resolved quickly and efficiently, gather as much information about your working environment as possible. See the information
below in these two sections:
Collecting general information about your environment

Collecting information specific to login events
Collecting Information Specific to Smart Card Login Failure
Collect the following information prior to opening a support case related to smart card log in failure:
The smart card type (for example, PIV, CAC, CACNG, and so on), manufacturer, and model.
A screen image of the smart card and its certificates in Keychain Access.
The following log files:
/tmp/sctool_D.log
/tmp/adquery.log
/tmp/tokendfolder.log
/var/Centrify/tmp/adinfo_support.tar.gz
To generate these logs, run the following commands while logged in as the local administrator:
sctool -D > /tmp/sctool_D.log
adquery user -A username_of_smartcard_user > /tmp/adquery.log
sudo ls -l /System/Library/Security/tokend/ > /tmp/tokendfolder.log
sudo adinfo -t
Collecting General Information about Your Environment
Take the following steps to gather information about your working environment before opening a support case.
1. Verify that the DirectControl agent is running on the computer where you have encountered a problem. For example, run the following command:
ps aux | grep adclient
If the adclient process is not running, check whether the watchdog process, cdcwatch, is running:
ps aux | grep cdcwatch
The cdcwatch process is used to restart adclient if it stops unexpectedly.
Note: The commands in the following three steps must be run as root or with the sudo command.
2. Enable logging for the DirectControl agent; for example:
sudo /usr/local/share/centrifydc/bin/cdcdebug on
Note: Login events are captured in /var/log/centrifydc-login.log by default. Turning on cdcdebug captures login events in /var/log/centrifydc.log.
3. Create a log file for the Mac Directory Service. For example:
To enable logging for opendirectoryd:
odutil set log debug
To disable logging for opendirectoryd when sufficient log information is collected:
odutil set log default
4. Duplicate the steps that led to the problem you want to report. For example, if an Active Directory user can’t log in to a managed system, attempt to log
the user in and confirm that the attempt fails. Be sure to make note of key information such as the user name or group name being used, so that Delinea
Support can identify problem accounts more quickly.
5. Verify that log file /var/log/centrifydc.log or /var/adm/syslog/centrifydc.log exists and contains data.
6. Run the cdcdebug command to generate logs that describe the domain and current environment; for example:
sudo /usr/local/share/centrifydc/bin/cdcdebug -f pack username
The following log files are created in /var/centrify/tmp when you execute the cdcdebug command:
adinfo_support.tar.gz
adinfo_support.txt
cdcdebug.tar.gz
dump_cache_error.log
stacktrace.txt
7. If there is a core dump during or related to the problem, save the core file and inform Delinea Support about it. Delinea Support may ask for the file to be
uploaded for review.
If the core dump is caused by a Delinea process or command, such as adclient or adinfo, open the /etc/centrifydc/centrifydc.conf file and change the
adclient.dumpcore parameter from never to always and restart the agent:
sudo /usr/local/share/centrifydc/bin/centrifydcrestart
Note: For more information about starting and stopping the agent, see the Administrator’s Guide for Linux and UNIX.
8. If there is a cache-related issue, Delinea Support may want the contents of the /var/centrifydc directory. You should be able to create an archive of the
directory, if needed.
9. If there is a DNS, LDAP, or other network issue, Delinea Support may require a network trace. You can use Ethereal to create the network trace from
Windows or UNIX. You can also use Netmon on Windows computers.
10. Create an archive (for example, a .tar or .zip file) that contains all of the log files and diagnostic reports you have generated, and add the archive to your
case or send it directly to Delinea Support.
11. Consult with Delinea Support to determine whether to turn off debug logging. If no more information is needed, run the following commands, which must
be run as root or with sudo:
odutil set log default
sudo /usr/local/share/centrifydc/bin/cdcdebug off
Collecting Information Specific to Login Events
Login events are captured in /var/log/centrifydc-login.log by default. If you enable logging for the DirectControl agent by turning on cdcdebug, login events are then
captured in /var/log/centrifydc.log.
The /var/log/centrifydc-login.log grows to a maximum size of 50M before it is compressed. When all compressed centrifydc-login.log files combined with the current log
file exceed 250M, the oldest compressed log is replaced.
Installing and Removing the Agent and Leaving a Domain
This section shows other methods of installing the agent besides the standard method using the package installer (DMG file); see Installing the Delinea
DirectControl Agent for Mac. It also shows how to remove the agent and how to join and leave a domain.
Installing Using the install.sh Script
Installing Silently on a Remote Computer
Uninstall from the Delinea System Preferences Pane
Run the uninstall.sh Script
Leaving an Active Directory Domain
Installing Using the install.sh Script
This section explains how to install using the install.sh script. This method is recommended for experienced UNIX administrators who are familiar with UNIX
command-line installations. Otherwise, you should install by using the graphical user interface, which is described in Installing the Delinea DirectControl
Agent for Mac.
To install using the install.sh command-line program:
Note: Before launching the installer, be certain that Apple Directory Utility is closed. If it is open while running the installer, it causes the Delinea
Directory Access plug-in to show the incorrect status, that is, it shows that the plug-in is disabled when in fact it is enabled.
1. Log on with a valid user account.
Note: You are not required to log on as the root user on, but you must know the password for the Administrator account to complete the
installation.
2. Mount the CD-ROM device using the appropriate command for the local computer’s operating environment, if it is not automatically mounted.
3. Change to the appropriate directory on the CD or on the network where the DirectControl agent package is located. For example, change to the
Agent_Mac directory.
4. Run the install.sh script to start the installation of the Delinea software on the local computer’s operating environment. For example:
sudo ./install.sh
Before beginning the installation, the install.sh script runs the ADCheck utility, which performs a set of operating system, network, and Active Directory
checks to verify that the Mac computer meets the system requirements necessary to install the Delinea DirectControl Agent for Mac and join an Active
Directory domain.
5. Review the results of the checks performed. If the target computer, DNS environment, and Active Directory configuration pass all checks with no
warnings or errors, you should be able to perform a successful installation and join. If you receive errors or warnings, correct them before proceeding
with the installation.
want to join a domain or restart the local computer automatically at the conclusion of the installation.
When installation is complete, see Understanding the Directory Structure below for a description of the directories and files installed for Centrify.
Installing Silently on a Remote Computer
You can install the agent silently on a remote Mac computer in either of these ways:
By using sudo commands from the command line. If you use this method, no user interaction on the target Mac computer is required. See the section
below, Installing Remotely on a Mac Computer Using sudo Commands.
By using Apple Remote Desktop. This method requires that you have Apple Remote Desktop 3 for remote software distribution. See the section below,
Installing Remotely on a Mac Computer Using Apple Remote Desktop.
If you use this method to install version 5.1.0 of the agent, the Delinea Join Assistant launches on the target Mac computer after the installation
completes, and a user must interact with the Delinea Join Assistant to complete the join process. This limitation exists only in version 5.1.0 of the agent.
Earlier versions of the agent (that is, 5.0.x and lower) and later versions (5.1.1 and above) do not have this limitation, and can be installed using Apple
Remote Desktop without any user interaction on the target Mac computer.
Installing Remotely on a Mac Computer Using Sudo Commands
Perform the following steps to use sudo commands to install the agent remotely on a target Mac computer without requiring any user interaction on the target
Mac computer.
To install the agent remotely using sudo commands:
1. Ensure that you have administrator account credentials on the target Mac computer, and that SSH is installed on the target Mac computer.
2. On the computer where the Delinea packages were downloaded (that is, the source computer), use an appropriate file transfer method to push the
CentrifyDC-x.x.x.pkg file to the target Mac computer.
For example, perform these steps to transfer files from a PC source computer to the target Mac computer:
1. On the source computer, ensure that file sharing is enabled, and that the folder containing the Delinea packages is a shared folder.
2. On the target Mac computer:
1. Open a new window in the Finder.
2. In the sidebar under Shared, click All.
3. Select the source computer.
4. Click Connect As, type the user name and password for the source computer, and click Connect.
3. The folder that you shared on the source computer appears in the Finder on the target Mac computer. Locate the CentrifyDC-x.x.x.pkg file on the
source computer and drag it to the location of your choice on the target Mac computer.
3. On the source computer, use a program such as Putty to connect remotely to the target Mac computer through SSH. Log in to the target Mac computer
using an account that has local administration privileges, such as the Local Admin account.
4. On the target Mac computer, navigate to the directory where the .pkg file was transferred and execute the following command:
sudo /usr/sbin/installer –pkg CentrifyDC-x.x.x.pkg –target /
When you execute this command, the agent is installed silently on the target Mac computer.
If an agent was already installed on the target Mac computer and this was an update of the existing agent, the target Mac computer was already
joined to the domain, and you do not need to perform any additional steps.
If this was the first installation of the agent on the target Mac computer, you must enable licensed features and join the target Mac computer to a
domain as described in Step 5 and Step 6.
5. Execute the following command on the target Mac computer to enable licensed features:
sudo adlicense -l
6. When you join the target Mac computer to a domain, you can choose to join the auto zone or a specified hierarchical zone.
Execute the following command on the target Mac computer to join the target Mac computer to a domain and the Auto Zone:
sudo /usr/local/sbin/adjoin --user Domain_Admin --container "domain.com/Path/To/OU" --name computer_name --workstation domain_name.com
Alternatively, execute the following command on the target Mac computer to join the target Mac computer to a domain and a specified
hierarchical zone:
sudo /usr/local/sbin/adjoin --user Domain_Admin --container "domain.com/Path/To/OU" --name computer_name --zone zone_namedomain_name.com
Installing Remotely on a Mac Computer Using Apple Remote Desktop
Perform the following steps to install the agent remotely on a target Mac computer without requiring any user interaction on the target Mac computer.
Note: If you use this method to install version 5.1.0 of the agent, the Delinea Join Assistant launches on the target Mac computer after the
installation completes, and a user must interact with the Delinea Join Assistant to complete the join process. For all other versions of the agent, no
user interaction on the target Mac computer is required.
To remotely install the DirectControl agent and join a computer to the domain using Apple Remote Desktop 3:
1. Verify that you have an Apple Remote Desktop 3 Admin station and one or more Apple Remote Desktop 3 Clients.
2. Verify that all of the Apple Remote Desktop 3 Client computers where you want to install the DirectControl agent are set to Allow Remote Desktop
using the Service pane in the Sharing system preference. For example:
3. Copy the DirectControl agent package, for example centrifydc-release-macversion-i386.dmg, to the Apple Remote Desktop 3 Admin computer and verify that
you can access the disk image.
4. Open Remote Desktop on the Admin Computer, then click Scanner and verify that the Mac computers on which you plan to install Delinea are listed
and that ARD Version column displays 3.0 (or later). For example:
5. Select one or more computers from the list, then click Install. For example:
6. In the Install Packages window, click + to locate the CentrifyDC.pkg in the DirectControl agent disk image. For example:
7. In the DirectControl agent disk image, select the CentrifyDC.pkg file and click Open to add it to the Install Packages list. For example:
8. In the Install Packages window, click Install to install the listed packages, for example:
In most cases, you can use the default settings to install the Delinea DirectControl Agent for Mac. If you want to schedule the installation for another time
rather than completing the installation now, click Schedule. For more information about the Apple Remote Desktop installation parameters, see Chapter 8
“Administering Client Computers,” in the Apple Remote Desktop Manual.
If you click Install the Remote Desktop displays a progress bar and task status for each of the computers selected for the installation.
Understanding the Directory Structure
When you complete the installation, the local computer will be updated with the following directories and files:
This directory Contains
/etc/centrifydc The Delinea DirectControl Agent for Mac configuration file and the Kerberos configuration file.
Kerberos-related files and service library files used by the Delinea DirectControl Agent for Mac to enable group
/usr/local/share/centrifydc
policy and authentication and authorization services.
/usr/local/sbin /usr/bin Command line programs to perform Active Directory tasks, such as join the domain and change a user password.
No files until you join the domain. After you join the domain, several files are created in this directory to record
/var/centrifydc information about the Active Directory domain the computer is joined to, the Active Directory site the computer is
part of, and other details.
/System/Library/Frameworks/
The Delinea Directory Service Plugin, CentrifyDC.dsplug, that enables you to join or leave the domain using the graphical
DirectoryService.framework/
user interface.
Resources/Plugins
Uninstall from the Delinea System Preferences Pane
The Delinea System Preferences pane is created when you install the Delinea DirectControl Agent for Mac. You can use this pane to uninstall the Delinea
DirectControl Agent for Mac. Uninstalling the agent from the Delinea System Preferences pane also leaves the AD domain.
To uninstall the Delinea DirectControl Agent for Mac from the Delinea System Preferences pane
1. Open System Preferences, then click Centrify.
2. Click Uninstall, then click O K at the confirmation prompt.
If you are currently joined to a domain, it will prompt the Leave Domain First dialog. For more information, see Leaving an Active Directory Domain
below.
3. Enter administrator credentials and click O K.
The uninstall process starts.
4. Click O K to quit when you see the window indicating that the Delinea DirectControl Agent for Mac was uninstalled.
Run the uninstall.sh Script
The uninstall.sh script is installed by default in the /usr/local/share/centrifydc/bin directory on each Centrify-managed system.
To remove the Delinea DirectControl Agent for Mac by running the uninstall.sh script
1. Open a Terminal window on the computer where the DirectControl agent is installed. For example, select Applications > Utilities > Terminal.
2. Switch to the root user or a user with superuser permissions. For example:
su -
Password: root_password
3. Run the uninstall.sh script. For example:
/bin/sh /usr/local/share/centrifydc/bin/uninstall.sh
The uninstall.sh script will detect whether the Delinea DirectControl Agent for Mac is currently installed on the local computer and whether the computer
is currently joined to a domain. If the computer is not currently joined to a domain, the script will begin removing Delinea files from the local computer.
Leaving an Active Directory Domain
To start the Delinea program for joining or leaving a domain:
1. Click Applications > Utilities > Delinea, then double-click Delinea Join Assistant to open it.
Click Continue on the Welcome page and the join assistant displays information about the domain to which the computer is connected:
2. Select whether to disable the computer object in Active Directory, remove the computer object from Active Directory, or leave without contacting
Active Directory.
Disable: Disables the computer object in Active Directory.

Remove: Removes the computer object from Active Directory.
Leave without contacting Active Directory: This option forces the local computer's settings to their pre-join conditions without contacting Active
Directory. The Computer Object will not be removed or disabled in Active Directory.
Use this option if the Active Directory computer account has been modified or deleted so that the host computer can no longer work with it.
3. Click Leave to leave the domain.
Administrator’s Guide for Windows
Introduction to Server Suite

Architecture and Operation
Planning a Deployment
Managing Zones
Managing Access Rights and Roles
Managing Local Windows Users and Groups
Managing Auditing and Audit Permissions
Managing Auditing for an Installation
Troubleshooting and Common Questions
Using Windows Command Line Programs
Working with Server Core and Windows Server 2012
Introduction to Server Suite
Server Suite is an IT management solution that provides three main services:
Access control, provided through the Authentication Service.

Privilege management, provided through the Privilege Elevation Service.
Auditing, provided through Audit & Monitoring Service.
These services can be used together or independently, depending on the requirements of your organization.
Managing Windows Computers Using Delinea software
Server Suite is a security platform that includes multiple components for managing Windows computers. The components fall into two broad categories of
features:
Access-related components for managing access, including administrative privileges.

Audit-related components for managing and analyzing audited activity.
Access-Related Features
Access-related features are provided by the Authentication Service and the Privilege Elevation Service. Together, these services enable you to manage
access and administrative privileges for the computers in your organization. The primary tool for managing access-related features is Access Manager.
Access Manager provides a central console for defining and managing role-based access control rules and applying them to specific users, groups, or
computers. For example, you can use Access Manager to delegate specific administrative tasks to a particular user or group. As an administrator, you can
also use Access Manager to configure roles with start and expiration dates or limit the availability of a role to specific days of the week or hours of the day.
Note: Server Suite treats gMSA accounts (group Managed Service Accounts) as Active Directory users.
Audit-Related Features
Audit-related features are provided by the Audit & Monitoring Service. This service enables you to collect and store audit trails that capture detailed
information about user activity. The primary tool for managing audit-related features is Audit Manager.
Audit Manager provides a central console for configuring and managing audited computers, audit store databases, and the permissions granted to specific
auditors. There is also a separate Audit Analyzer console for searching and replaying captured activity.
Choosing Access and Auditing Features
In addition to the management tools for access-related or auditing-related features, each computer you want to manage must have a Agent installed. After
you install the agent, you choose whether to enable access features, auditing features, or both feature sets.
If you enable access features, the agent enforces the role-based privileges that enable users to run applications locally with administrative privileges without
using the Administrator password and with their activity traceable to their own account credentials. You can also use role-based privileges to secure access
to network services on remote computers.
If you enable auditing features, the agent captures detailed information about what users do when they access applications or network resources with
administrative privileges.
You can use access features and components without auditing if you aren’t interested in collecting and storing information about session activities. You can
also deploy auditing features and components without access control and privilege elevation features if you are only interested in auditing activity on
Windows computers. However, the real value of using Delinea software to manage Windows computers comes from using all of the services as an integrated
solution for managing elevated privileges and ensuring accountability and regulatory compliance across all platforms in your organization.
Access Control for Windows Computers
By using Access Manager and deploying the Agent for Windows, you can develop fine-grained control over who has access to the Windows computers in your
organization. You can also limit the use of administrative accounts and passwords. For example, you can restrict access to computers that host
administrative applications or data center services and ensure that users accessing those computers can log on locally or connect remotely only when
appropriate.
In a Windows environment without Delinea software, the primary way you secure access to Windows computers is by granting a limited number of users or
groups local or domain administrator privileges. The main drawback of this approach is that the rights associated with group membership don’t change. A
user who has domain administrator rights has those rights on any computer in the domain at all times. In other cases, users who aren’t administrators or
members of an administrative group need administrative privileges to perform specific tasks that would require them to have an administrator and service
account password. Shared passwords reduce accountability and are often flagged by auditors as a security issue.
Through the use of zones and roles, Delinea software provides granular control over w h o can do what, and over where and when those users should be
granted elevated privileges.
One way trust environments
Windows agent supports one-way trust in the following scenarios:
When the zone belongs to the resource forest.

When the logon account belongs to the account forest.
When the RunAs account or group belongs to the resource forest (RunAs group can be a built-in group).
When the role assignment is at the zone, computer, or computer role level.
How Zones Organize Access Rights and Roles
One of the most important aspects of managing computers with Delinea software is the ability to organize computers, users, groups and other information
about your organization into zones. A zone is a logical object created using Access Manager that is stored in Active Directory. You use zones to organize
computers, rights, roles, security policies, and other information into logical groups. These logical groups can be based on any organizing principle you find
useful. For example, you can use zones to describe natural administrative boundaries within your organization, such as different lines of business, functional
departments, or geographic locations.
Zones provide the first level of refinement for access control, privilege management, and the delegation of administrative authority. For example, you can use
zones to create logical groups of Windows computers to achieve these goals:
Control who can log on to specific computers.

Grant elevated rights or restrict what users can do on specific computers.
Manage role definitions, including availability and auditing rules, and role assignments on specific computers.
Delegate administrative tasks to implement “separation of duties” management policies.
You can also create zones in a hierarchical structure of parent and child zones to enable the inheritance of rights, roles, and role assignments from one zone
to another or to restrict local or remote access to specific computers for specific users or groups.
Because zones enable you to grant specific rights to users in specific roles on specific computers, you can use zones as the first level of refinement for
controlling who has access to which computers, where administrative privileges are granted, and time restrictions on when administrative privileges can be
used.
You can also use zones to establish an appropriate separation of duties by delegating specific administrative tasks to specific users or groups on a zone-by-
zone basis. With zones, administrators can be given the authority to manage a given set of computers and users without granting them permission to perform
actions on computers in other zones or giving them access to other Active Directory objects.
How Role-Based Access Rights Can be Used
Role-based access rights are more flexible than Active Directory group membership because Active Directory groups provide static permissions. For
example, if Jonah is a member the Active Directory Backup Operators group, he has all of the permissions defined for members of that group regardless of
when or where he logs on to computers in the forest. In contrast, role assignments can be scheduled to start and end, apply only during specific hours, or only
be available on specific computers. For example, Jonah may only be in the Backup Operators role on a specific computer or only on weekends.
Role-based access rights also prevent password sharing for privileged accounts, helping to ensure accountability. Users who need to be able to launch
applications with elevated privileges can log on with their regular account credentials but run the application using an appropriate role without being
prompted to provide the administrative password. For example, if Angela is assigned a role that enables her to run Disk Defragmenter using elevated
privileges, she can log on with her normal credentials and select the role that enables her to run Disk Defragmenter without being prompted to provide an
administrator user name and password.
Auditing User Activity on Windows Computers
Just as it is important to protect assets and resources from unauthorized access, it is equally important to track what users who have permission to access
those resources have done. For users who have privileged access to computers and applications with sensitive information, auditing helps ensure
accountability and improve regulatory compliance. With the Audit and Monitoring service, you can capture detailed information about user activity and all of
the events that occurred while a user was logged on to an audited computer.
If you choose to enable audit and monitoring service on Windows computers, the Agent starts recording user activity when a user selects a role or logs on to a
computer. The agent continues recording until the user logs out or the computer is locked because of inactivity. The user activity captured includes an audit
trail of the actions a user has taken and a video record of the applications opened, any text that was entered, and the results that were displayed on the
screen. Because information about user activity, called a session, is collected as it happens, you can monitor computers for suspicious activity or
troubleshoot problems immediately after they occur.
When users start a new session on an audited computer, they can be notified that their session is being audited and they cannot turn off auditing except by
logging off. The information recorded is then transferred to a Microsoft SQL Server database so that it is available for querying and playback. You can search
the stored user sessions to look for policy violations, user errors, or malicious activity that may have led to a service degradation or outage.
In addition to saving video record of user activity, sessions provide a summary of actions taken so that you can scan for potentially interesting or damaging
actions without playing back a complete session. After you select a session of interest in the Audit Analyzer, the console displays an indexed list of actions
taken in the order in which they occurred. You can then select any entry in the list to start viewing the session beginning with that action. For example, if a user
opened an application that stores credit card information, you can scan the list of actions for the launch of that application and begin reviewing what
happened in the session from that time until the user closed that application.
If users change their account permissions to take any action with elevated privileges, the change is recorded as an audit trail event. You can search for these
events to find sessions of interest.
Using Access and Auditing Features Together
If you use the Access and Audit and Monitoring service features together, you can define role-based access rights, restrict when and where roles are
available, identify roles that should be audited, trace activity when roles with elevated permissions are selected and used, and play back session activity
based on the criteria you choose. However, audit and monitoring service requires database storage for the audited sessions and management of network
communication for collecting and transferring audited sessions from computers being audited to one or more databases where the sessions are stored. You
also need to decide which roles should require audit and monitoring service and the computers you want to audit.
Architecture and Operation
This chapter provides an overview of the Delinea software architecture for identity management, privilege elevation, and auditing on Windows computers.
Identity and Privilege Management
In Server Suite, the authentication service and privilege elevation service provide role-based access control and privilege management for Windows
computers. For administration, the services provide tools that help you define and manage access rights and roles for Active Directory users and groups. To
enforce the rights and roles you define, you install an agent on each server or workstation to be managed.
Defining Rights and Roles Using Access Manager
When you install Server Suite, you choose the components you want to enable. For identity and privilege management, the key component for administration
is the Access Manager console. Although there are other ways to define and manage access rights, roles, and role assignments, Access Manager is the
primary tool for managing all of the Delinea software information stored in Active Directory. With Access Manager, you can:
Create and manage zones to control access to all of the computers you support, including Windows, UNIX, Linux, and Mac OS X computers.
Set and modify specific types of access right for users and groups.
Add and customize the role definitions available in different zones, including any time restrictions on when roles are available or cannot be used.
Assign and manage roles for individual Active Directory user or Active Directory groups.
Associate groups of computers that share a common function or attribute with users who have a specific role assignment.
Generate and view reports describing the users, groups, computers, and applications you are managing and which users and groups have access to
which computers.
View and manage licenses for servers and workstations.
Enforcement of Rights and Roles by the Agent
For identity and privilege management, the key component for deployment is the Agent for Windows. After you install the agent on a server or workstation and
identify a zone for the computer to join, the computer becomes a Delinea-managed computer. If you have enabled access management features for the
agent, you can then define access rights and role-based policies to control what different sets of users can do on those computers in each zone.
After you deploy the Agent for Windows and select access management on a computer, the agent provides the following identity and privilege management
features:
Users logging on to the computer must be assigned to a role that allows them to log on.
Users who are assigned to a role with application rights can run a specific application with elevated privileges.
Users who are assigned to a role with desktop rights can create new Windows desktops that enables them to run all local applications with elevated
privileges.
Users who are assigned to a role with network access rights can connect to network resources with elevated privileges.
The following illustration provides a simplified view of the components for identity and privilege management.
In this illustration, an Agent is installed on an individual user’s workstation and on a server accessed remotely. The administrative consoles that you use to
manage zones, access rights, role definitions, and Active Directory accounts are installed on two separate computers. As shown in the illustration, all of these
computers are part of an Active Directory domain and have access to an Active Directory domain controller. If you work with other platforms, the architecture
is the same but you would have additional platform-specific agents.
To ensure that you can centrally manage access to Windows computers with the privilege elevation service and the Agent for Windows, you should check
that your network meets a few basic requirements:
You have at least one Active Directory forest and domain controller.
All of the computers you want to manage must be joined to an Active Directory domain and can communicate with an Active Directory domain controller
over the network or through a firewall.
You have a basic deployment plan in place that identifies your primary goals, team members and responsibilities, and a target set of computers.
The Audit and Monitoring Service Infrastructure
The Audit and Monitoring Service is part of Server Suite. The service captures detailed information about user activity on the computers you choose to audit.
Auditing Captures User Activity
After you deploy audit and monitoring service, the Agent for Windows captures all of the user activity on the computers you choose to audit. Depending on
whether you enable identity and privilege management together with audit and monitoring service, or just audit and monitoring service on a computer, the
agent starts recording user activity when a user selects a role or logs on to a computer and continues recording until the user logs out or the computer is
locked because of inactivity. If you enable identity and privilege management together with audit and monitoring service on a computer, the agent records
user activity when a role withaudit and monitoring service is used. If you only enable audit and monitoring service on a computer, all user activity is captured
by default.
Each record of continuous user activity is called a session, and starts as soon as users log on, whether they log on locally, using a Windows Remote Desktop
connection, through a virtual network connection such as Citrix or VNC, or using any other type of remote access software. A session ends when the user logs
out, disconnects, or is inactive long enough to lock the desktop. If the user reconnects to a disconnected desktop or unlocks the desktop, the agent resumes
recording the user’s activity as a new session. Each session is a video record of everything that takes place on the user’s desktop during a period of user
activity.
Auditing Requires a Scalable Architecture
To ensure scalability for large organizations and fault tolerance, audit and monitoring service has a multi-tier architecture that consists of the following
layers:
Audited computers are the computers on which you want to monitor activity. To be audited, the computer must have an agent installed, audit
features enabled, and be joined to an Active Directory domain.
Collectors are intermediate services that receive and compress the captured activity from the agents on audited computers as it occurs. You should
establish at least two collectors to ensure that audit and monitoring service is not interrupted. You can add collectors to your installation at any time,
and it is common to have multiple collectors to provide load balancing and redundancy.
Audit stores define a scope for audit and monitoring service and include the audit store databases that receive captured activity and audit trail
records from the collectors and store it for querying and playback. Audit store databases also keep track of all the agents and collectors you deploy. For
scalability and network efficiency, you can have multiple audit stores each with multiple databases.
A management database server is a computer that hosts the Microsoft SQL Server instance with the audit management database. The
management database stores information about the overall installation, such as the scope of each audit store, which audit store database is active,
where there are attached databases, the audit roles you create, and the permissions you define. The management database enables centralized
monitoring and reporting across all audit stores, collectors, and audited computers.
Audit Manager and Audit Analyzer consoles are the graphical user interfaces which administrators can use to configure and manage the
deployment of audit components, such as agents and collectors, or query and review captured user sessions.
A reporting database collects data from audit stores and the management database and saves the data in a format that is optimized for reporting.
With the reporting database, you can generate event notifications, such as when an audited system goes offline.
To ensure that audit data transferred over the network is secure, communication between components is authenticated and encrypted.
In addition to these core components of the audit and monitoring service infrastructure, there is a separate Windows service that is optional to collect audit
trail events when there are audit store databases that are not accessible, for example, because of network issues or the database server is shut down. This
audit management service spools the events on the management database, then sends them to the audit store database when the inaccessible database
comes back online.
How Audited Sessions are Collected and Stored
The agent on each audited computer captures user activity and forwards it to a collector on a Windows computer. If the agent cannot connect to a collector—
for example, because all of the computers hosting the collector service for the agent are shut down for maintenance—the agent spools the session data
locally and transfers it to a collector later. The collector sends the data to an audit store server, where the audit data is stored in the Microsoft SQL Server
database that you have designated as the active audit store. As you accumulate data, you can add more SQL Server databases to the audit store to hold
historical information or to change the database designated as the active audit store database.
When an administrator or auditor uses the Audit Analyzer console to request session data, the audit management server retrieves it from the appropriate
audit store.
The following figure illustrates the basic architecture and flow of data with a minimum number of audit and monitoring service components installed.
In the illustration, each agent connects to one collector. In a production environment, you can configure agents to allow connections to additional collectors
for redundancy and load balancing or to prevent connections between specific agents and collectors. You can also add audit stores and configure which
connections are allowed or restricted. The size and complexity of the auditing infrastructure depends on how you want to optimize your network topology,
how many computers you are audit and monitoring service, how much audit data you want to collect and store, and how long you plan to retain audit records.
Deploying the Audit and Monitoring Service Infrastructure
The multi-tiered architecture of audit and monitoring service requires that you deploy an audit and monitoring service infrastructure to transfer and store the
information captured by agents on the audited computers. This auditing infrastructure is referred to collectively as an Auditing installation. The audit and
monitoring service installation represents a logical boundary similar to an Active Directory forest or site. It encompasses all of the audit and monitoring
service components you have installed—agents, collectors, audit stores, management database, and consoles—regardless of how they are distributed on
your network. The installation also defines the scope of audit data available. All queries and reports are against the audit data contained within the
installation boundary.
The most common deployment scenario is to have a single audit and monitoring service installation for an entire organization so that all audit data and
management of the audit data is centralized. Within a single audit and monitoring service installation, you can have components wherever they are needed,
as long as you have the appropriate network connections that allow them to communicate with each other. The audit data for the entire installation is
available to users who have permission to query and view it using a console. For most organizations, having a single audit and monitoring service installation is
a scalable solution that allows a “separation of duties” security model through the use of audit roles. If you establish a single audit and monitoring service
installation, there will be one Master Auditor role for the entire organization, and that Master Auditor can control the audit data that others users and groups
can see or respond to by defining roles that limit access rights and privileges.
However, if you have different lines of business with different audit policies, in different geographic locations, or with different administrative groups, you can
configure them as separate audit and monitoring service installations. For example, if you have offices in North America and Hong Kong managed by two
different IT teams—IT-US and IT-HK—you might want to create two installations to maintain your existing separation of duties for the ITUS and IT-HK teams.
Planning Where to Install Audit and Monitoring Service Components
Before you install audit and monitoring service components, you should develop a basic deployment plan for how you will distribute and manage the
components that make up an installation. For example, you should decide how many collectors and audit stores to create and where to put them. You should
also consider the network connections required and how many computers you plan to audit. For example, you can have multiple agents using the same set of
collectors, but you should keep the collectors within one hop of the agents they serve and within one hop of the audit stores to which they transfer data.
By planning where to install components initially, you can determine the number of collectors you should have for load balancing or redundancy. After the
initial deployment, you can add collectors and audit stores whenever and wherever they are needed.
Using Multiple Databases in an Audit Store
Each audit store uses Microsoft SQL Server to provide database services to the installation. When you configure the first audit store, you identify the
database instance to use for audit and monitoring service and that database becomes the active database for storing incoming audit data. A single audit
store, however, can have several databases attached to it. Attached databases store historical information and respond to queries from the management
database. You can use the Audit Manager console to control the databases that are attached and to designate which database is active. Only one database
can be active in an audit store at any given time.
Although the audit store can use multiple databases, the presentation of session data is not affected. If a session spans two or more databases that are
attached to the audit store, the Audit Analyzer console presents the data as a single, unbroken session. For example, if you change the active database during
a session, some of the session data is stored in the attached database that is no longer active and some of it stored in the newly activated database, but the
session data plays back as a single session to the auditor.
Using Multiple Consoles in an Installation
A single audit installation always has a single audit management server and database. In most cases, however, you use more than one console to request data
from the audit management database. The two most important consoles in an installation are the Audit Manager console and the Audit Analyzer console.
As an installation owner, you use the Audit Manager console to configure and manage the audit installation. In most organizations, there is only one
Audit Manager console installed.
Auditors and administrators use the Audit Analyzer console to search, retrieve, play back, and delete sessions. The auditor can use predefined queries
to find sessions or define new queries. Auditors can also choose whether to share their queries with other auditors or keep them private. In most
organizations, there are multiple Audit Analyzer consoles installed.
In addition to the Audit Manager and Audit Analyzer consoles, audit and monitoring service includes a settings control panel and a collector control panel.
As an administrator, you can use the Audit & Monitoring Service Settings control panel to configure the agent on Windows. Normal users who log on and
run applications on the audited computer cannot stop, pause, restart, or configure the agent.
You can use the collector control panel to configure a collector.
The following illustration is an example of the architecture of a medium-size installation.
Basic Operation with Identity and Privilege Management, and Auditing
When you combine identity and privilege management together with auditing on the same computer, you have an audit trail and video record of actions
performed with elevated privileges. For example, when you deploy identity and privilege management features, users must be assigned to a role with
permission to log on. If they are allowed to log on and audit and monitoring service is deployed, the agent begins auditing their activity. If a user creates a new
desktop, opens a protected application, or connects to services on a remote network server with administrative or service account privileges, the action is
recorded and can be traced back to the account used to log on.
The following illustration provides a simplified view of the architecture and flow of data when you deploy components for identity management, privilege
management, and auditing.
Although it is not depicted in the illustration, the audit trail records every successful or failed attempt to use a role, including the login role. You do not have to
enable audit and monitoring service for a role to record this information. Every computer that has the Agent for Windows records the use of elevated
privileges by default. If you do enable audit and monitoring service for a role, however, you can record all of the user activity after the user switches to the
audited role. With audit and monitoring service enabled, the audit trail and the user activity are stored in the database and available for display and analysis
anywhere you install the Audit Analyzer console. Without audit and monitoring service, the audit trail is only available in the Windows event log on the local
computer where the activity took place.
Planning a Deployment
This chapter describes the decisions you need to make during the planning phase of a deployment and summarizes what’s involved in deploying identity
management, privilege management, audit and monitoring service, and Agents. It includes simplified diagrams that highlight the steps involved.
Because of its multi-tier architecture and storage requirements, most of the information in this chapter applies to planning a deployment of audit and
monitoring service. If you are only interested in deploying identity and privilege management without auditing, you should scan What’s involved in the
deployment process for relevant topics and continue to Installing Server Suite and updating Active Directory.
Why Planning is Important
Deploying Delinea software on Windows affects how users access local applications and remote services. These changes will become a critical part of your
IT infrastructure and the management of your organization’s resources. Therefore, it is important that you plan and test your deployment strategy and
validate the results before placing Delinea software components into a production environment.
After you deploy Delinea software in a production environment, the rights and roles you define will control whether users can log on and what they can do on
specific computers if they are allowed to log on. Because preventing users from accessing critical resources or services can affect business operations, you
should analyze the requirements of your environment as thoroughly as possible before moving from a pilot deployment into production.
Identify Identity, Privilege Management, and Auditing Goals
As discussed in Managing Windows computers using Delinea software, you have the option of focusing your deployment on identity and privilege
management, or on audit and monitoring service, or on a combination of the two. If you plan to install components for identity and privilege management
together with audit and monitoring service, you can use roles and role assignments to control which users and groups are audited and under what
circumstances auditing takes place. You can also capture detailed information about what happened after a user selected a role with domain administrator
privileges or started an application using a service account.
During the planning phase, you should decide on the goals of your deployment—identity and privilege management, audit and monitoring service, or both—
because that decision affects all of the other decisions you need to make. If you plan to include audit and monitoring service, you should also start to identify
who and what you want to audit, any roles where no auditing should be done, and any roles that will require auditing.
Decide on the Scope of the Installation
Before you deploy any of the audit and monitoring service infrastructure, you should decide on the scope of the installation and whether you want to use a
single installation for your entire Active Directory site, or separate installations for different geographical areas or functional groups.
The most common deployment is a single audit and monitoring service installation for each Active Directory forest, so that auditors can query and review
information for the entire organization. However, if your Active Directory site has more than one forest, you might want to use more than one audit and
monitoring service installation. If you want to use more than one audit and monitoring service installation, you should determine the subnetwork segments
that will define the scope of each installation.
In Active Directory, a site represents the collection of Internet Protocol (IP) addresses that describe the physical structure of your network. If you are not
familiar with how Active Directory sites are defined, you should consult Microsoft documentation for more information.
Decide Where to Install the Management Database
Each installation has a single audit management server and database. The management database is a Microsoft SQL Server database that stores
information about the installation such as the Active Directory sites or subnets associated with each audit store.
The computer you use for the audit management database should have reliable, high-speed network connectivity. The management database does not store
the captured sessions, and is, therefore, much smaller than the audit store databases. There are no specific sizing requirements or recommendations for the
management database.
You can use the following guideline as the recommended hardware configuration for the computer you use as the management database:
Computer used for Number of concurrent sessions CPU cores CPU speed Memory
Management database Any 1 to 2 2.33 GHz 8 GB
Decide Where to Install Collectors and Audit Stores
Although a collector and an audit store database can be installed on the same computer for evaluation, you should avoid doing so in a production
environment. As part of the planning process, therefore, you need to decide where to install collectors and audit store databases. In designing the network
topology for the audit and monitoring service installation, there are several factors to consider. For example, you should consider the following:
Database load and capacity

Network connectivity
Port requirements
Active Directory requirements
The next sections provide guidelines and recommendations to help you decide where to install the collectors and audit store databases required to support
the number of computers you plan to audit.
Use Separate Computers for Collectors and Audit Store Databases
To avoid overloading the computers that host collectors and audit store databases, you should install collectors and audit store SQL Server databases on
separate computers. Because SQL Server uses physical memory to store database information for fast query results, you should use a dedicated computer
for the audit store database, and allocate up to 80% of the computer’s memory to SQL Server. In most installations, you also need to plan for more than one
audit store database and to periodically rotate from one database to another to prevent any one database from getting too large. For more information about
managing audit store databases, see Managing audit store databases.
Plan for Network Traffic and Data Storage
You should minimize the distance network packets have to travel between an agent and its collector. You should also minimize the distance between
collectors and their audit stores. If possible, you should not have more than one gateway or router hop between an agent and its collector.
Default Ports for Network Traffic and Communication
To help you plan for network traffic, the following provides an overview of the network communications and ports used when a user logs on and the ports used
in the initial set of network transactions.
When a user logs on, the Agent for Windows connects to Active Directory to begin the lookup process, then the agent and the domain controller exchange
messages as follows:

Kerberos – Ticket Granting Ticket (TGT) request on port 88.
Network Time Protocol (NTP) Server – Time synchronized for Kerberos on port 123.
Domain Name Service (DNS) – Host (A), Pointer (PTR), Service Location (SRV) records on port 53.
RPC over TCP - For inbound RPC endpoint mapper connections to support network discovery or if password management and validation uses RPC over
TCP on port 135.
ports used for different editions of Delinea software.
This
Is used for Delinea software and operation requiring this port
port
Encrypted TCP communication for

22 Authentication service and privilege elevation service for secure shell connections on remote clients.
OpenSSH connections
TCP communication for Telnet Delinea authentication service, privilege elevation service, and audit and monitoring service. By default,
23
connections telnet connections are not allowed because passwords are transferred over the network as plain text.
Authentication service and privilege elevation service, clients use the Active Directory DNS server for
53 TCP/UDP communication
DNS lookup requests.
This
Is used for Delinea software and operation requiring this port
port
Authentication service and privilege elevation service, Kerberos ticket validation and authentication,
88 Encrypted UDP communication
agents, Delinea PuTTY
UDP communication for simple network Authentication service and privilege elevation service, keeps time synchronized between clients and
123
time protocol (NTP) Active Directory for Kerberos ticketing.
authentication service and privilege elevation service, Active Directory authentication and client LDAP
389 Encrypted TCP/UDP communication
service.
Cloud proxy server to Delinea cloud

443 Delinea software for mobile device management.
service
Encrypted TCP/UDP communication for Authentication service and privilege elevation service, adclient and adgpupdate use Samba (SMB) and
445
delivery of group policies Windows file sharing to download and update group policies, if applicable.
Encrypted TCP/UDP communication for Authentication service and privilege elevation service, Kerberos ticket validation and authentication for
464
Kerberos password changes agents,Delinea PuTTY, adpasswd, and passwd.
Encrypted TCP communication for the

Authentication service, privilege elevation service, and audit and monitoring service; collector service
1433 collector connection to Microsoft SQL
sends audited activity to the database.
Server
Authentication service and privilege elevation service, Active Directory authentication and LDAP global
3268 Encrypted TCP communication
catalog updates.
Encrypted TCP/RPC communication for Authentication service, privilege elevation service, and audit and monitoring service; auditing service
5063
the agent connection to collectors records user activity on an audited computer.
Authentication service and privilege elevation service, to determine whether if a remote computer is
none ICMP (ping) connections
reachable.
Auditing Requires Database Management
If you are planning a deployment with just audit and monitoring service or with identity management, privilege management, and auditing, you must plan how
you will create and manage the databases that receive and store audit data. You should also consider your data archiving and retention policies, who should
be given auditor permissions, and other details because these decisions affect your storage and maintenance requirements. For more information about
managing an installation for auditing, see Managing auditing for an installation.
For audit and monitoring service, you should plan a pilot deployment of 20 to 25 agents to determine how much audit data your organization would generate
and how fast the database can increase in size as you add agents. For more information about monitoring a pilot deployment for audit and monitoring service
and guidelines for sizing the database, see Estimating database requirements based on the data you collect.
Identify an Active Directory Site or Subnets
Depending on the size and distribution of your Active Directory site, an audit store might cover an entire site or specific subnet segments. If you have a large,
widely distributed site, you should consider network connectivity and latency issues in determining which subnets each audit store should serve. In addition,
you should always place collectors in the same site as the agents from which they receive data. Collectors and agents must always be in the same Active
Directory forest. If possible, you should put collectors and agents in the same domain.
Note: If you deploy agents in a perimeter network, such as a demilitarized zone (DMZ), that is separated from your main network by a firewall, put
the collectors in the same Active Directory domain as the audited computers. The collectors can communicate with the audit store database
through a firewall.
Determine How Many Collectors and Audit Stores to Install
Although you can add collectors and audit stores to your audit and monitoring service installation after the initial deployment, you might want to calculate
how many you will need before you begin deploying components. You should always have at least two collectors to provide redundancy. As you increase the
number of agents deployed, you should consider adding collectors.
Estimate the Number of Agents and Sessions Audited
If you plan to use more than the minimum number of collectors, the most important factor to consider is the number of concurrent sessions you expect to
monitor on audited computers. The number of concurrent sessions represents the number of interactive users that the agent is actively capturing for at the
same time.
You can use the following guidelines as a starting point and adjust after you have observed how much audit data you are collecting and storing for Windows
computers:
Number of concurrent sessions Recommended number of collectors Recommended number of audit stores
up to 100 agents 2 1
more than 100 agents 2 for every 100 agents 1 for every 100 agents
Determine the Recommended Hardware Configuration
The hardware requirements for collectors and audit store servers depend on the size of the installation and where the components are installed on the
network. For example, the requirements for a computer that hosts the collector service are determined by the number of audited computers the collector
supports, the level of user activity being captured and transferred, and the speed of the network connection between the agents and the collector and
between the collector and its audit store.
You can use the following guidelines as the recommended hardware configuration for the computers you use as collectors and audit store servers when
auditing Windows computers:
Collectors Up to 100 active agents 2 2.33 GHz 8 GB
Audit store Up to 200 active agents 2 2.33 GHz 8 GB
200 to 500 active agent 4 2.33 GHz 32 GB
Guidelines for Storage
Because audit and monitoring service collectors send captured user sessions to the active SQL Server database, you should optimize SQL Server storage for
fast data logging, if possible. For the active database, you get the most benefit from improvements to disk write performance. Read performance is
secondary. Fibre Attached Storage (FAS) and Storage Area Network (SAN) solutions can provide 2 to 10 times better performance than Direct Attached
Storage (DAS), but at a higher cost. For attached databases that are only used to store information for queries, you can use lower cost storage options.
Guidelines for Disk Layout
The following table outlines the recommended disk arrays:
Application Disk configuration Use the disk for
Operating system C: RAID 1 Operating system files, page file, and SQL Server binaries.
Microsoft SQL Server D: RAID 10 (1+0) Audit store database.
E: RAID 10 (1+0) Audit database log files.
F: RAID 1 or 10 (1+0) Temporary database space (tempdb) for large queries for reports.
G: RAID 1 Database dump files.
The size of disk needed depends on the number, length, and types of sessions recorded each day, the selected recovery model, and your data retention
policies. For more information about managing audit store databases, see Managing audit store databases.
Decide Where to Install Agents
The Agent for Windows must be installed on all of the computers you want to audit. Therefore, as part of your planning process, you should decide whether
you want to audit every computer on the network or specific computers, such as the computers used as servers or used to run administrative software.
Before installing the agent, verify the following:
The computer is joined to Active Directory.

The computer has Windows security update KB3033929 installed if it is running Windows 7 with Service Pack 1 or Windows Server 2008 R2 with Service
Pack 1.
The computer has .NET 4.6.2 or later installed.
The computer has Windows Installer version 4.5 or newer.
Agents can communicate with a collector only if the agents and collector are in the same Active Directory forest.
Decide Where to Install Consoles
You can install and run the Audit Manager console and the Audit Analyzer console on the same computer or on different computers. The computers where you
install the consoles must be joined to the Active Directory domain and be able to access the management server and the database that serves the
installation.
You can also use the Audit Analyzer console to run queries from any additional computers with network access to the management database. Therefore, you
should decide where it would be convenient to have this capability.
Check SQL Server Logins for Auditing
An audit installation requires at least two Microsoft SQL Server databases: one for the management database and at least one for the first audit store
database. To successfully connect to these databases, you must ensure that the appropriate users and computers have permission to read or to read and
write for the databases that store audit-related information.
The simplest way to manage SQL logins for auditors and administrators is to do the following:
Ensure you have a SQL login account for the NT Authority\System built-in account.
Add the NT Authority\System account to the system administrator role.
Use Audit Manager to grant Manage SQL Logins permissions to the Active Directory users and groups that require them.
If you use Audit Manager to manage SQL logins, you can use Active Directory membership to automatically add and remove the permissions required for
auditing activity. There is no requirement to use the SQL Server Management Studio to manage logins or permissions. Because it is recommended that you
have a dedicated SQL Server instance for auditing, giving the NT Authority\System account a SQL login and system administrator role is an acceptable
solution for most organizations.
Create Security Groups for Auditing
Depending on whether you configure Microsoft SQL Server to use Windows only authentication or Windows or SQL Server authentication, your SQL Server
login credentials might be a Windows account or a SQL Server login account that is not associated with a Windows account.
To facilitate communication and the management of SQL logins, you can create Active Directory security groups for the following users and computers:
Admins for the user accounts that perform administrative tasks using Audit Manager.
Auditors for the user accounts that user Audit Analyzer.
TrustedCollectors for the computers accounts that host the collector service.
If you create these Active Directory security groups, you can then use Audit Manager to grant Manage SQL Login permissions for each group to allow its
members to connect to the appropriate SQL Server database. Creating Active Directory security groups with SQL Server logins enables you to manage
access to the databases required for auditing through Active Directory group membership without the help of the database administrator.
Any time you want to add an administrator, auditor, or collector computer to the installation, you simply add that user account or computer object to the
appropriate Active Directory group. If an administrator or auditor leaves or if you want to stop using the collector on a particular computer, you can remove
that user or computer from its Active Directory security group to prevent it from accessing the database.
What’s Involved in the Deployment Process
Most of the planning in this chapter has focused on designing the audit and monitoring service infrastructure and deciding where to install components. The
following illustration provides a visual summary of the complete deployment process and highlights the keys to success. The sections after the flowchart
provide additional details about what’s involved in each phase or the decisions you will need to make, such as who should be part of the deployment team,
where to install the software, and who has permission to do what.
Plan
During the first phase of the deployment, you collect and analyze details about your organization’s requirements and goals. You can then also make
preliminary decisions about sizing, network communication, where to install components, and what your zone structure should look like.
Identify the goals of the deployment.
Is identity and privilege management or audit and monitoring service a primary goal?
Are identity and privilege management and audit and monitoring service equally important to the organization?
Is audit and monitoring service important for specific computers?
Is audit and monitoring service important for computers used to perform administrative tasks?
Is audit and monitoring service important for computers that host specific applications or sensitive information?
Should audit and monitoring service be required for users in specific groups or with specific roles?
For example, if audit and monitoring service is important, are you

primarily interested in auditing Windows servers, such as SQL Server,
Exchange, and IIS, administrative workstations, or computers that host
specific applications or sensitive information?
Assemble a deployment team with Active Directory and other expertise.
People with specific knowledge, such as Exchange, IIS, or Sharepoint administrators.

If auditing, at least one Microsoft SQL Server database administrator.
Provide basic training on Delinea software architecture, concepts, and terminology.
Study the existing environment to identify target computers where you plan to install Delinea software components.
Review network connections, port requirements, firewall configuration.
For more information about network communication and the ports used, see
Plan for network traffic and data storage.
Identify computers for administration.
Basic deployment — Access Manager

Auditing — Audit Manager and Audit Analyzer consoles
Identify computers to be used as collectors, audit stores, and the management database.
Verify that you have reliable, high-speed network connections between components that collect and transfer audit data.
Verify you have sufficient disk storage for the first audit store database.
Identify the initial target group of computers to be managed and audited.
Single or multiple top-level parents.

Initial child zones, for example, separate zones for different functional departments or administrative groups.
Prepare
After you have analyzed the environment, you should prepare the Active Directory organizational units and groups to use. You can then install administrative
consoles and the audit and monitoring service infrastructure, and prepare initial zones.
(Optional) Create organizational units or containers to define a scope of authority.
The deployment team should consult with the Active Directory enterprise administrator to determine whether any additional containers or
organizational units would be useful, who should be responsible for creating Licenses and Zones container objects, and who will manage the objects in
those containers.
(Optional) Create the additional Active Directory security groups for your organization.
Groups can simplify permission management and the separation of duties.
Install Access Manager on at least one administrative Windows computer.
Open Access Manager for the first time to run the Setup Wizard for the Active Directory domain.
The hierarchical zone structure you use depends primarily on how you want to use inheritance and roles.
Prepare Windows computer accounts in the appropriate zones and assign the default Windows Login role to the appropriate Active Directory users and
groups.
Install Audit Manager and Audit Analyzer together or separately.
Create an installation and a management database on one computer.
Create an audit store and audit store database on at least one computer.
Install a collector on at least two computers.
Deploy
After you have prepared Active Directory, installed administrative consoles on at least one computer, created at least one zone, and prepared the audit and
monitoring service infrastructure, you are ready to deploy on the computers to be managed.
Create Desktop, Application, and Network Access rights.

Add Desktop, Application, and Network Access rights to custom role definitions.
Assign custom roles to the appropriate Active Directory users and groups.
Install the Agent for Windows on a target set of computers.
Join the appropriate zones.
Prepare a Group Policy Object for deploying agents remotely using a group policy.
Assign the appropriate permissions to the users and groups who should have access to audit data.
Validate
After you have deployed agents on target computers, you should test and verify operations before deploying on additional computers.
Log on locally to a target computer using an Active Directory user account and password to verify Active Directory authentication and Windows Login
role assignment.
Open a Remote Desktop Connection to a target computer to verify Active Directory authentication and Windows Login role assignment on a remote
computer.
Create a new desktop that gives you administrative rights and verify that you can start and stop Windows services or perform other administrative
tasks.
Right-click an application, select Run using selected roles, then select an available role for running the application.
Open Audit Analyzer and query for your user session if audit and monitoring service is enabled.
Manage
After you have tested and verified identity management, privilege management, and audit and monitoring service operations, you are ready to begin
managing the installation and refining on-going operations.
Here are the key steps involved if you deploying identity management, privilege management, and auditing for Windows computers:
Secure the installation.

Add roles and assign roles and permissions to the appropriate users, groups, and computers.
Delegate administrative tasks to the appropriate users and groups for each zone.
Deploy additional group policies on the appropriate organizational units.
Create new databases and rotate the active database.
Archive and delete old audit data.
Automate key administrative tasks using Delinea-defined Powershell-based cmdlets and scripts.
Authentication and Privilege Elevation Services Deployment Checklist
The following checklist provides an overview of each of the main steps that are involved when you deploy the Authentication Service and Privilege Elevation
Service. For any tasks related to Delinea software, there are links to more information and procedures.
For auditing deployment steps, please see the Audit & Monitoring Service deployment checklist.
Step# Installation Step Notes Link to Details
PREPARATION AND PLANNING
Analyze your network topology to determine where to install

Planning a
1 components and services and any hardware or software updates
Deployment
required.
Create a list of the computers where you plan to install different Planning a
2
components. Deployment
Determine how you plan to install the software onto your Planning a
3
computers. Deployment
PRE-INSTALL TASKS
Prepare a domain account that has permissions to create Active You'll need this account to create the OU using the
4
Directory containers and child objects. Installation wizard.
5 Prepare an Active Directory group to be zone administrators.
6 Create the Zone Provisioning Agent (ZPA) service account. Requires Active Directory domain admin privileges
7 Apply group policy to allow the ZPA to run as a service. Requires Active Directory domain admin privileges
INSTALL TASKS
Install the Access Manager console, ZPA, group policies, create the Installing Server
8
OU in Active Directory, and so forth. Suite
(Optional) Configure ZPA – this is only needed if you plan on

9
automatically provisioning users.
Run adcheck on any UNIX computer that you want to manage and
10
fix any issues until adcheck produces no issues.
Install a Agent for Windows on each Windows computer that you Installing the Agent
11
want to manage. for Windows
Install a Agent for *NIX on each UNIX or Linux computer that you
12
want to manage.
Install additional Access Manager consoles on any Windows Installing

13 computer that you want to use for the Authentication and Privilege Additional
Management services. Consoles
Troubleshooting
Verify that agents are working correctly. Run adinfo on managed
14 and Common
UNIX computers.
Questions
POST-INSTALL HOUSEKEEPING
adimport man
15 Identify UNIX users who do not have an Active Directory account. Automatically done by adimport
page
16 Identify service accounts.
17 Collect and analyze sudoers files.
Create a list of roles in sudoers that will be migrated to Privilege

18
Elevation Service.
19 Create a list of users and groups to be migrated to Active Directory.
20 Create missing Active Directory user accounts.
SETUP AND CONFIGURATION
21 Create list of computers that will be joined to each zone.
Creating a New
Parent Zone
22 Create parent and child zones.
Creating Child
Zones
Delegating Control
23 Delegate control to zones. of Administrative
Tasks
24 Import UNIX users and groups into Active Directory.
25 Create Zone Provisioning groups and add users and groups to them.
26 Pre-create computer objects in zones.
27 Create role groups .
28 Assign roles and users to role groups.
Create a New
29 Create ComputerRoles and ComputerRole groups.
Computer Role
Add Role
30 Assign roles, users, and computers to ComputerRole groups. Assignments to the
Computer Role
Use “Show Effective Users” to check that profiles and roles are
31
correct.
32 Start the ZPA agent. You configured ZPA in a previous step.
33 Configure the ZPA provisioning rules for the parent zone.
34 Join UNIX servers to Zones.
* Critical task that must be carefully coordinated with

Change the UID/GID of files for those users who have been assigned
35 the users. Can be done at time of join to Active
a new UID/GID in the Zone. Run adfixid on servers.
Directory with a script.
FINAL TASKS
36 Check the status of the join and roles on the servers. Run adflush, adinfo and dzinfo
37 Back up passwd, shadow, and group files.
Remove the users and groups (that have been migrated to Active
38 Run adrmlocal on servers
Directory) from the local files.
Accounts and Permissions for Installation and Deployment
Below is a summary of the account permissions that you need to install and deploy Server Suite.
Authentication and Privilege Elevation Services permissions
Access Manager Account Permissions
Account
Type of Required
name Notes
account permissions
(suggested)
Domain Because the Setup Wizard creates container objects, you might need to use a domain administrator
administrator domain account. This requirement depends on the specific permissions your organization has configured for
n/a (when running admin (in different classes of users. For example, if your organization only permits Domain Admins to create
Access Manager most cases) parent and child objects in Active Directory, you need to use an account with those permissions to run
for the first time) the Setup Wizard.
For more information, see:
"Running Access Manager for the First Time" and "Permissions Required to use the Setup Wizard" in the Unexpected Link Text
Zone Provisioning Agent Account Permissions
Account
Type of Required
name Notes
account permissions
(suggested)
The Zone Provisioning Agent requires permission to create UNIX profiles-- that is, the service connection
Active
Log on as a points in each zone where it needs to perform provisioning operations. The service account that runs the Zone
Cfy_SVC_ZPA Directory
service Provisioning Agent requires the Log on as a service right set as a local computer security policy, or in the
account
default domain policy.
"About Zone Provisioning Agent and its Requirements" in the Unexpected Link Text
Report Services Account Permissions
Required security
policy Required SQL Server or
Required Active Directory Required SSRS
User type permissions(group PostgreSQL
permissions permissions
policy, or local permissions
policy)
For domain-based reporting:

Replicating directory changes at the
report service account to run
domain level (ADUC) and replicate Log on as a service
the Reporting Service
directory changes in ADSI For zone-
based reporting: Read permission
SQL Server service account member of the

n/a Log on as a service
to run SQL Server securityadmin role
the account must have

PostgreSQL service permission to connect to
Required security
policy Required SQL Server or
Required Active Directory Required SSRS
User type permissions(group PostgreSQL
permissions permissions
policy, or local permissions
policy)
account PostgreSQL and create a

database
member of the
report admin to run the Report
securityadmin role (At the
Configuration wizard or the
Folder Settings > Content very least, the user needs
Upgrade & Deployment wizard needs to be a member of the domain n/a
Manager role permission to connect to
and deploy reports to an existing
SQL Server and create a
SQL Server instance
database.)
Read permission to the domain root

report admin to modify the object of the selected domain. Read
n/a
Reports Control Panel permission to all computer objects in
the selected domain.
Site settings > System

user role Folder settings >
Report viewer to view reports
browser (assign SSRS
from SSRS/Internet Explorer
roles to Active Directory
group or users)
Site settings > System

Report writer read, write, edit user role Folder settings >
access for reports, in addition to Content Manager role
the permissions needed to view (assign SSRS roles to
reports Active Directory group or
users)
SQL Server Permissions Set by the Report Services Configuration Wizard
User type Required SQL Server permissions
report services account to run the SQL Server

Snapshot Service (predefined role)
Reporting Service
If you deploy to an existing SQL Server instance, the configuration wizard makes no changes to the
SQL Server service account.
If you deploy to a new SQL Server instance: --If the operating system is Windows 2008 and you’re
using a SQL Server version later than 2012, virtual accounts are used for various SQL Server
components, as follows:
SQL Server engine:

NT SERVICE\MSSQL$<InstanceName>
SQL Server Agent:

NT SERVICE\SQLAgent$<InstanceName>
SQL Server service account to run SQL Server
Full text search:
NT SERVICE\MSSQLFDLauncher$<InstanceName>
SSRS:
NT SERVICE\ReportServer$<InstanceName>
--Otherwise, the SQL Server service accounts are configured as follows:
SQL Server engine: NT Authority\Network Service

SQL Server Agent: NT Authority\Network Service
Full text search: NT Authority\Local Service
SSRS: NT Authority\Local Service
report admin to run the Report Configuration

Connect SQL (cannot be revoked after setup) Create Database, Create any database, or Alter any database member
Wizard and deploy reports to an existing SQL
of securityadmin role, or Alter any login permission
Server instance
report admin to modify the Reports Control

SnapshotAdmin (predefined role)
Panel
Report viewer to view reports from

Login permission SnapshotViewer (predefined role)
SSRS/Internet Explorer
Report writer read, write, edit access for reports,

in addition to the permissions needed to view Login permission SnapshotViewer (predefined role)
reports
Note: Microsoft SQL Server Reporting System (SSRS) affords only role-based security in their reports. Be sure to grant appropriate access to
reports. For example, if a user has access to only some data in the specified domain but all reports, they will be able to view all reports on all data
"Required User Permissions for Report Services" and "SQL Server Permissions that are Set by the Configuration Wizard" in the Unexpected Link Text
Audit & Monitoring Permissions
Auditing permissions for SQL Server
SQL Server account Type of account Required permissions Notes
NT Authority\System machine account SQL Server Roles: sysadmin role
Auditing security groups
Active Directory security Type of Required SQL Server

Notes
groups account permissions
Admins for the user no explicit SQL Server

Creating Active Directory security groups with SQL Server logins enables you
accounts that perform Active permissions needed — Audit
to manage access to the databases required for auditing through Active
administrative tasks using Directory Manager handles the SQL
Directory group membership without the help of the database administrator.
Audit Manager. Server permissions
Auditors for the user

accounts that use Audit
Analyzer.
Collectors for the computer

accounts that host the
Active Directory security Type of Required SQL Server
Notes
groups account permissions
collector service.
For more information, see Checking SQL Server Logins for Auditing.
This chapter describes how to install Server Suite software on Windows computers in a production environment. It includes instructions for installing all
identity and privilege management, audit and monitoring service, and multi-factor authentication components. It also describes how to install the Agent for
Windows, and how to enable services on agent-managed Windows computers.
If your deployment plan includes identity and privilege management, as well as audit and monitoring service, you should review the details in Planning a
deployment before installing any components.
In a production environment, you should use separate computers for different components to ensure scalability and performance. For information about
setting up an evaluation environment on a single computer for testing, see the Evaluation Guide for Windows.
Installation Checklist
As a preview of what’s involved in the installation process, the following steps summarize what you need to do and the information you should have on hand
for a successful deployment of Server Suite.
To prepare for installation:
1. Analyze your network topology to determine where to install components and services and any hardware or software updates required.
For a review of the decisions to make and recommended hardware configuration, see Planning a deployment.
2. Create a list of the computers where you plan to install different components.
For example, list the computers where you plan to install agents, collectors, audit store databases, consoles, and group policy extensions.
If you are installing the audit and monitoring service infrastructure, you should use a dedicated computer for each component, so that the audit
collector service, audit store database, and audit management database are on separate computers with high-speed and reliable network connectivity.
For a review of the requirements associated with each component, see Planning a deployment.
3. Determine the scope of the audit installation.
The most common deployment scenario is a single installation for an Active Directory site, but you can have more than one installation, if needed, and
use subnets to limit the scope of the installation. If you are only implementing access management, you can skip this step, Step 4, and Step 7 through
Step 10.
For a review of what constitutes an installation, see Deploying the audit and monitoring service infrastructure and Decide on the scope of the
installation.
4. Create Active Directory security groups for managing the permissions required for the audit and monitoring service infrastructure.
For a review of the Active Directory security groups to create, see Create security groups for auditing. If you are only implementing identity and privilege
management, you can skip this step.
5. Install Access Manager on at least one computer that can connect to the Active Directory forest.
6. Open Access Manager and add containers for licenses and zones to the Active Directory forest.
7. Install Microsoft SQL Server.
If you are not a database administrator in your organization, you should submit a service request or contact an administrator who has permission to
create databases for assistance. For more information about preparing a SQL Server database engine for auditing, see Installing and configuring
Microsoft SQL Server for auditing. If you are only implementing access management, you can skip this step.
8. Install Audit Manager and Audit Analyzer.
For more information about installing these products, see Installing the Audit Manager and Audit Analyzer consoles. If you are only implementing identity
and privilege management, you can skip this step.
9. Open Audit Manager to create a new installation for auditing.
For more information about using Audit Manager to create a new installation and audit store, see Creating a new installation. If you are only
implementing identity and privilege management, you can skip this step.
10. Install the audit collector service on at least two Windows computers.
You can add collectors to the installation at any time. For more information about installing and configuring collectors, see Installing and configuring
audit collectors. If you are only implementing identity and privilege management, you can skip this step.
11. Install an Agent for Windows on each Windows computer that you want to manage or audit.
For more information about installing and configuring Agent for Windows, see Installing the Agent for Windows.
12. Install additional consoles on any Windows computer that you want to use for identity and privilege management, or audit and monitoring service.
After the initial deployment, you can add new agents, collectors, audit stores, and audit store databases to the audit installation or create additional
installations at any time.
Installing Server Suite and Updating Active Directory
When you install Server Suite, components for the following features are installed:
The Identity Platform, which enables MFA login, endpoints, and other platform services.
The Privilege Elevation Service, which enables users and zone-joined computers to have elevated privileges.
The Audit & Monitoring Service, which enables audit and monitoring service data to be collected and stored.
The Agent for Windows, which enables each computer where the agent is installed to be managed by Server Suite software.
The Licensing Service, which works together with Server Suite components to monitor and report usage and activity for all types of licenses. For more
information about the licensing service, see the License Management Administrator’s Guide
You can select which features to install from the Delinea software setup program.
After Server Suite are installed, you must enable some or all of them on each agent-managed computer. The enablement step lets you decide which services
are available on each agent-managed computer.
Things to remember
At least one zone must be created before an agent-managed computer can be enabled to use the identity and privilege management features that you
install. If no zones are available, the agent-managed computer will not have the option of being joined to the authentication and privilege elevation
services.
When the Agent is upgraded or when it adds the Identity Platform, a corporate endpoint enrollment is performed in the Privileged Access Service. The
endpoint device moves into the endpoint category and the device is marked as corporate owned.
Running the Setup Program on a Windows Computer
You can install components for all Server Suite from the Server SuiteCD or a downloaded ISO or ZIP file. After you access the distribution media, the setup or
autorun program copies the necessary files to the local Windows computer. There are no special permissions required to run the setup or autorun program
other than permission to install files on the local computer.
To install Delinea software on Windows:
1. Log on to the computer you have selected for administrative tasks and browse to the location where you have saved downloaded Delinea software files.
If you have a physical CD, the Getting Started page is displayed automatically. If the page is not displayed, open the autorun.exe file to start the
installation of Delinea software.
2. On the Getting Started page, click Authentication & Privilege to start the setup program for authentication and privilege elevation services.
Note: {/b}The Authentication & Privilege components are the recommended first components to install so that Access Manager is available for you
to use to create zones. At least one zone must be created before you can enable the authentication and privilege elevation services on an agent-
managed computer.
If any programs must be updated before installing, the setup program displays the updates required and allows you to install them. After updates are
complete, you can restart the setup program.
3. At the following screen, select Yes to install Microsoft SQL Server Compact. The Access Manager console uses the Microsoft SQL Server Compact for
storage.
If you select No, Microsoft SQL Server Compact is not installed and some features of Access Manager are not available.
5. Review the terms of the license agreement, click I agree to these terms, then click Next.
6. Type your name and company name, then click Next.
7. Expand and select the Administration and Utilities components you want to install, then click Next.
If you are only managing identity and privileges for Windows computers, you can install a subset of the components. For a Windows-only deployment,
select the following components:
ADUC property page extension if you want to include profiles when displaying properties in Active Directory Users and Computers.
Access Manager console (all) if you want to use an administrative console to manage zones and roles.
Group Policy Management Editor extension if you want to deploy group policies.
Installing Report Services is optional. If you select this option, see Installing and configuring Microsoft SQL Server for auditing for additional
details.
For a Windows-only deployment, you can deselect Utilities to skip the installation of those components.
8. Accept the default location for installing components, or click Browse to select a different location, then click Next.
9. Review the components you have selected, then click Next.
The setup program begins installing the selected components.
10. Click Finish to complete installation.
11. Optionally install additional Server Suite components as follows:
Licensing Service. This service is installed by default when you install the Authentication & Privilege components, and usually does not need to
be installed separately. For more information about the licensing service, see the License Management Administrator’s Guide.
Audit & Monitor. The Auditing and Monitoring Service is not installed automatically with any other components, and must be installed
separately if you intend to use auditing and monitoring features. For installation details, see Installing the Audit Manager and Audit Analyzer
consoles.
Agent for Windows. To install the agent on client Windows computers so that those computers can be managed by Server Suite, see Installing
the Agent for Windows.
Opening Access Manager to Update Active Directory
The first time you start Access Manager, a Setup Wizard prepares the Active Directory forest with parent containers for licenses and zones. The Setup
Wizard also sets the appropriate permissions for the objects automatically. For more information about using the Setup Wizard to update Active Directory,
see Starting Access Manager for the first time.
Installing and Configuring Microsoft SQL Server for Auditing
If you want to audit user activity on Windows, you must have at least one Microsoft SQL Server database instance for the audit management database and
audit store databases. We recommend that you use a dedicated instance of SQL Server for the audit management database. A dedicated SQL Server
instance is an instance that does not share resources with other applications. The audit store databases can use the same dedicated instance of SQL Server
or their own dedicated instances.
There are three database deployment scenarios for your installation:
Evaluation—Use the SQL Server Express with Advanced Services setup program (SQLEXPRADV_x64_ENU.exe) to create a new instance of Microsoft
SQL Server Express. You should only use Microsoft SQL Server Express for evaluation or for limited use in a test environment. You should not use SQL
Server Express databases in a production environment.
If you choose to install a different version of Microsoft SQL Server Express for an evaluation and the version requires .NET version 3.5 SP1, you will need
to manually install the .NET files yourself (the installer doesn't include these files).
Manual installation with system administrator privileges—Install a Microsoft SQL Server database instance for which you are a system
administrator or have been added to the system administrator role.
Manual installation without system administrator privileges—Have the database administrator (DBA) install an instance of Microsoft SQL
Server and provide you with system administrator credentials or information about the database instance so that you can create the management
database and audit store databases.
Downloading and Installing SQL Server Manually
You can use an existing Microsoft SQL Server database engine or install a new instance. You can download Microsoft SQL Server software from the Microsoft
website or through the Support Portal](https://www.delinea.com/login/?portal=support). In selecting a version of Microsoft SQL Server to download, you
should be sure it includes Advanced Services. Advanced Services are required to support querying using SQL Server full-text search.
After downloading an appropriate software package, run the setup program using your Active Directory domain account and follow the prompts displayed to
complete the installation of the SQL Server database engine.
Configuring SQL Server to Prepare for Audit and Monitoring Service
After you install the SQL Server database engine and management tools, you should configure the SQL Server instance for audit and monitoring service by
doing the following:
Depending on the version of SQL Server you install, you might need to manually enable full text search. For example, use SQL Server Surface Area
Configuration for Services and Connections to start the full-text search service.
Use SQL Server Configuration Manager to enable remote connections for TCP/IP.
Use SQL Server Configuration Manager to restart the SQL Server and SQL Server Browser services.
Verify whether SQL Server is using the default TCP port 1433 for network communications. If you use a different port, you should note the port number
because you will need to specify in the server name when you create the management and audit store databases.
Installing the Audit Manager and Audit Analyzer Consoles
You can install Audit Manager and Audit Analyzer on the same computer or on different computers. The computers where you install the consoles must be
joined to the Active Directory domain and be able to access the audit management database.
In most cases, the consoles are installed together on at least one computer.
To install Audit Manager and Audit Analyzer on the same computer:
1. Log on to the computer you have selected for administrative tasks and browse to the location where you have saved downloaded Delinea files.
If you have a physical CD that you made from the ISO image file, the Getting Started page is displayed automatically. If the page is not displayed, open
the autorun.exe file to start the installation of Delinea software.
2. On the Getting Started page, click Audit & Monitor to start the setup program for audit and monitoring service service components.
In the rare case where the administrator should not have access to the Audit Analyzer, select Audit Manager, then click Next.
After you install Audit Manager, you are prompted to create a new installation. If you want to create the installation at a later time, you can run the setup
program again to create a new installation.
Creating a New Installation
Before you can begin audit and monitoring service, you must create at least one installation and a management database. Creating the management
database, however, requires SQL Server system administrator privileges on the computer that hosts the SQL Server instance. If possible, you should have a
database administrator add your Active Directory domain account to the SQL Server system administrators role.
If you have not been added to the system administrators role, you should contact a database administrator to assist you. For more information about creating
a new installation when you don’t have system administrator privileges, see How to create an installation without system administrator privileges.
To create a new installation and management database as a system administrator:
1. Log on using an Active Directory account with permission to install software on the local computer.
2. Open the Audit Manager console to display the New Installation wizard.
The New Installation wizard displays automatically the first time you start Audit Manager. You can also start it by clicking Action > New Installation
or from the right-click menu when you select the Audit Manager node.
3. Type a name for the new installation, then click Next.
Tip: {/b}Name the installation to reflect its administrative scope. For example, if you are using one installation for your entire organization, you might
include the organization name and All or Global in the installation name, such as AcmeAll. If you plan to use separate installations for different regions or
divisions, you might include that information in the name, for example AcmeBrazil for a regional installation or AcmeFinance for an installation that
audits computers in the Finance department.
4. Select the option to create a new management database and verify the SQL Server computer name, instance name, and database name are correct,
then click Next.
If the server does not use the default TCP port (1433), you must provide the server and instance names separated by a backslash, then type a comma
and the appropriate port number. For example, if the server name is ACME, the instance name is BOSTON, and the port number is 1234, the server name
would be ACME\BOSTON,1234.
If you’re connecting to a SQL Server availability group listener, click Options (next to the Server Name) and enter the following connection string
parameters:
MultiSubnetFailover=Yes
5. Type the license key you received, then click A d d or click Import to import the keys directly from a file, then click Next.
6. Accept the default location or click Browse to select a different Active Directory container to which you want to publish audit-related information, then
click Next.
7. Select Enable video capture recording of user activity if you want to capture a full video record of desktop activity on Windows computers when
users are audited, then click Next.
Selecting this option enables you to review everything displayed during an audited user session, but will increase the audit store database storage
requirements for the installation. You can deselect this option if you are only interested in a summary of user activity in the form of audit trail events.
Audit trail events are recorded when users log on, open applications, and select and use role assignments with elevated rights.
8. Review details about the installation and management database, then click Next.
If you have SQL Server system administrator (sa) privileges and can connect to the SQL Server instance, the wizard automatically creates the
9. Select the Launch Add Audit Store Wizard option if you want to start the Add Audit Store wizard, then click Finish.
If you want to create the first audit store database at a later time, you should deselect the Launch Add Audit Store Wizard option and click Finish.
For more information about adding the first audit store database, see Create the first audit store.
How to Create an Installation without System Administrator Privileges
If you do not have the appropriate permission to create SQL Server databases, you cannot use the New Installation wizard to create the management
database without the assistance of a database administrator.
If you do not have system administrator privileges, the wizard prompts you to specify another set of credentials or generate SQL scripts to give to a database
administrator. For example:
If you don’t have a database administrator immediately available who can enter the credentials for you, you cannot continue with the installation.
To create an installation when you don’t have system administrator privileges:
1. Select the option to generate the SQL scripts, then click Next.
2. Select the folder location for the scripts, then click Next.
3. Review details about the installation and management database you want created, then click Next.
The wizard generates two scripts: Script1 prepares the SQL Server instance for the management database and Script2 creates the database.
4. Click Finish to exit the New Installation wizard.
5. Send the scripts to a database administrator with a service or change control request.
Note: {/b}You should notify the database administrator that the scripts must be run in the proper sequence and not modified in any way. Changes to the
scripts could render the database unusable.
6. After the database administrator creates the database using the scripts, open the Audit Manager console to run the New Installation wizard again.
7. Type the name of the installation, then click Next.
8. Select Use an existing database and verify the database server and instance name, then click the Database name list to browse for the database
name that the database administrator created for you.
If the server does not use the default TCP port, specify the port number as part of the server name. For example, if the port number is 1234, the server
name would be similar to ACME\BOSTON,1234.
9. Select the database name from the list of available databases, click O K, then click Next.
10. You should only select an existing database if the database was created using scripts provided by Delinea.
11. Type a license key or import licenses from a file, then click Next.
12. Review details about the audit management database to be installed, then click Next.
Create the First Audit Store
If you selected the Launch Add Audit Store Wizard at the end of the New Installation Wizard, the Add Audit Store Wizard opens automatically. You can also
open the wizard at any time by right-clicking the Audit Stores node in the Audit Manager console and choosing Add Audit Store.
To create the first audit store:
1. Type a display name for the audit store, then click Next.
Tip: {/b}If your plan specifies multiple audit stores, use the name to reflect the sites or subnets serviced by this audit store. Note that an audit store is
actually a record in the management database. It is not a separate process running on any computer. You use a separate wizard to create the databases
for an audit store.
2. Click Add Site or Add Subnet to specify the sites or subnets in this audit store.
If you select Add Site, you are prompted to select an Active Directory site.
If you select Add Subnet, you are prompted to type the network address and subnet mask.
After you make a selection or type the address, click O K. You can then add more sites or subnets to the audit store. When you are finished adding
sites or subnets, click Next to continue.
The computer you use to host the audit store database should be no more than one gateway or router away from the computers being audited. If
your Active Directory sites are too broad, you can use standard network subnets to limit the scope of the audit store.
3. Review information about the audit store display name and sites or subnets, then click Next.
4. Select the Launch Add Audit Store Database Wizard option if you want to create the first audit store database, then click Finish.
Create the Audit Store Database
If you selected the Launch Add Audit Store Database Wizard check box at the end of the Launch Add Audit Store Wizard, the Add Audit Store Database Wizard
opens automatically. You can also open the wizard at any time from the Audit Manager console by expanding an audit store, right-clicking the Databases
node, and choosing Add Audit Store Database.
To create the first audit store database:
1. Type a display name for the audit store database, then click Next.
The default name is based on the name of the audit store and the date the database is created.
2. Select the option to create a new database and verify that the SQL Server computer name, instance name, and database name are correct.
The default database name is the same as the display name. You can change the database name to be different from the display name, if you want to
use another name.
When entering the SQL Server host computer name, note that you can enter either the server short name (which is automatically resolved to its fully
qualified domain name, or FQDN) or the actual server FQDN or the CNAME alias for the server.
If the database is an Amazon RDS SQL Server:
1. Select the This is an Amazon RDS SQL Server option.
2. In the Server Name field, enter the RDS SQL Server database instance endpoint name used for Kerberos authentication.
For example, if the database host name is northwest1 and the domain name is sales.acme.com, then the endpoint name would be
northwest1.sales.acme.com.
Click Options to enter additional connection string parameters or to enable data integrity checking.
You can enable or disable data integrity checking once, when you create the audit store database. To change the state, you must rotate to a new
audit store database.
Connecting to SQL Server on a Remote Computer
To create an audit store database on a remote computer, there must be a one-way or two-way trust between the domain of the computer on which you are
running the Add Audit Database wizard and the domain of the computer hosting SQL Server. The Active Directory user account that you used to log on to the
computer where the Audit Manager is installed must be in a domain trusted by the computer running SQL Server. If there is no trust relationship, you must log
on using an account in the same domain as the computer running SQL Server. If you are accessing the computer running SQL Server remotely, you can use
the Run As command to change your credentials on the computer from which you are running the wizard.
Verify Network Connectivity
The computer hosting the SQL Server database for the active audit store server be online and accessible from the Audit Manager console and from the
clients in the Active Directory site or the subnet segments you have defined for the audit store. You should verify that there are no network connectivity
issues between the computers that will host collectors and those hosting the SQL Server databases.
How to Create the Database without System Administrator Privileges
administrator. If you don’t have database administrator credentials or a database administrator immediately available who can enter the credentials for you,
you should generate the scripts, then follow the prompts displayed to exit the wizard.
To add the database to the audit store after you have generated the scripts:
1. Send the scripts to a database administrator with a service or change control request.
Note: {/b}You should notify the database administrator that the scripts must be run in the proper sequence and not modified in any way. Changes to the
scripts could render the database unusable.
2. After the database administrator creates the database using the scripts, open the Audit Manager console.
3. Expand the installation node, then expand Audit Stores and the specific audit store you for which you want a new database.
4. Select Databases, right-click, then click Add Audit Store Database. For example:
6. Select Use an existing database and select the database that the database administrator created for you.
Because this is the first audit store database, you also want to make it the active database. This option is selected by default. If you are creating the
database for future use and don’t want to use it immediately, you can deselect the Set as active database option.
The installation, management database, and first audit store database are now ready to start receiving user session activity. Next, you should install the
collectors and, finally, the agents to complete the deployment of the audit and monitoring service infrastructure.
Installing and Configuring Audit Collectors
After you have created a new installation, with an audit management database and at least one audit store and audit store database, you must add the
collectors that will receive audit records from the agents and forward those records to the audit store. For redundancy and scalability, you should have at
least two collectors. For more information about planning how many collectors to use and the recommended hardware and network configuration for the
collector computers, see Decide where to install collectors and audit stores.
Set the Required Permission
Before you configure a collector, you should check whether your user account has sufficient permissions to add new collector accounts to the audit store
database. If you are a database administrator or logged on with an account that has system administrator privileges, you should be able to configure the
collector without modifying your account permissions. If you have administrative rights on the computer hosting Audit Manager but are not a database
administrator, you can set the appropriate permission before continuing.
To set the permission required to add accounts to the audit store database:
1. Open Audit Manager.
2. Expand the installation, then expand Audit Stores.
3. Select the audit store that the collector will connect to, right-click, then click Properties.
5. Click A d d to search for and select the user who will configure the collector.
6. Select the Manage SQL Logins right, then click O K.
Install the Collector Service Using the Setup Program
If your user account has sufficient permissions to add new collector accounts to the audit store database, you can install a collector by running the setup
program on a selected computer. When prompted to select components, select Audit Collector and deselect all of the other components, then click Next.
Follow the instructions in the wizard to select the location for installing files and to confirm your selections, then click Finish to complete the installation.
Configure the Audit Collector Service
By default, when you click Finish, the setup program opens the Collector Configuration Wizard. Alternatively, you can start the configuration wizard at any
time by clicking Configure in the Collector Control Panel.
To configure the collector service:
1. Type the port number to use, then click Next.
The default port is 5063 for communication from agents to the collector. If you want to use a different port, the wizard checks whether the port is open
in the Windows firewall.
If you’re running another firewall product, open the port with the tools provided by that product. If there’s an upstream firewall—such as a dedicated
firewall appliance—between the Collector and the computers to be audited, contact the appropriate personnel to open the port on that firewall.
2. Select the installation of which this collector will be a part, then click Next.
The configuration wizard verifies that the installation has an audit store that services the site that the collector is in and that the collector and its audit
store database are compatible.
3. Select whether you want to use Windows authentication or SQL Server authentication when the collector authenticates to the audit store database,
then click Next.
In most cases, you should choose Windows authentication to add the computer account to the audit store database as a trusted, incoming user.
If Microsoft SQL server is in a different forest or in an untrusted forest, you should use SQL Server Management Studio to set up one or more SQL Server
login accounts for the collector. After you create the SQL Server login account for the collector to use, you can select SQL Server authentication, then
type the SQL Server login name and password in the wizard.
4. Choose the maximum number of connections you want for the SQL Server Connection Pool, then click Next.
5. Review your settings for the collector, then click Next.
6. Click Finish to start the collector service and close the wizard.
Installing the Agent for Windows
You must install an agent on every Windows computer that you want to manage or audit. You can install the agent in the following ways:
Interactively, by running the setup program on each computer.
When the installation finishes, the agent configuration panel launches automatically. You can configure the agent to enable Delinea services right
away, or exit the configuration panel and configure the agent later. See Installing the Agent for Windows interactively using the setup program for
details about this installation method.
Silently, by executing appropriate commands in a terminal window on each computer. This method also requires you to configure the agent registry
settings on each computer. See Installing the Agent for Windows silently on remote Windows computers for details about this installation method.
A variation of this method is to use a third-party software distribution product, such as Microsoft System Center Configuration Manager (SCCM), to
execute the appropriate command line remotely, so that the software is deployed on remote computers. Using a third-party software distribution
product is not covered in this guide.
Silently and centrally, by using a Windows group policy to execute installation and registry configuration commands remotely on each computer that is
joined to the domain. See Installing the Agent for Windows silently on all domain computers by using group policy for details about this installation
method.
Regardless of the deployment method you choose, you should first make sure that the computers where you plan to deploy meet all of the installation
prerequisites.
Verifying Prerequisites
Before installing the Agent for Windows, verify the computer on which you plan to install meets the following requirements:
The computer is running a supported Windows operating system version.

The computer has sufficient processing power, memory, and disk space for the agent to use.
The computer has Windows security update KB3033929 installed if it is running Windows 7 with Service Pack 1 or Windows Server 2008 R2 with Service
Pack 1.
The computer has Windows Installer version 4.5 or newer.
If you are installing interactively using the setup program, the setup program can check that the local computer meets these requirements and install any
missing software required. if you are installing silently or from a Group Policy Object, you should verify the computers where you plan to install meet these
requirements.
Installing the Agent Interactively Using the Setup Program
The procedure in this section describes how to use the agent installation wizard to install the agent on a Windows computer. After the agent is installed, you
will enable the agent to use one or more services that you installed earlier on the main administrative computer as described in Installing Server Suite and
updating Active Directory.
To install the agent on Windows using the setup program:
1. Insert the distribution CD into the computer on which you wish to install the agent or browse to the location where you have saved downloaded files.
2. On the Getting Started page, click Agent to start the setup program for the agent.
If the Getting Started page is not displayed, open the autorun.exe file to start the installation of Delinea software.
3. If a previous version of the agent is installed, click Yes when prompted to upgrade the Agent for Windows.
6. Accept the default location for installing components, or click Change to select a different location, then click Next.
7. In the Ready to install Agent for Windows page, click Install.
8. Click Finish to complete the installation and start the agent configuration panel.
Go to Configuring the agent for details about using the agent configuration panel to enable Delinea services and configure how the agent interacts with
those services.
Configuring the Agent
By default, when you click Finish, the setup program opens the agent configuration panel. In the agent configuration panel, you can enable the agent to
connect to Delinea services that are installed on the main administrative computer as described in Installing Server Suite and updating Active Directory. After
a service is enabled, you can use the agent configuration panel to configure settings that define how the agent will interact with each service.
The first time the agent configuration panel opens, it does not display any services for you to enable. Services display in the agent configuration panel only
after you manually instruct the configuration panel to check for services and display those that are eligible to be enabled.
Only services that are installed and configured as required are eligible to be enabled. For example, if you installed the Privilege Elevation Service earlier (as
described in Running the setup program on a Windows computer) but did not create a zone, the Privilege Elevation Service does not display on the list of
services that you can enable.
To enable services using the agent configuration panel:
1. If the agent configuration panel is not open, open it by clicking Agent Configuration in the list of applications in the Windows Start menu.
2. In the agent configuration control panel, click Add service.
All Delinea services that are available to be enabled are displayed.
3. In the list of Delinea services, highlight a service and click O K.
4. Provide additional information about the service that you are enabling:
Audit & Monitoring Service:
In the Select an Audit Installation page, select an audit store from the list of available audit stores. Click Next, and the computer is connected to
the audit store.
Identity Platform Settings:
1. In the Connect to Identity Platform page, type the URL of the identity platform instance to connect to, or select an instance from the list of
registered platform instances in the forest. Click Next.
2. In the Multi-factor authentication for Windows Login page, ensure that the check box to enable multi-factor authentication is selected. Next,
use the All Active Directory accounts button or Accounts below button to specify which Active Directory accounts are enabled for
multi-factor authentication login. If you select Account below, use the A d d and Remove buttons to select accounts. Click Next when
you are finished.
Privilege Elevation Service:
1. In the Join to a zone page, type a zone or select a zone from the list of available zones. You can also choose to select the option to retrieve the
zone data before the computer restarts. This option can be helpful in situations where you might lose connection to the domain after
restarting, such as when you're using a VPN connection.
Click Next, and the computer is joined to the zone.
2. After the computer is joined to a zone, you must reboot the computer to activate all privilege elevation service features on the computer.
If the zone that you select is already configured with a Privileged Access Service tenant, the message Identity Platform enabled
displays after the computer joins the zone. In this situation, the instance is managed by the zone, and is shown as read-only.
5. To add additional services, click Add service and repeat the preceding steps.
When you are done, the services that you enabled are shown in the Enabled services section of the agent configuration panel.
6. If necessary, continue to configure Delinea services after their initial configuration during enablement as described in these sections:
Configuring agent settings for the audit and monitoring service
Configuring agent settings for offline audit and monitoring service storage
Configuring agent settings for the Identity Platform
Configuring agent settings for privilege elevation
Configuring Agent Settings for the Audit and Monitoring Service
If you want to reconfigure agent settings for auditing on a Windows computer after initially configuring them during enablement (or if you did not use the
agent configuration panel when you enabled the service), you can open the agent configuration panel manually and configure the agent as described in this
section.
To configure agent settings for audit and monitoring service:
1. In the Windows Start menu, click Agent Configuration in the list of applications.
The agent configuration panel opens, and displays the Delinea services that are currently enabled. You can configure any service listed in the Enabled
services section.
2. Click Audit & Monitoring Service, and then click Settings.
3. In the General tab, click Configure.
4. Select the maximum color quality for recorded sessions, then click Next.
See Selecting the maximum color quality for recorded sessions for more information on the configuration of this setting.
5. Specify the offline data location and the maximum percentage of disk that the offline data file should be allowed to occupy, then click Next.
See Configuring agent settings for offline audit and monitoring service storage for more information on the configuration of this setting.
6. Select the installation that the agent belongs to, then click Next.
7. Review your settings, then click Next.
8. Click Finish.
9. Click Close in the General tab to save your changes.
For information about using the Troubleshooting tab, see Monitoring collector status locally.
Selecting the Maximum Color Quality for Recorded Sessions
Because auditing Windows computers captures user activity as video, you can configure the color depth of the sessions to control the size of data that must
be transferred over the network and stored in the database. A higher color depth increases the CPU overhead on audited computers but improves resolution
when the session is played back. A lower color depth decreases network traffic and database storage requirements, but reduces the resolution of recorded
sessions.
The default color quality is low (8-bit).
Configuring Agent Settings for Offline Audit and Monitoring Service Storage
The “Maximum size of the offline data file” setting defines the minimum percentage of disk space that should be available, if needed, for audit and monitoring
service. It is intended to prevent audited computers from running out of disk space if the agent is sending data to its offline data storage location because no
collectors are available.
For example, if you set the threshold to 10%, auditing will continue while spooling data to the offline file location as long as there is a least 10% of available disk
space on the spool partition. When the available disk space reaches the threshold, auditing will stop until a collector is available.
The agent checks the spool disk space by periodically running a background process. By default, the background process runs every 15 seconds. Because of
the delay between background checks, it is possible for the actual disk space available to fall below the threshold setting. If this were to occur, auditing would
stop at the next interval. You can configure the interval for the background process to run by editing the
HKLM\Software\Centrify\DirectAudit\Agent\DiskCheckInterval registry setting.
Configuring Agent Settings for the Identity Platform
If you want to reconfigure agent settings for the Identity Platform on a Windows computer after initially configuring them during enablement (or if you did not
use the agent configuration panel when you enabled the service), you can open the agent configuration panel manually and configure the agent as described
in this section.
To configure agent settings for the Identity Platform:
The agent configuration panel opens, and displays the Delinea services that are currently enabled. You can configure any service listed in the Enabled
services section.
2. Click Identity Platform, and then click Settings.
3. In the General tab, review the authentication options in the Features area:
Multi-factor authentication:
If the status is Enabled, the computer is not joined to a zone, and you can configure all Identity Platform settings that are shown in the
General tab.
If the status is Enabled per zone settings, the computer is joined to a zone, and most Identity Platform settings are based on the zone
configuration.
In this situation, the Browse and Details buttons in the General tab are disabled, because those features are controlled by the zone
configuration. The only configuration that you can perform in the General tab is to change the proxy server settings.
Multi-factor authentication displays in the Authentication Source drop-down once the status is Enabled per zone settings.
RADIUS authentication:
If the status is Enabled, you can select this option to use as the authentication option for privilege elevation. You can enable this option
either by group policy or a local configuration setting.
If the status is Disabled, click Details to configure and enable the RADIUS server connection.
RADIUS authentication displays in the Authentication Source drop-down once the status is Enabled.
4. To change proxy server settings:
1. Click Change.
2. Specify a new proxy server address.
3. Click O K.
5. To change to a different Identity Platform instance (only configurable if the computer is not joined to a zone):
1. Click Browse.
2. Select an instance from the list of registered platform instances in the forest.
3. Click O K.
6. To specify which Active Directory accounts require multi-factor authentication (only configurable if the computer is not joined to a zone):
1. Click Details.
2. Use the All Active Directory accounts button or Accounts below button to specify which Active Directory accounts are enabled for multi-
factor authentication login. If you select Account below, use the A d d and Remove buttons to select accounts.
3. Click O K.
For information about using the Troubleshooting tab, see the Multi-factor Authentication Quick Start Guide.
Configuring Agent Settings for Privilege Elevation
If you want to reconfigure agent settings for privilege elevation on a Windows computer after initially configuring them during enablement (or if you did not
use the agent configuration panel when you enabled the service), you can open the agent configuration panel manually and configure the agent as described
in this section.
If you haven't yet configured the agent settings for privilege elevation, see Configuring the agent for details.
To configure existing agent settings for privilege elevation:
The agent configuration control panel opens, and displays the services that are currently enabled. You can configure any service listed in the Enabled
services section.
2. Click Privilege Elevation Service, and then click Settings.
3. In the General tab, click Change.
4. In Change the zone for this computer, click Browse.
5. Click Find Now to search for an appropriate zone for the agent.
6. Select a zone from the list of search results, then click O K.
7. Click O K to use the zone you selected.
For information about using the Troubleshooting tab, see Running diagnostics and viewing logs for the agent.
Installing the Agent without MFA Login
If desired, you can install the Agent for Windows without the MFA login feature. This can be useful in situations where either you don't want to enforce multi-
factor authentication or you don't use Privileged Access Service.
To install the Agent for Windows without the MFA login feature:
Run the following command:
msiexec /i "Agent for Windows64.msi" /qn PRIVILEGEONLY=1
Installing the Agent for Windows Silently on Remote Windows Computers
If you want to perform a “silent” (also called unattended) installation of the Agent for Windows, you can do so by specifying the appropriate command line
options and Microsoft Windows Installer (MSI) file to deploy. You must execute the commands on every Windows computer that you want to manage or audit.
Note: {/b}You can also use a silent installation to automate the installation or upgrade of the agent on remote computers if you use a software distribution
product, such as Microsoft System Center Configuration Manager (SCCM), to deploy software packages. However, installing remotely in this way is not
covered in this topic.
Deciding to Install with or without Joining the Computer to a Zone
Before you begin a silent installation, you should decide whether you will wait until later to join the computer to a zone, or join the computer to a zone as part
of the installation procedure.
If you install without joining a zone during installation:
See Configuring registry settings for details about the registry settings that you can configure manually after the installation finishes.
See Installing silently without joining a zone for details about performing the installation.
If you install and join a zone during installation:
You use a transform (MST) file that is provided with Server Suite to configure a default set of agent-specific registry keys during the silent installation.
You can optionally edit the MST file before performing the installation to customize agent-specific registry settings for your environment.
You can optionally use the registry editor to configure registry settings after the installation finishes.
See Configuring registry settings for details about the registry settings that you can configure by editing the MST file.
See Editing the default transform (MST) file for details about how to edit the MST file before you perform the installation.
See Installing and joining a zone silently for details about performing the installation.
Configuring Registry Settings
When you perform a silent installation, several registry settings specific to the agent are configured by the default MSI file. In addition, a default transform
(MST) file is provided for you to use if you join the computer to a zone as part of the installation procedure. When executed together, the default MSI and MST
files ensure that the computer is joined to a zone, and that a default set of agent-specific registry keys is configured.
If your environment requires different or additional registry settings, you can edit the MST file before performing an installation. Then, when you execute the
MSI and MST files to perform an installation, your customized registry settings are implemented. For details about how to edit the MST file, see Editing the
default transform (MST) file.
Note: If you do not join the computer to a zone during installation, you do not use the MST file. In this situation, you can create or edit registry keys
manually after the installation finishes by using the registry editor.
The following table describes the agent-specific registry settings that are available for you to configure during installation (by using the MST file) or after
installation (by using the or the registry editor). Use the information in this table if you need to configure registry settings differently than how they are
configured by the default MSI and MST files. Keep the following in mind as you review the information in the table:
The default MSI file is named Agent for Windows64.msi, and is located in the Agent folder in the Delinea download location.
The default MST file is named Group Policy Deployment.mst, and is located in the Agent folder in the Delinea download location.
If you want to install the agent without the MFA login feature, use the Group Policy Deployment-PrivilegeOnly.mst, and is located in the Agent folder in
the Delinea download location.
All of the settings in the following table are optional, although some are included in the default MSI and MST files so that they are configured when the
MSI and MST files execute during an installation.
Settings that are included in the default MSI and MST files are noted in the table.
Some settings are environment-specific, and therefore do not have a default value. Others are not environment-specific, and do have a default value.
The settings described in the table are located in the MSI file’s Property table.
The Setting column shows both the property name in the MSI file, and the name (in parentheses) of the registry key in the Windows registry.
Service Setting Description
Specifies the color depth of sessions recorded by the agent. The color depth affects the resolution of
the activity recorded and the size of the records stored in the audit store database when you have video
capture auditing enabled. You can set the color depth to one of the following values: 0 to use the native
Auditing and REG_MAX_FORMAT color depth on an audited computer. 1 for a low resolution with an 8-bit color depth 2 for medium
Monitoring (MaxFormat) resolution with a 16-bit color depth (default) 4 for highest resolution with a 32-bit color This setting
is included in the default MSI file. In the registry, this setting is specified by a numeral (for
example, 1). In the MSI file Property table, it is specified by the # character and a numeral (such as #1).
Specifies the minimum amount of disk space that must be available on the disk volume that contains
the offline data storage file. You can change the percentage required to be available by modifying this
registry key value. This setting is included in the default MSI file. In the registry, this setting is
Auditing and REG_DISK_CHECK_THRESHOLD
specified by a numeral (for example, 1). In the MSI file Property table, it is specified by the # character
Monitoring (DiskCheckThreshold)
and a numeral (such as #10). The default value is 10, meaning that at least 10% of the disk space on the
volume that contains the offline data storage file must be available. If this threshold is reached and
there are no collectors available, the agent stops spooling data and audit data is lost.
Specifies the offline data storage location. The folder location you specify will be where the agent
saves (“spools”) data when it cannot connect to a collector. This setting is not included in the
Auditing and
REG_SPOOL_DIR (SpoolDir) default MSI file. To use it, you must edit the default transform (MST) file so that it is processed
Monitoring
together with the MSI file during installation, or create it manually in the registry after the installation
finishes.
Specifies the unique global identifier (GUID) associated with the installation service connection point.
Auditing and REG_INSTALLATION_ID This setting is not included in the default MSI file. To use it, you must edit the default
Monitoring (InstallationId) transform (MST) file so that it is processed together with the MSI file during installation, or create it
manually in the registry after the installation finishes.
Auditing and Specifies what level of information, if any, is logged. Possible values are: off information warning error
REG_LOG_LEVEL_DA (LogLevel)
Monitoring verbose This setting is included in the default MSI file. The default value is information.
Specifies which users have rescue rights. Type user SID strings in a comma separated list. For
Authentication REG_RESCUEUSERSIDS example: user1SID,user2SID,usernSID This setting is not included in the default MSI file. To
& Privilege (RescueUserSids) use it, you must edit the default transform (MST) file so that the setting is processed together with the
MSI file during installation, or create it manually in the registry after the installation finishes.
Authentication REG_LOG_LEVEL_DZ Specifies what level of information, if any, is logged. Possible values are: off information warning error
& Privilege (LoggingLevel) verbose This setting is included in the default MSI file. The default value is information.
Specifies whether the computer is joined to the zone where the computer was pre-created. This
setting is used only during installation and does not have a corresponding registry key. Possible values
Authentication are: 0 - The computer is not joined to the zone. 1 - The computer is joined to the zone. This setting is
GPDeployment
& Privilege included in the default transform (MST) file. To use it, you must execute the MST file when you
execute the default MSI file. The default value is 1, meaning that the pre-created computer is joined to
the zone.
Specifies the option to retrieve the zone data before the computer restarts. This option can be helpful
Authentication
ZONEDATA in situations where you might lose connection to the domain after restarting, such as when you're using
& Privilege
a VPN connection. Possible values are: YES NO The default value is NO in the default MSI file.
Editing the Default Transform (MST) File
This section describes how to edit the default transform (MST) file Group Policy Deployment.mst. You execute the MST file together with the installation
(MSI) file during a silent installation if you want to join the computer to a zone as part of the installation.
The MST file specifies registry key settings that are different from those specified in the MSI file. You use the MST file to customize a silent installation for a
specific environment. Using an MST file makes it unnecessary to edit registry keys manually after a silent installation.
Note: {/b}By default, auditing features are installed when you install the Agent for Windows. The service is not enabled by default, but the service item in the
configuration panel appears if the feature is enabled through group policy.
See Installing and joining a zone silently for instructions about how and when to execute the MST file.
To edit the default MST file:
1. You will use the Orca MSI editor to edit the MST file. Orca is one of the tools available in the Windows SDK. If the Windows SDK (or Orca) is not installed
on your computer, download and install it now from this location:
https://msdn.microsoft.com/en-us/library/aa370557(v=vs.85).aspx
2. Execute Orca.exe to launch Orca.
3. In the Agent folder in the Delinea download location, copy Group Policy Deployment.mst so that you have a backup.
4. In Orca, select File > Open and open the Agent for Windows64.msi file located in the Agent folder in the Delinea download location.
5. In Orca, select Transform > Apply Transform.
6. In Orca, navigate to the Agent folder in the Delinea download location and open Group Policy Deployment.mst.
The file is now in transform edit mode, and you can modify data rows in it.
7. In the Orca left pane, select the Property table.
Notice that a green bar displays to the left of “Property” in the left pane. This indicates that the Property table will be modified by the MST file.
The right pane displays the properties that configure registry keys when the MSI file executes. Notice that the last property in the table, GPDeployment,
is highlighted in a green box. This indicates that the GPDeployment property will be added to the MSI file by the MST file.
Note: {/b}In order for the computer to join a zone during installation, the Group Policy Deployment.mst file must specify the GPDeployment property
with a value of 1.
8. In the right pane, edit or add properties as necessary to configure registry keys for your environment. See the table in Configuring registry settings for
details about agent-specific properties that are typically set.
To edit an existing property, double click its value in the Value column and type a new value.
To add a new property, right-click anywhere in the property table and select Add Row.
9. After you have made all necessary modifications, select Transform > Generate Transform to save your modifications to the default MST file.
Be sure to save the MST file in the same folder as the MSI file. If the MST and MSI files are in different folders, the MST file will not execute when you
execute the MSI file.
The MST file is now ready to be used as described in Installing and joining a zone silently.
Installing Silently without Joining a Zone
This section describes how to install the agent silently without joining the computer to a zone. This procedure includes configuring registry settings manually
using the registry editor or a third-party tool.
Note: {/b}To install the agent and join the computer to a zone during installation, see Installing and joining a zone silently for more information.
Check prerequisites:
1. Verify that the computers where you plan to install meet the prerequisites described in Verifying prerequisites. If prerequisites are not met, the silent
installation will fail.
2. If you are installing audit and monitoring service, verify that the following tasks have been completed:
1. Installed and configured the SQL Server management database and the SQL Server audit store database.
2. Installed and configured one or more collectors.
3. Configured and applied the DirectAudit Settings group policy that specifies the installation name.
To install the Agent for Windows silently without joining the computer to a zone:
1. Open a Command Prompt window or prepare a software distribution package for deployment on remote computers.
2. Run the installer for the Agent for Windows package. For example:
msiexec /qn /i "Agent for Windows64.msi"
By default, none of the services are enabled.
3. Use the registry editor or a configuration management product to configure the registry settings for each agent. See the table in Configuring registry
settings for details about agent-specific registry keys that you can set.
For example, under
HKEY_LOCAL_MACHINE\Software\Centrify\DirectAudit\Agent, you could set the DiskCheckThreshold key to a value other than the default value of
10%.
Installing and Joining a Zone Silently
This section describes how to install the agent and join the computer to a zone at the same time. The procedure described here includes the following steps in
addition to executing the MSI file:
You first prepare (pre-create) the Windows computer account in the appropriate zone.
You execute an MST file together with the MSI file to join the computer to a zone and configure registry settings during the installation.
Note: {/b}Joining the computer to a domain is applicable only when you are enabling Authentication & Privilege features.
To install the agent without joining the computer to a zone during installation, see Installing silently without joining a zone for more information.
1. Verify that the computers where you plan to install meet the prerequisites described in Verifying prerequisites. If prerequisites are not met, the silent
2. If you are enabling audit and monitoring service in addition to Authentication & Privilege, verify that the following tasks have been completed:
3. Configured and applied the DirectAudit Settings group policy that specifies the installation name.
To install the Agent for Windows and add a computer to a zone during installation:
1. Prepare a computer account in the appropriate zone using Access Manager or the PowerShell command New-CdmManagedComputer. See Preparing
Windows computer accounts for more information.
2. You will use the default transform file Group Policy Deployment.mst in Step 3 to update the MSI installation file so that the computer is joined to the zone
in which it was pre-created in Step 1. You can optionally modify Group Policy Deployment.mst to change or add additional registry settings during
installation.
If you want to edit Group Policy Deployment.mst to change or add additional registry settings and have not yet done so, edit it now as described in
Editing the default transform (MST) file.
In order for the computer to join the zone from Step 1, the Group Policy Deployment.mst file must specify the GPDeployment property with a value of 1.
msiexec /i "Agent for Windows64.msi" /qn TRANSFORMS="Group Policy Deployment.mst"
By default, Privilege Elevation Service is enabled by joining a zone. If the zone is also configured with a platform instance (tenant), Identity Services
Platform will also be enabled. If you want to enable auditing, configure the corresponding registry value in the Property page of the MST file:
REG_CURRENT_INSTALLATION or via Group Policy.
You can also choose to install the specify the option to retrieve the zone data before the computer restarts. This option can be helpful in situations
where you might lose connection to the domain after restarting, such as when you're using a VPN connection. To specify that the agent retrieves zone
data before the computer restarts, run the following command:
msiexec /i "Agent for Windows64.msi" /qn TRANSFORMS="Group Policy Deployment.mst" ZONEDATA="YES"
The computer will be restarted automatically to complete the deployment and start the agent.
Installing the Agent for Windows Silently on All Domain Computers by Using Group Policy
You can use a group policy object (GPO) to automate the deployment of the Agent for Windows. Because automated installation fails if all the prerequisites
are not met, be sure that all the computers on which you intend to install meet the requirements described in Verifying prerequisites.
Note: If you install the Common Component before you install the agent, information about the installation of the agent can be captured in a log
file for troubleshooting purposes.
To create a new group policy object for the deployment of the Agent for Windows:
1. Prepare computer accounts in the appropriate zones using Access Manager or the PowerShell command New-CdmManagedComputer. See Preparing
Windows computer accounts for more information.
2. Copy the Agent for Windows64.msi and Group Policy Deployment.mst installer files to a shared folder on the domain controller or another location
accessible from the domain controller.
When you select a folder for the agent installer files, right-click and select Share with > Specific people to verify that the folder is shared with
Everyone or with appropriate users and groups.
3. Right-click on the Agent for Windows64.msi file, then select Edit with Orca.
4. Select Transform > Apply Transform, then select Group Policy Deployment.mst from the same location as the Agent for Windows64.msi file.
5. Select the Property table on the left hand side and add the following:
Property Value Comments
(Ex: https://aaa1111.my.delinea.net:443/) Note: You must

REG_ZONELESS_MFA_TENANT Tenant URL
include “https://” and “:443/”.
REG_ZONELESS_MFA_ENABLED true Default Value = false
Comma-Separated user or group names, or

REG_EFFECTIVE_ZONELESS_MFA_USERS
enter * for All AD users
REG_CONNECTOR_BRANDING Delinea
1. Close Orca and save the changes as a new mst file.
Make sure you save it in the same location as the msi file.
2. On the domain controller, click Start > Administrative Tools > Group Policy Management.
3. Select the domain or organizational unit that has the Windows computers where you want to deploy the Agent, right-click, then select Create a GPO
in this domain, and Link it here.
4. For example, you might have an organizational unit specifically for Delinea-managed Windows computers. You can create a group policy object and link
it to that specific organizational unit.
5. Type a name for the new group policy object, for example, Agent Deployment, and click O K.
6. Right-click the new group policy object and click Edit.
7. Expand Computer Configuration > Policies > Software Settings.
8. Select Software installation, right-click, and select New > Package.
9. Navigate to the folder you selected previously, then select the Agent for Windows64.msi file, and click Open.
10. Select Advanced and click O K.
11. Click the Modifications tab and click A d d.
12. Select the .mst file created previously, then click Open, and click O K.
13. Close the Group Policy Management Editor, right-click the Agent Deployment group policy object, and verify that Link Enabled is selected.
By default, when computers in the selected domain or organizational unit receive the next group policy update or are restarted, the agent will be
deployed and the computer will be automatically rebooted to complete the deployment of the agent.
If you want to test deployment, you can open a Command Prompt window to log on to a Windows client as a domain administrator and force group policies to
be updated immediately by running the following command:
gpupdate /force
After installation, all of the registry settings that were specified in the MSI and MST files are configured. If you need to further configure registry settings, use
the registry editor to do so as described in Installing the Agent for Windows silently on remote Windows computers.
Installing the Agent on a Computer Running Server Core
You cannot use the autorun.exe or the setup.exe program to install components on a computer that is configured to run as a Server Core environment.
Instead, you must install from Microsoft Installer (.msi) files using the msiexec command-line program.
To install the Agent for Windows on Server Core:
1. Use the Deployment Image Servicing and Management (DISM) or another command-line tool to enable the .NET Framework.
For example, if the .NET Framework is located on the installation media in the D:\sources\sxs folder, use the following command:
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs
2. Copy the Agent for Windows files to the Server Core computer.
For example:
copy D:\Common\Centrify* C:\Centrify Agent
copy D:\Agent\* C:\Centrify Agent
3. Install the Common Component service using the .msi file.
For example, to install the Common Component on a computer with 64-bit architecture, you might use the following command:
msiexec /i Centrify Common Component64.msi" /qn
4. Install the Agent for Windows using the .msi file.
For example, to install the Agent for Windows with identity management, privilege elevation, auditing, and monitoring features enabled on a computer
with 64-bit architecture, you might run the following command:
msiexec /qn /i "Agent for Windows64.msi" ADDLOCAL=ALL
You can also choose to install the specify the option to retrieve the zone data before the computer restarts. This option can be helpful in situations
where you might lose connection to the domain after restarting, such as when you're using a VPN connection. To specify that the agent retrieves zone
data before the computer restarts, run the following command:
msiexec /i "Agent for Windows64.msi" /qn TRANSFORMS="Group Policy Deployment.mst" ZONEDATA="YES"
5. Restart the computer with the appropriate shutdown options to complete the installation and start agent services.
For example, you might run the following command:
shutdown /r
Installing Additional Consoles
You can install additional consoles on any domain computers you want to use for managing access using zones or roles, or for managing the audit and
monitoring service infrastructure. You also might want to install additional consoles on the computers to be used by auditors. You can install additional
consoles from the Management Services setup program or from individual component-specific setup programs. For example, you can use the Audit Analyzer
Console.exe setup program to install Audit Analyzer on a computer.
Installing Group Policy Extensions Separately from Access Manager
Group policy extensions are packaged separately from Access Manager, enabling the following installation options:
You can install group policy extensions on any Windows domain computer without also installing Access Manager on the computer.
You can install Access Manager on any Windows domain computer without also installing group policy extensions on the computer.
The group policy extension package has its own .exe and .msi installer files, so that you can install group policy extensions interactively through an
installation wizard (by executing the .exe file) or silently from the command line (by executing the .msi file). Additionally, you can select or de-select the
group policy extensions for installation when you run the Access Manager installation wizard.
Note: {/b}At the start of an installation, the group policy extension installer checks for previously installed versions of group policy extensions. If it detects a
newer version than the version you are trying to install, the installation stops.
To install standalone group policy extensions interactively with the group policy installer:
1. On the Windows domain computer where you will install group policy extensions, navigate to the Delinea ISO bundle containing the group policy
extension installer file.
The installer file is named  CentrifyDC_GP_Extension-*#.#.#-architecture.*exe.
For example: 
CentrifyDC_GP_Extension-5.2.3-win64.exe
In most distributions, the installer file is located in the following folder in the ISO bundle:
DirectManage\Group Policy Management Editor Extension
2. Double-click the installer file to launch the Group Policy Management Editor Extension Setup Wizard.
3. Follow the wizard installation instructions to install the group policy extensions.
To install standalone group policy extensions interactively with the Management Services installer:
1. On the Windows domain computer where you will install group policy extensions, launch the setup program for Management Services components as
described in Installing Server Suite and updating Active Directory.
2. Proceed through the setup program until you reach the wizard page in which to select individual components to install.
3. De-select every component except for Group Policy Management Editor extension for managing group policies:
4. Continue to follow the wizard installation instructions as described in Installing Server Suite and updating Active Directory until you are finished with the
installation.
To install standalone group policy extensions silently without installing Access Manager:
1. Open a Command Prompt window.
2. Execute the group policy extension .msi installer file from the command line.
The installer file is named  CentrifyDC_GP_Extension-*#.#.#-architecture.*msi.
For example: 
CentrifyDC_GP_Extension-5.2.3-win64.msi
In most distributions, the installer file is located in the following folder in the ISO bundle:
DirectManage\Group Policy Management Editor Extension
The following is a typical command to run the 64-bit .msi installer file: 
msiexec /qn /i "CentrifyDC_GP_Extension-5.2.3-win64.msi”
For more information about installing with a .msi file, see Installing the Agent for Windows silently on remote Windows computers.
To install Access Manager interactively without installing group policies:
1. On the Windows domain computer where you will install group policy extensions, launch the Management Services setup program and select
Authentication & Privilege as described in Installing Server Suite and updating Active Directory.
2. Proceed through the setup program until you reach the wizard page in which to select individual components to install.
3. De-select the Group Policy Management Editor extension component.
4. Continue to follow the wizard installation instructions as described in Installing Server Suite and updating Active Directory until you are finished with the
installation.
Managing Zones
Zones are the key component for organizing access rights and role assignments for Windows computers. This chapter describes how to use Access Manager
to create zones, manage zone properties, add Windows computers to selected zones, and move and rename zone objects.
Starting Access Manager for the First Time
The first time you start Access Manager, a Setup Wizard prepares the Active Directory forest with parent containers for licenses and zones. The Setup
Wizard also sets the appropriate permissions for the objects. For example, all authenticated users are granted read access of the Licenses container by
default. These steps are typically performed once by a domain administrator. If you choose to, you can create the container objects manually.
What to do Before Updating Active Directory
Before you use Access Manager the first time, you should contact the Active Directory administrator to determine the appropriate location for the Licenses
and Zones parent containers and whether you have the appropriate rights for completing this task. The specific administrative rights required for this task
depend on the policies of your organization and who has permission to create classStore and parent and child container objects in Active Directory.
If you don’t have administrative rights to create container objects in Active Directory, a domain administrator in the forest root domain can manually create
the container objects and set the rights on those objects to allow other users to complete the initial configuration without being members of an
administrative group.
The following table describes the minimum rights that must be granted on manually created container objects for other users to successfully complete the
configuration with the Setup Wizard.
This target
object
Licenses
Read all properties Create classStore objects Modify permissions This object only
container

Write Description property Write displayName property
objects
By default, all Authenticated Users have read and list contents permission for the Licenses container and all
of its child objects.
Zones container Read all properties Create classStore objects Create Container objects This object only

objects
If you are a domain administrator and use the Setup Wizard to create the container objects, you should add a security group for Zone Administrators to Active
Directory. Set the following permissions on the parent Zones container to allow other users to manage zones.
Zones container Read all properties Create Container objects Delete Container objects This object only
Write displayName property This object and all child objects
A Windows Active Directory administrator performs this task, depending on your organization’s policies, by running the Setup Wizard or by manually creating
container objects and notifying another user of the location of the container objects. The user who runs the Setup Wizard must be granted the rights required
to create classStore objects.
How Often You Should Perform this Task
In most organizations, you only do this once for an Active Directory forest. However, if you want to create more than one administrative boundary, you can
create additional parent containers as needed.
The following instructions illustrate how to run the Setup Wizard from Access Manager.
To update Active Directory using Access Manager:
4. Select a location for installing license keys in Active Directory, then click Next.
The default container for license keys is  domain_name/Program Data/Centrify/Licenses. To create or select a container
object in a different location, click Browse. If an Active Directory administrator has created the Licenses container for you, click Browse and navigate
to the appropriate location. The Setup Wizard will create a classStore object in the location you specify.
You can create additional containers in other locations later using the Manage Licenses dialog box.
5. Review the permission requirements for the container, then click Yes to confirm your selection.
7. Select Create default zone container and specify a location for the Zones container, then click Next.
The default container location for zones is  domain_name/Program Data/Centrify/Zones. To create or select a container object
in a different location, click Browse. If an Active Directory administrator has created the Zones container for you, click Browse and navigate to the
appropriate location. The Setup Wizard will create a classStore object in the location you specify.
Any zones you create are placed in this container location by default.
The next three pages only apply if you are managing multiple platforms. For a Windows-only deployment, you can click Next to leave the following
options unselected:
Grant computer accounts in the Computers container permission to update their own account information.
Register administrative notification handler for Microsoft Active Directory Users and Computers snap-in.
Activate profile property pages.
After you click Finish, the Access Manager console is displayed.
What to Do Next
Create at least one parent zone.
Access control for Windows computers

How zones organize access rights and roles
Identity and privilege management
Preparing to Use Zones
One of the most important aspects of managing computers with Delinea software is the ability to organize computers, users, and groups into zones. You use
zones to create logical groupings for:
Managing access rights, role definitions, and role assignments.

Delegating administrative tasks based on a separation of duties.
Associating groups of computers and groups of users with specific role assignments.
Controlling Access through Hierarchical Zones
Server Suite for Windows only supports hierarchical zones. Hierarchical zones enable you to establish parent-child zone relationships, allowing rights, role
definitions, and role assignments to be inherited down the zone hierarchy. One of the first decisions you need to make is how you can use the zone hierarchy
most effectively.
With hierarchical zones, you define rights and roles in a parent zone so that those definitions are available in one or more child zones, as needed. Child zones
can also inherit user and group role assignments. At any point in the zone hierarchy, you can choose to use or override information from a parent zone.
There are no predefined limits to the number of zones that can be used in a zone hierarchy or the number of levels deep zones can be nested in the hierarchy
you define. For practical purposes, keep the hierarchy similar to the following:
One or more top-level parent zones that includes all users and groups.
One to three levels of intermediate child zones based on natural access control or administrative boundaries.
There are many different approaches you can take to defining the scope of a zone, including organizing by platform, department, manager, application,
geographical location, or how a computer is used. The factors that are most likely to affect the zone design, however, will involve managing access rights and
roles and delegating administrative tasks to the appropriate users and groups.
Managing Access Rights and Roles Using Zones
Zones enable you to grant specific rights to users in specific roles on specific computers. By assigning roles, you can control the scope of resources any
particular group of users can access and what those users can do. For example, all of the computers in the finance department could be grouped into a single
zone called “finance” and the members of that zone could be restricted to finance employees and senior managers, each with specific rights, such as
permission to log on locally, access a database, update certain files, or generate reports.
Rights represent specific operations users are allowed to perform. A role is a collection of rights that can be defined in a parent or child zone and inherited.
For example, a role defined in a parent zone can be used in a child zone, in a computer role, or at the computer level.
System and Predefined Rights
There are specialized login rights, called system rights. The system rights for Windows computers are:
Console login is allowed: Specifies that users are allowed to log on locally using their Active Directory account credentials.
Remote login is allowed: Specifies that users are allowed to log on remotely using their Active Directory account credentials.
PowerShell remote access is allowed: Specifies that users are allowed to log on remotely to PowerShell.
There are additional predefined rights that allow access to specific applications. For example, there are predefined rights that allow users to run
Performance Monitor or Server Manager without having an administrator’s password. You grant users permission to access computers by assigning them to
a role that includes at least one login right. You can then give them access to specific applications or privileges using additional predefined or custom access
rights.
Granting Permission to Log On
By default, zones always provide the Windows Login role to allow users to log on locally or remotely to computers in the zone. Users must have at least one
role assignment that grants console or remote login access or they will not be allowed to access any of the computers in the zone.
Note: The Windows Login role grants users the permission to log on whether they are authenticated by specifying a user name and password or by
using a smart card and personal identification number (PIN).
Because the Windows Login role only allows users to log on, it is often assigned to users in a parent zone and inherited in child zones. However, the Window
Login role does not override any native Windows security policies. For example, most domain users are not allowed to log on to domain controllers. Assigning
users the Windows Login role does not grant them permission to log on to the domain controllers. Similarly, if users are required to be members of a specific
Windows security group, such as Server Operators or Remote Desktop Users, to log on to specific computers, the native Windows security policies take
precedence.
There are additional predefined roles that grant specific rights, such as the Rescue always permit login role that grants users the “rescue” right to log on
if audit and monitoring service is required but not available. In general, at least one user should be assigned this role to ensure an administrator can log on if
the audit and monitoring service service fails or a computer becomes unstable.
Delegating Administrative Tasks in Hierarchical Zones
You can use zones to delegate administrative tasks to specific users or groups. Using hierarchical zones, you can give separate groups of administrators the
authority to manage a different sets of computers and users without granting them permission to perform actions on other computers, in other zones, or on
other Active Directory objects. You can also use zones to establish a separation of duties so that only specific groups or users can perform certain tasks. For
example, you can create a child zone for software-development and give the dev_mgrs group authority to manage rights and roles and manage role
assignments on the computers in that zone.
By creating child zones and delegating administrative tasks within those zones, you can group computers that form a natural administrative set or that should
be managed by different administrative teams. For example, you might want to group computers that are managed by a local support organization in one
zone and computers that are managed by a corporate IT group in another zone. You can also control what different groups of users can do within each child
zone. For example, you can set up regional zones to provide a separation of duties, authorizing users in San Francisco to manage computers in their local
office while a team in Barcelona has authority to join computers to the zone and manage role assignments for offices located in Spain but does not have the
authority to add users or groups.
Associating Computers and Role Assignments
You can use zones to associate a set of users with a particular role assignment to a particular set of computers. This association of a group of computers with
a particular role assignment is called a computer role. For example, you might have several computers that are dedicated to a specific function, such as
hosting Oracle databases, or to a functional area, such as payroll. Some groups of users who access these computers might require a specific set of rights.
For example, the database administrators who access the computers hosting Oracle databases need different rights than users who are updating payroll
records in the databases being hosted.
A computer role enables you to link the privileges associated with the database administrator role assignment, such as permission to backup and restore or
create new tables, with the computers that host the Oracle databases. You can configure a separate computer role for the rights required by the users
processing payroll on the same set of computers. The computer role creates the link between users with a specific role assignment, database administrator
or payroll department, and the computers where that role assignment applies.
If you add an Oracle database server, you add it to the computer group. If new users are assigned the database administrator role, they automatically receive
the appropriate access rights on the computers hosting Oracle databases.
You can also use computer roles to specify whether you want session-level auditing for a group of computers.
Creating a New Parent Zone
In most cases, you design a basic zone structure as part of the deployment process. After the initial deployment, you can create new hierarchical zones any
time you have new administrative boundaries. For example, if you acquire another organization, add offices that are managed by a different group, or
restructure the organization along different functional lines, you are likely to need new zones.
What to Do Before Creating a New Parent Zone
Before you can create parent zones, you must have installed Access Manager and run the Setup Wizard. You should also have a basic zone design that
describes how you are organizing information, for example, whether you are using one top-level parent zone or more than one parent zone. There are no other
prerequisites for performing this task.
Wizard. To create new zones, your user account must be a domain user with the following permissions:
Select this target

object
Select this target
object
Parent container for new On the Object tab, select Allow to apply the following permission to this object and all child objects: Create Container
zones, for example: Objects Create Organizational Unit Objects. Note: Both permissions are required if you want to allow zones to be created as
domain/Delinea/Zones either container objects or organizational unit objects.
Parent container for On the Object tab, select Allow to apply the following permission to this object only: Create group objects Write Description
Computers in the zone property
Note: If the Active Directory administrator manually sets the permissions required to create zones, you should verify that the account also has
permission to add an authorization store, define rights and roles, and manage role assignments.
A Windows domain administrator performs this task, depending on your organization’s policies. The user who creates the zone is responsible for delegating
After you are fully deployed, you create new zones infrequently to address changes to your organization.
The following instructions illustrate how to create a new parent zone using Access Manager. Examples of script that uses the Windows API are included in the
Software Developer’s Kit or may be available in community forums on the Delinea website. For code examples using ADEdit, see the ADEdit Command
Reference and Scripting Guide.
To create a new parent zone using Access Manager:
2. In the console tree, select Zones and right-click, then click Create New Zone.
In most cases, you should use the default parent container and container type that you created when you configured the Active Directory forest, then
click Next.
For zones that include Windows computers, you should always use the default zone type, which creates the new zone as a hierarchical zone. For
Windows computers, only hierarchical zones are supported. The only reasons for changing the default other settings would be if you want to:
Create a zone as an organizational unit because you want to assign a Group Policy Object to the zone.
4. In most cases, you'll want to leave the Skip permission delegation option deselected. If you select this option, the service does not set the security
descriptor for the zone; you'll need to go in and set that attribute yourself. Some organizations prefer to set security descriptors manually. Security
descriptors include security information such as the object owner, who has access rights to the object, and so forth.
5. Review information about the zone you are creating, then click Finish.
What to Do Next
After you create a new parent zone, you might want to create its child zones.
How zones organize access rights and roles

Preparing to use zones
Creating Child Zones
For Windows, the primary reason for creating child zones is to inherit role definitions and role assignments from a parent zone. Less often, you might want to
use a child zone to override role definitions and assignments that you have made in a parent zone. For example, if you have created a role definitions that
allows a user to run a specific application with administrative privileges in a parent zone, you can use child zones to limit the scope of that right to specific
subsets of computers.
What to Do Before Creating Child Zones
Before you create child zones, you must have installed Access Manager, run the Setup Wizard to create the Zones container, and created at least one parent
zone. You should also have a basic zone design that describes the zone hierarchy for the child zone. There are no other prerequisites for performing this task.
Wizard. To create new child zones, your user account must be a domain user with the following permissions:
Container for the parent zones, for On the Object tab, select Allow to apply the following permission to this object and all child objects: Create
example if the parent zone is berlin: Container Objects Create Organizational Unit Objects. Note: Both permissions are required if you want to allow
domain/MyOU/Zones/berlin zones to be created as either container objects or organizational unit objects.
On the Object tab, select Allow to apply the following permission to this object only: Create group objects Write
Description property These permissions are only needed if you are supporting “agentless” authentication in the new
the zone
zone.
Note: If the Active Directory administrator manually sets the permissions required to create zones, you should verify that the account also has
permission to add an authorization store, define rights and roles, and manage role assignments.
After you are fully deployed, you create new child zones infrequently to address changes to the scope of ownership and administrative tasks.
The following instructions illustrate how to create a new child zone using Access Manager.
To create a new child zone using Access Manager:
2. In the console tree, expand Zones and individual zones to select the parent zone for the new child zone.
3. Right-click, then click Create Child Zone.
Because this is a child zone, you should use the default parent container and container type, then click Next.
5. In most cases, you'll want to leave the Skip permission delegation option deselected. If you select this option, the service does not set the security
descriptor for the zone; you'll need to go in and set that attribute yourself. Some organizations prefer to set security descriptors manually. Security
descriptors include security information such as the object owner, who has access rights to the object, and so forth.
6. Review information about the child zone, then click Finish.
Opening and Closing Zones
Because properties and objects are organized into zones, you must open a zone to work with its contents. If you open a parent zone, its child zones are also
available for you to use by default. If you open a child zone, you can choose whether to open its parent zone. Once you open a zone, it stays open until you
close it and you can have multiple zones and zone levels open at the same time. If you have a large number of zones, you should close any zones you aren’t
actively working with for better performance.
As an alternative to opening individual or parent and child zones manually, you can automatically load all zones in a forest or all zones in a specific container
at startup time. If you choose to load all zones, you cannot manually close zones.
To open an individual parent or child zone:

2. In the console tree, select Zones and right-click, then click Open Zone.
3. Type all or part of the name of the zone you want to open, then click Find Now.
4. Select the zone to open from the list of results, then click O K. You can use the CTRL and SHIFT keys to select multiple zones.
After you open the zones you want to work with, you should save your changes when you exit the Access Manager console, so that the open zones are
displayed by default the next time you start the console.
To close an open zone:

2. Expand the zone hierarchy until you can select the specific zone name you want to close
3. Right-click, then click Close.
4. Click Yes to confirm that you want to close the zone.
To load all zones automatically:
2. In the console tree, select Access Manager, right-click, then click Options.
3. On the Filter Settings tab, select Load all zones, then select connected forest to automatically load all zones in the forest or click Browse to
navigate to specific container.
Selecting this option prevents you from opening or closing any zones manually. You should not select the Load all zones option if you want to manually
open and close individual zones for performance reasons.
Changing Zone Properties
After you create a zone, you can change its zone properties at any time. For example, if you want to change the parent zone for a child zone, you can do so by
modifying the child zone’s properties.
To change the properties for a zone:
2. Expand Zones to display the list of zones, then expand the zone hierarchy until you see the zone you want to modify.
3. Select the zone, right-click, then click Properties.
4. On the General tab, you can view the location of the zone in Active Directory and the zone type.
From the General tab, you can make the following changes:
Change the parent zone for a child zone.
Modify the zone description.
Select a specific Licenses container for the zone to use.
Configure the access control list of permissions for the zone.
For example, click Browse to find and select a new zone to use as the parent of a child zone, then click O K to save the new zone properties. For
Windows computers, only the properties on the General tab are applicable.
Moving a Child Zone to a New Parent Zone
You can make an existing zone a child of another zone by dragging and dropping it from one zone to another or by changing the Parent zone field on the zone’s
Properties General tab.
If a child zone inherits role assignments from its parent zone, the console displays a warning message and prevents you from moving the zone until you have
removed the role assignments. If moving the zone creates a circular hierarchy, the console prevents you from moving the zone.
Delegating Control of Administrative Tasks
If you are the creator of a parent or child zone, you can use the Access Manager console to give other users and groups permission to perform specific types
of administrative tasks within each zone you create. For example, assume you have created a zone called Finance. Certain users or groups who access
computers in that zone must be able to perform administrative tasks on their own without your help. You want to give them the permissions they require to
accomplish specific tasks without turning over full control to anyone except your most trusted administrative staff. Using Access Manager and the Zone
Delegation Wizard, you select the appropriate groups and users for the Finance zone and specify exactly what each do. For example:
Members of the group Finance-ITStaff are allowed to perform All administrative tasks within the Finance zone. They can change zone properties, join
and remove computers from the zone, define rights and roles, and assign roles to users and groups. Only your most trusted administrative staff are
members of this group.
Members of the group FinanceManagers are allowed to join and remove computers from the zone and assign roles to users and groups.
Members of the group FinanceUsers are allowed to add users, add groups, and join computers to the zone, but perform no other tasks.
The users jason.ellison and noah.stone have permission to remove computers from the zone.
In most cases, each zone should have at least one Active Directory group that can be delegated to perform all administrative tasks, so that members of that
group can manage their own zone. You are not required to create or use a zone administrator group for every zone. However, assigning the management of
each zone to a specific user or group creates a natural separation of duties for administrative tasks.
If you delegate control for individual tasks—for example, by assigning only the join computers task to one group and only the add and remove users tasks to
another—you should ensure the members of each group know the tasks they are assigned.
You can delegate administrative tasks for parent zones, for child zones, and for individual computers. Because computer-level overrides are essentially
single computer zones, you can assign administrative tasks to users and groups at the computer level.
To delegate which users and groups have control over the objects in a zone:
2. Expand Zones to display the list of zones, then expand the zone hierarchy until you see the specific zone you want to modify.
3. Select the zone, right-click, then click Delegate Zone Control.
4. Click A d d to find the users, groups, or computer accounts to which you want to delegate specific tasks.
5. Select the type of account—User, Group, or Computer—to search for, type all or part of the account name, then click Find Now.
6. Select one or more accounts from the list of results, then click O K.
7. Repeat Step 4 through Step 6 until you are finished adding users and groups to which you want to assign the same administrative tasks, then click Next.
8. Select the tasks you want to delegate to the user or group, then click Next.
For example, if you want all of the members of the group you selected in the previous steps to be able perform all administrative tasks for a zone, select
All.
10. Review your delegation settings, then click Finish to close the wizard.
Granting the Authority to Perform All Administrative Tasks
Only the administrator who creates a zone has full control over the zone’s properties and only that administrator can delegate administrative tasks to other
users. For each zone you create, you should identify at least one user or group that can be delegated to perform all administrative tasks. For example, if you
have a Finance zone, you may want to create a Finance Admins group in Active Directory and then delegate All tasks to that group so that members of that
group can manage the zone.
Although you are not required to create or use a zone administrator group for every zone, assigning the management of each zone to a specific user or group
simplifies the delegation of administrative tasks.
If members of the designated administrative group must be able to create parent or child zones, they should be assigned the rights described in Creating a
new parent zone and Creating child zones.
Restricting Authority to Specific Administrative Tasks
You can use the Zone Delegation Wizard to set up fine-grain control over the specific administrative tasks different sets of users or groups can perform. For
example, you can choose to grant the Join Operators group permission to join computers to the zone and no other tasks. You can then specify another group
is only allowed add and remove users. If you choose to use fine-grain control over specific administrative tasks, you should ensure the members of those
groups know their restricted authority.
Note: If you delegate administrative tasks to one or more groups that have members logged on, you should inform the group members that they
should log out and log back on so that they can perform the administrative tasks assigned to the group.
Adding Windows Computers to a Zone
To use identity and privilege management features, a Windows computer must have the Agent for Windows installed, be joined to an Active Directory domain,
and joined to a zone. Depending on your organization’s policies, you can either allow any authenticated user with a valid domain account to join a zone or
require a domain administrator account to join a zone.
If you want to have individual users deploy the Agent for Windows on their own computers and join a zone without administrative rights, you can prepare the
zone in advance and let users know which zone to join. If only domain administrators are allowed to join computers to zones, you should log on to computers
with the Agent for Windows installed using an account that has appropriate administrative rights and provide a password.
Preparing Windows Computer Accounts
If joining a zone is restricted to privileged users, you may want to prepare a computer account in the zone before joining. By preparing the computer account
before joining, users can add their computers to the zone without any special rights or permissions in Active Directory.
To prepare a Windows computer account using Access Manager:
2. Expand Zones to display the list of zones, then expand the parent and child zone hierarchy until you see the specific zone to which you want to add the
computer account.
3. Right-click, then click Prepare Windows Computer.
4. Click Find Now to search for and select the computer account to add to the selected zone.
5. Click O K to add the computer account to the Access Manager console in the zone’s Computers container.
6. A dialog box displays that asks if you want to skip permission delegation when creating the computer. In most cases, click N o.
If you click Yes, the service does not set the security descriptor for the zone; you'll need to go in and set that attribute yourself. Some organizations
prefer to set security descriptors manually. Security descriptors include security information such as the object owner, who has access rights to the
object, and so forth.
Changing the Zone for the Computer
You can move computer accounts from one zone to another at any time, if needed. Users who have administrative privileges can change the current zone on
their local computer using the agent configuration panel. You can also change the zone information for a computer from Access Manager by changing its
Active Directory properties or by dragging and dropping the computer from its current to a new zone.
To change the zone for a computer using Access Manager and Active Directory properties:

2. Expand Zones to display the list of zones, then expand the zone hierarchy until you see the specific zone you want to modify.
3. Expand Computers to display the list of computers in the zone.
4. Select the computer that you want to modify, then right-click and select AD Properties.
5. Click the Windows Profile tab.
6. Click Browse and type all or part of the zone name, then click Find Now.
7. Select the new zone for the computer from the list of results, then click O K.
8. If the computer has role assignments defined, Access Manager prevents you from moving the computer until you remove the role assignments.
Leaving a Zone
You can remove a computer from a zone at any time. Users who have administrative privileges can leave the current zone on their local computer using the
agent configuration panel. You can also remove the zone information for a computer from Access Manager by deleting the computer from its current zone.
Leaving the zone does not remove the computer object from Active Directory.
To remove a computer from a zone using Access Manager:
Open Access Manager.

Expand Zones to display the list of zones, then expand the zone hierarchy until you see the specific zone you want to modify.
Expand Computers to display the list of computers in the zone.
Select the computer that you want to remove from the zone, right-click, then select Delete.
Click Yes to confirm the removal of the computer from the zone.
Renaming a Zone
You can rename a zone at any time. For example, if your organization changes how business units are aligned, moves to a new location, or merges with
another organization, you might want to update zone names and descriptions to reflect these changes. You might also want to rename zones if your initial
deployment did not use a naming convention for new zones, and you want to implement one after you have agents deployed.
What to Do Before Renaming a Zone
Before you rename zones, you might want to define and document a naming convention to use for future zones or the reasons for changing the zone name.
You should also identify the computers in the zone to be renamed. You do not need to restart the agent on Windows computers for the new zone name to be
recognized. However, you might need to perform other administrative tasks—such as changing role assignments—after renaming a zone. There are no other
prerequisites for performing this task.
Parent container for an

Click the Properties tab and select Allow to apply the following properties to this object only: Write Description Write
individual zone For example,
name Write Name These are the minimum permissions required to rename a zone and not allow a user or group to modify
a ZoneName container
any other zone properties. You can set permissions manually, or automatically grant these and other permissions to
object, such as:
specific users or groups by selecting the Change zone properties task in the Zone Delegation Wizard.
domain/Zones/arcade
After you are deployed, you rename zones only when you need to address organizational changes or to implement or improve the naming conventions you
use.
The following instructions illustrate how to rename a zone using Access Manager.
To rename a zone using Access Manager:
2. Expand Zones to display the list of zones, then expand any child zones in the zone hierarchy until you see the specific zone you want to modify.
3. Select the zone to change, right-click, then click Rename.
4. Type the new name and, if needed, any changes to the zone description.
You do not have to restart any Agents on the computers in the zone you have renamed. Computers will remain joined to the zone even after changing the
zone name.
5. Users who have administrative privileges can verify the updated zone name on their local computer using the agent configuration panel.
Working Directly with Managed Computers
When you deploy a Agent on a computer, that computer has tools installed locally to allow you to manage access, troubleshoot agent operations, and view
information about roles and role assignments, and auditing status.
Depending on the rights associated with the role you are using, you can use the tools on the managed computer to open new desktops, run individual
applications with elevated privileges, connect to services on remote computers, join or change the zone for a computer, set the level of detail to record in log
files, generate diagnostic information for the agent, and view detailed information about your own or other users’ effective rights and roles.
Using the Agent Configuration
The Agent for Windows provides an agent configuration panel from which you can configure agent settings for the Privileged Access Service, Privilege
Elevation Service, and Audit & Monitoring Service. If you have the appropriate privileges, you can use the agent configuration panel to select the zone for a
computer to join, change the current zone, or remove a computer from a zone.
To use the agent configuration panel to select the zone for a local computer:
1. Log on to a computer where the Agent is deployed.

2. From the Windows Start menu, select Agent Configuration.
3. Click Privilege Elevation Service.
4. Click Settings.
5. On the General tab, click Change.
6. Click Browse, type all or part of the zone name, and click Find Now to search for the zone.
7. Select the new zone in the search results, click O K, then click O K to return General tab.
8. Click Close to return to the agent configuration panel.
You can also use the agent configuration panel to set logging level, view logs, and get diagnostic information about agent operations. For more information
about using the agent configuration panel to configure logging and get diagnostic information, see Troubleshooting and common questions.
If you allow users to join their own computers to a zone, you should notify them of the zone to use and see that they have access to the User's Guide for
Windows.
Working with Zone Role Workflow
You can enable zone role workflow in the Admin Portal so that your users can request access to systems in particular zones. Enabling zone role workflow
requires having a Connector installed in the domain. For improved performance, you can also install the Client with the CSS Extension on the affected
systems.
For details about how to enable zone role workflow, see Working with zone role workflow
Using Zone Role Workflow with the Connector
If you set up zone role workflow with just the Connector, be aware that there will be a delay between when the approver approves the request and when the
user can access the affected systems. Although the Connector updates Active Directory immediately after the approver approves the request, a delay
occurs because it can take some time to replicate the Active Directory information and also because the Agent reloads authorization information from Active
Directory at specified intervals.
Using Zone Role Workflow with the Client
If you set up zone role workflow and also install the Client (so that you'll have installed both the Agent and the Client) and enable the CSS Extension on the
Client, then there is no delay. Once the designated approvers approve the request, the user can access the specified system(s) immediately. The Client uses
the client channel in the background to securely communicate with the Agent.
Note: For deployments that have zone role workflow enabled for use with the Client, the affected systems must have Python 3.4 or later installed.
Managing Access Rights and Roles
This chapter describes how to establish role-based access controls for the computers that have the Agent for Windows installed and identity and privilege
management features enabled.
Basics of Authorization and Access Rights
You can use Access Manager to centrally manage what users can do on computers that have the Agent for Windows installed. For example, you can control
who can log on or connect remotely for each computer in a zone through the assignment of roles. As discussed in Managing access rights and roles using
zones, a right represents a specific operation that a user is allowed to perform.
System Rights Allow Users to Log On
For Windows computers, the most basic rights are the system rights that determine whether a user can log on locally, log on remotely, or both. The rights that
grant users local and remote access are defined by default in the Windows Login role so that you can grant users access simply by assigning the Windows
Login role and without defining any custom roles or any additional access rights. You can enable or disable these system rights in any custom role definition,
but you cannot add, modify, or delete them.
In most cases, you can assign the Windows Login role to all local Windows users, all Active Directory users, or both, to allow users to log on locally or remotely.
However, the system rights in the Windows Login role do not override any native Windows security policies. For example, most domain users are not allowed
to log on locally on domain controllers. Depending on how your organization has configured native Windows security policies, users might need to be
members of a specific Windows security group, such as Server Operators or Remote Desktop Users, to log on to specific computers locally or remotely.
If you would like to require multi-factor authentication for users or groups that use Delinea-managed Windows computers, you must assign them the require
MFA for login role in addition to the Windows Login role as there is no system right to enable multi-factor authentication within the Windows Login role.
If you enable multi-factor authentication, users will be required to type their password and provide a second form of authentication before being able to log
on. For example, you can configure an authentication profile that requires users to answer a phone call, click a link in an email message, respond to a text
message, provide a one-time password (OTP) token, or answer a security question. Before defining this system right, however, you should be aware that
multi-factor authentication for Delinea-managed Windows computers relies on the infrastructure provided by the Privileged Access Service.
For more information about preparing to use multi-factor authentication, see the Multi-factor Authentication Quick Start Guide.
In addition to the system rights that specify whether a user can log on locally or remotely, you can use the Rescue rights setting to specify that users in a
particular role should always be allowed to log on to a computer. This option is intended as a “safety net” for “emergency” situations when users would
normally be locked out. For example, if auditing is required for a role, but the agent is not running or has been removed, users are not allowed to log on. You can
use the rescue rights option to allow selected administrative users access to computers when they would otherwise be locked out and prevented from
logging on. Because this option allows unaudited activity, you should strictly limit its use.
Note: If you do not explicitly set the Rescue rights option for any users, only the local administrator and the domain administrator accounts will
have rescue rights. Those accounts are always allowed to log on by default.
Windows-specific Rights Can Grant Users Privileged Access
In general, you use the default Windows Login role for most users during the initial deployment to prevent disruptions in user access. You can then define
custom roles to add specialized access rights to grant users additional privileges in a controlled manner.
For Windows computers, these specialized access rights are:
Desktop access rights enable users to create additional working environments and run applications in that desktop with their own credentials but as a
member of an Active Directory or built-in group. Users who are assigned to a role with desktop rights can switch from their default desktop to a desktop
with administrator privileges without having to enter an Administrator password. With a desktop right, users can also run any application from their
default desktop using a selected role and credentials without opening a new desktop.
Application access rights enable users to run specific local applications as another user or as a member of an Active Directory or built-in group. Users
who are assigned to a role with application rights can log on with their normal Active Directory credentials and run a specific application using a role
with elevated privileges without having to enter the service account or Administrator password.
Network access rights enable users to connect to a remote computer as another user or as a member of an Active Directory or built-in group to
perform operations, such as start and stop services, that require administrative privileges on the remote computer. Users who are assigned to a role
with network access rights can perform administrative operations on a remote server using a role with elevated privileges that only applies to the
operations performed on the network computer without having to enter the service account or Administrator password. You can use zones to control
who can connect and perform tasks on remote computers and what their elevated privileges allow them to do.
Combining Rights into Roles and Role Assignments
You can combine the system rights and specialized Windows rights into role definitions that reflect the needs of a specific job function, such as database
administrator or web services administrator, or a particular task, such as troubleshooting application failures. You can then assign those roles to specific
users and groups.
You can configure rights, role definitions, and role assignments in any parent or child zone. In most cases, you define rights and roles in a parent zone and
make role assignments in a child zone.
Roles can be assigned to individual Active Directory users or to Active Directory groups. Therefore, you can manage how roles are applied to users completely
through Active Directory group membership.
The rights from multiple role assignments accumulate, which provides great flexibility and granularity in how you define and assign rights and roles. For
example, you can use the Windows Login role to control console and remote access, and define a second role with desktop access rights so that a user
assigned to both roles could log in and create another desktop for accessing applications with administrative privileges. By separating login and desktop
access rights into separate roles, not every user who is allowed to log on can create a desktop with administrative privileges.
Deciding Where to Define and Assign Roles
Because access rights are additive, it is important to consider where you define and assign roles to control who has administrative privileges on which
computers. For example, it might seem reasonable to assign the predefined Windows Login role to all Active Directory users. Doing so, however, could grant
broad permission to log on locally or remotely on computers to which you want to restrict access. If you assign that role in a parent zone, it is inherited along
with any additional rights granted in child zones.
In most cases, it is appropriate to define roles in parent zones, but assign roles carefully in child zones to avoid granting access rights on computers that host
administrative applications or sensitive information.
Adding Predefined Rights to a Zone
There are many predefined rights available that grant access to specific Windows applications. For example, there is a predefined Performance Monitor right
that allows users to run Performance Monitor on a computer without being a local administrator or knowing an administrative password.
You can add any or all of these predefined rights to any zone so they are available to include in role definitions. Alternatively, you can add predefined rights to
individual role definitions without adding them to zones. In either case, you create the predefined rights in the context of a role definition.
To create predefined rights in a zone:
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a predefined right.
3. Expand Authorization > Role Definitions.
4. Select a role definition, right-click, then select Add Right.
5. Select a type of right if you want to filter the list of rights displayed.
For example, select Any Windows Rights or Any Windows Applications to list only Windows-specific rights.
6. Click Create Predefined Rights.
7. Select the specific predefined rights you want created in the zone you selected in Step 2 from the list of available rights, then click O K.
By default, all of the selected predefined rights are added to the role definition in the zone. You can deselect any of the rights you don’t want added to
the role definition.
8. If you have selected at least one of the predefined rights as applicable for the role definition, click O K.
If none of the predefined rights is applicable for the role definition, you can click Cancel to add the rights to the zone without adding them to the role
definition.
You can click Refresh in Access Manager to see the predefined rights listed as Windows application rights.
Enabling Multi-factor Authentication for Windows Rights
In addition to the require MFA for login role, which requires users to provide both their password and a second form of authentication to log on to a
Delinea-managed Windows computer, you can enable multi-factor authentication for a predefined right. When you define a desktop, application, or network
access right, you can choose to enable multi-factor authentication for that right. For example, if you want to require multi-factor authentication before a user
can open a privileged desktop, you would issue that user a role with a predefined desktop right that has multi-factor authentication enabled.
To enable multi-factor authentication for a right definition:
1. Right-click the predefined right after adding it to a role definition.
2. Select Properties.
3. Click the Run As tab and select Re-authenticate current user and Require multifactor authentication.
Note: Before defining this right, you should be aware that multi-factor authentication for Delinea-managed Windows computers relies on
the infrastructure provided by the Privileged Access Service.
4. Click O K.
Using Multi-factor Authentication When There are Selective Cross-forest Trusts
If you have domains in different forests that have a two-way selective trust relationship, any computer or user accounts that are used to log on to the remote
forest must be granted the “Allowed to authenticate” right on the domain controllers in both forests to get role information.
In addition to granting the “Allowed to authenticate” right to users and to computers with the Agent for Windows installed, the right must also be granted to
computers that host your connectors.
After you grant these computers and users the “Allowed to authenticate” right for the domains in both forests, users that are assigned a role with a multi-
factor authentication right for privilege elevation will be able to authenticate using any of the authentication mechanisms that you have assigned to them.
If a connector is not allowed to authenticate on the remote domain controller, some multi-factor authentication mechanisms may fail to authenticate users.
For more information about preparing to use multi-factor authentication, see the Multi-factor Authentication Quick Start Guide.
Defining Desktop Access Rights
When users log on with their normal Active Directory credentials, Windows brings up the default desktop for the user logging on. You can define desktop
rights to enable users to create additional working environments—new desktops—that run using their own credentials but with the privileges of an Active
Directory or built-in group.
Users who are assigned to a role with desktop rights can switch from their default desktop to a desktop with elevated privileges to perform administrative
tasks. For example, if assigned to a role that has a desktop right, a user can create a new desktop and switch to it when he needs perform administrative tasks
such as install new software or stop running services on the local computer account. The user can perform these tasks without having to enter the service
account or Administrator password.
Users who are assigned a role with desktop rights can also select any application on the computer, right-click, and run the application using a selected role.
The difference between the desktop right and an application right is that the desktop right allows the user to run any applications using the privileged account
defined in the desktop right. An application right restricts access to a specific application using the privileged account explicitly defined for that application.
Desktop rights are useful for users who frequently perform tasks that require the privileges associated with the Administrator account.
To define a desktop right:

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a desktop right.
3. Expand Authorization > Windows Right Definitions.
4. Select Desktops, right-click, then click New Windows Desktop.
5. On the General tab, type a name and a description for the desktop right.
For this Do this
For this Do this
Type the name you want to use for this desktop right. For example, if the desktop allows a user to create a desktop using the privileges
Name
associated with a service account, you might include the security group in the name.
Type a description for this desktop right. The description is optional. You can use it to provide a more detailed explanation of the privileges
Description
associated with the desktop.
Priority Set the priority for this desktop right.
1. Click the Run As tab.
You can browse for and select a specific group that will allow you to log on with your own credentials but with the elevated privileges of the specified
group.
Click Add AD Groups or Add Built-in Groups to search for and select a previously-defined or built-in group with the privileges you want to add to
the logged in user’s account.
Select No re-authentication required to allow users to use the desktop right without any additional authentication.
Select Re-authenticate current user if you want to prevent the desktop right and its privileges from being used by anyone not authorized to do so.
Selecting this option also allows you to enable multi-factor authentication for the right. For more information, see Enabling multi-factor authentication
for Windows rights.
If you select the Re-authenticate current user option, users are prompted to re-enter their password to verify their identity before they are allowed to
create a new desktop or switch between desktops. Forcing users to re-authenticate ensures the privileges associated with the desktop are only granted
to users who have been assigned those privileges.
If you select this Re-authenticate current user option for users who are authenticated using a smart card, users must enter a personal identification
number (PIN) or a password to resume working with the desktop.
2. Click O K to save the desktop right.
Where Desktop Rights Apply
Desktop rights can be used on Windows servers and workstations that have a traditional Windows desktop. If the computer you are using is running Windows
8 or 8.1, or Windows Server 2012 or 2012 R2, Windows does not provide access to applications natively when you switch from the default desktop to a
privileged desktop due to changes to the underlying interfaces and supported features within the operating system. To enable access to applications on
computers running these versions of Windows, the Agent for Windows provides a custom start menu. The start menu allows you to open and run applications
as you would on Windows 7 or Windows Server 2008 R2. The start menu is installed on the left side of the taskbar and displays the Delinea logo. This start
menu is only available if you are using a role with Delinea desktop rights and cannot be modified.
Defining Application Rights
Application rights allow users to run specific applications using either another user account or using their own credentials but with the privileges of an Active
Directory or built-in group.
When you create an application right, you specify one or more application executable files to which you want to control access. The capability to specify
more than one executable file in a single application right takes into account situations in which one application might reside in different locations on
different computers. For example, the executable file for SQL Server Management Studio resides in different locations in Windows 2005, Windows 2008, and
Windows 2012. By specifying all instances of the executable file in one application right, you can use that application right to control access to SQL Server
Management Studio on computers running any of those operating systems.
You can also use Delinea application utilities to allow access to common administrative tasks such as software installation, network, and Windows feature
management. For more information on using these utilities, see Using Delinea application utility rights
Note: Although it is possible to define different applications (for example, SQL Server Management Studio and Internet Explorer) in one
application right, this is not a recommended practice. Instead, it is recommended that you create separate application rights for different
applications.
How to Specify Which Applications are in an Application Right
You can specify which application executable files are in an application right in these ways:
You can specify the path and file name of an application executable file. You can perform this operation in two ways:
Manually, by typing or pasting the path and file name into an application right definition form. Specifying files manually is recommended only if you
need to include a small number of files in the definition—typically just one or two. See Defining an application right manually for more information.
By navigating to the executable file or a running process that was launched by the executable file. After locating the executable file, you can
import the path and file name into the application right definition form. See Using an installed application or running process to create application
rights for more information.
You can specify search criteria for application executable files, and then include all application executable files that match those criteria in the
application right. You can perform this operation in two ways:
Manually, by typing or pasting values into search criteria fields. See Defining an application right manually for more information.
By importing values into search criteria fields from an executable file or from a running process that was launched by the executable file. See
Using an installed application or running process to create application rights for more information.
See Examples of application right definitions for examples of defining application rights in all of these ways.
Defining an Application Right Manually
This section describes how to create an application right by manually typing or pasting information into several application right definition forms.
Note: Alternatively, you can import information into application right definition forms from an executable file or from a running process that was
launched by the executable file. See Using an installed application or running process to create application rights for more information.
To define an application right manually:

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define an application right.
4. Select Applications, right-click, then click New Windows Application.
5. On the General tab, type a name and a description for the application right, and specify a priority for the application right.
For this Do this
Type the name you want to use for this application right. For example, if the right allows a user to run SQL Server Configuration Manager using
Name the privileges associated with a security group, you might include the service account in the name. For example, you might use a name like
SQL Config Manager.
Type a description for this application right. The description is optional. You can use it to provide a more detailed explanation of the privileges
Description
associated with running the application.
Set the priority for this application right. If more than one application right is added to the same role definition, the priority value determines
the application right to use when users assigned to that role open that application. The lower the value, the higher the priority. For example, a
right with the priority of 1 takes precedence over a priority value of 2. If the application rights have the same priority value, the application right
listed first under the role definition is used.
1. Click the Match Criteria tab and use it to create or edit application definitions. Each application definition specifies one application or a group of
applications. The set of application definitions displayed in the Match Criteria tab defines the set of applications that can be run by this application
right.
In the Match Criteria tab, click A d d to create a new application definition.
The Definition Settings dialog appears.
2. In the upper portion of the Definition Settings dialog, provide this information about the application definition.
For this Do this
Type a description for this application definition. For example, if the definition specifies one executable file (such as SQL Server Management
For this Do this
Studio for Windows 2005), you might type Windows 2005 SQL Server Management Studio here. Or, if the definition specifies more
Description
general criteria so that multiple executable files (such as SQL Server Management Studio for all versions of Window) can run, you might type
a more general description such as SQL Server Management Studio.
Select the type of executable file for this definition. If you are constructing the definition so that it specifies multiple executable files, all files
File Type
must all be of the type that you specify here. Supported file types are: .bat .cmd .com .cpl .exe .msc .msi .msp .ps1 .vbs .wsf
1. To specify executable files in this definition by typing or pasting the file name and location, select the P a t h option. Go to Step 9 and continue from
there.
Specifying files in this way is recommended only if you need to include a small number of files in the definition—typically just one or two.
To specify a larger number of executable files in this definition, it is recommended that you select file parameters that are common to the set of files.
Files that match the parameters are then included in the definition. To do this, go to Step 10 and continue from there.
2. Perform this step to specify a small number of executable files in this definition. In this step, you type or paste information about the executable file
name, location(s), and arguments. When you are done with this step, go to Step 11 and continue from there.
For this Do this
Type the name of the application executable file. If this field is defined, you must also select a path option (standard system path or a specified
Name
path). For example, to specify the SQL Server Management Studio executable, type Ssms.exe.
Standard
Select Standard system path to use the directories where the user would normally find the application specified. For example, to use the
system
application executable in its default directory, select Standard system path.
path
Select Specify path if you want to define the location of the application specified. If you select this option, you can specify one or more
paths, separated by a semicolon (;). Supported path variables are %systemroot%, %system32%, %syswow64%, %program files%,
Specify
%winagentinstall%, and %program files(x86)% (note that a space between “program” and “files” is required). For example, to specify the
path
location of the SQL Server Management Studio executable file in Windows 2008, type C:\Program Files (x86)\Microsoft SQL
Server\100\Tools\Binn\VSShell\Common7\IDE.
If you selected a file type of .msc in Step 7, the Arguments option is required. The Arguments option is optional for all other file types. Select
the Arguments option and leave the argument field blank to specify that the application cannot accept any arguments. To specify that the
application can run using any argument, leave the Arguments option deselected. For example, if you specified the SQL Server Management
Studio executable and left the Arguments option deselected, users can run SQL Server Management Studio with any option on a local
computer with elevated privileges. If you want to restrict the arguments allowed, in the argument field type the list of arguments to allow. Valid
Arguments arguments be must enclosed by quotation marks and separated by a space. For example, to allow users to run the specified application using
argument1, argument2, or argument3, you would specify the list of arguments like this: “argument1” “argument2” “argument3” By default,
arguments that you specify do not need to be a case-sensitive match, but do need to be an exact match (that is, a match is returned if the
actual argument is a partial match of the argument string that you specify). If arguments must be a case-sensitive match for a particular
application, select the Keep arguments case sensitive option. If arguments can be a partial match for a particular application, deselect
the Match whole string only option.
1. Perform this step to specify a larger number of executable files in this definition. In this step, you use the File details area to specify characteristics
that are used to search for applications to include in this definition. All of the characteristics that you specify must be met in order for an application to
be a match. For example, if you specify a product name of Microsoft SQL Server and a company name of Microsoft Corporation, all executable files that
meet both of those criteria are included in this definition.
Note: This step describes how to manually fill in each field in the File details area. You can select any combination of these fields to specify
the file characteristics for which to search. Alternatively, you can populate fields in the Definition Settings dialog by importing values from an
installed executable file or from a running process. Filling in fields by importing is faster and more accurate than filling in fields manually one
at a time. For details about filling in fields by importing, see Using an installed application or running process to create application rights.
For this Do this
Select an operator (is or contains) from the drop-down list and in the provided field type the product name for which to search. If you select is,
Product
matches are returned for product names that exactly match the string that you type here. If you select contains, matches are returned for
Name
product names that contain the string that you type here anywhere in the product name.
Company Select an operator (is or contains) from the drop-down list and in the provided field type a company name for which to search.
File
Select an operator (is or contains) from the drop-down list and in the provided field type a file description for which to search.
Description
Select an operator (is, contains, starts with, or ends with) from the drop-down list and in the provided field type a serial number for which to
Volume
search. The supported format is 8-character hex string (FFFFFFFF). This criterion is matched only if the executable file was from CD/DVD
Serial #
media.
Select an operator (is, contains, starts with, or ends with) from the drop-down list and in the provided field type publisher information for
Publisher which to search. For example, publisher information could look similar to: CN=Acme Corporation, OU=Digital ID Class 3 - Microsoft Software
Validation v2, O=Acme Corporation, L=Sunnyvale
Product Select an operator (equal, earlier or equal, or later or equal) from the drop-down list and in the provided field type product version information
Version for which to search. For example, the product version could look similar to: 3.1
Select an operator (equal, earlier or equal, or later or equal) from the drop-down list and in the provided field type file version information for
File Version
which to search. For example, the file version could look similar to: 3.1.2
Select this option to match applications using the encrypted file hash for the application. The file hash for the application is generated using
the SHA-1 encryption algorithm, which is FIPScompliant. You can click Import Process or Import File and select an application to populate
the File Hash field for which to search. Only applications with a hash string that is exactly the same as the string generated by the MD5
File Hash
algorithm are matched. You can only use file hash matching to identify an application for files that are less than 500MB to limit the CPU and
memory used to calculate the file hash. If the file with matching hash information is larger than 500MB, an empty value is returned for the file
hash field.
In the provided field, type owner information for which to search. Matches are returned for owner information that exactly matches the string
Owner that you type here. Owner information can be: AD user/group/builtin (SID) local user (user name) local group (group name) For example, the
owner could look similar to: NT AUTHORITY\SYSTEM DEMO\Ed.Admin (this is an AD user account) Amy Adams (this is a local user account)
1. Optionally select the Application requires administrative user option to specify that applications in this definition run only if
RequestedExecutionLevel is set to requireAdministrator in the application manifest. If you select this option, the applications in this definition run only
for administrators and require that the applications be launched with the full access token of an administrator. This option applies only to .exe files.
2. Click O K to save the definition. You are returned to the Match Criteria tab, and the new or modified definition appears in the Match Criteria list of
definitions.
3. Click the Run As tab and select the account that has the privileges you want to enable for this application right.
You can browse for and select a specific user account or have the application run using the logged in user’s account credentials but with the elevated
privileges of a specified group. Click Add AD Groups or Add Built-in Groups to search for and select a previously-defined or Built-in group with the
privileges you want to add to the logged in user’s account.
In most cases, you select a specific user account only if the application should run as a service account. However, some applications require a specific
privileged user account to be used. For example, Microsoft System Center Operations Manager (SCOM) and Exchange require a user account. If you are
defining an application right for an application that requires a privileged user account rather than membership in a privileged group, you should create a
service account and use that account for the run-as account.
Select Re-authenticate current user if you want to prevent the application right and its privileges from being used by anyone not authorized to do
so. Selecting this option also allows you to enable multi-factor authentication for the right. For more information see Enabling multi-factor
authentication for Windows rights.
If you select this option, users are prompted to re-enter their password to verify their identity before they are allowed to select a role for running a local
application. Forcing users to reauthenticate ensures the privileges associated with the application right are only granted to users who have been
assigned those privileges.
If you select this option for users who are authenticated using a smart card, users must enter a personal identification number (PIN) or a password to
resume working with the application.
4. Click O K to save the application right.
Using Application Utility Rights
This section describes how you can manage user access to Windows programs and features using application utility rights.
There are many common administrative tasks such as managing software installations, changing network settings, and adding or removing Windows
features that require access to the explorer.exe application on Windows systems. Because granting users privileged access to explorer.exe can allow the
user to perform many other tasks that you may want to remain restricted, you can use the Delinea application utilities, Application Manager, Network
Manager and Windows Feature Manager, to grant access to these tasks using the corresponding predefined rights.
When you create a new zone, the Delinea utility rights are automatically added to the list of Windows Right Definitions. However, in zones that existed before
the addition of these utility rights, you may need to add them by following the procedure below.
To add the Delinea Utilities to the list of Windows Right Definitions
1. Right click Windows Right Definitions and select Add predefined rights.
Windows Right Definitions can be found in the following location:
The application rights can be found in the following location:
Access Manager > Zones > Zone Name > Authorization > Windows Right Definitions
2. Select the rights you would like to add and click O K.
The rights will now appear under Applications.
It is important to note that if you do not install the Agent for Windows in the default location during the installation or upgrade process, users who are assigned
these rights may not be able to access the corresponding applications. If you have installed the agent in a location other than the default location, you can
specify a variable in the application right settings to allow them to be used by assigned users by doing the following:
To specify the application right path
1. Right click on the application right and select Properties.
The application rights can be found in the following location:
Access Manager > Zones > Zone Name > Authorization > Windows Right Definitions > Applications.
2. Click the Match Criteria tab, and then click Edit.
3. Check the P a t h box in the Commands components section, and select Specific path.
4. In the Specific path field, enter the following variable: %winagentinstall%
Do this for each of the Utility application rights.
Application Manager
Application Manager is a utility that allows a user to manage installed software. Application Manager is similar to the Windows utility Programs and Features.
It can allow users who are assigned a role with the Utility - Application Manager right to Refresh, Uninstall, Change, or Repair installed software.
Windows Feature Manager
When you assign workstation users a role with the predefined right Utility - Windows Feature Manager, they will be able to access the normal Windows
Feature Manager, where they can choose what Windows features to add or remove.
When you assign server users a role with this right, the Windows Feature Manager will launch. This utility is similar to the normal Windows utility, with a few
notable differences.
Opening the utility will launch a wizard. When you select whether to add or remove roles and features on the first screen of the wizard, you can only perform
one action at a time. For example, if you choose Add roles and features, you will not be able remove any installed features until you go back to the initial
screen and choose Remove roles and features.
Additionally, when you attempt to install features that require the installation of dependent components, you will be prompted to add those features. All
features with one or more components installed will appear with a check mark next to the name.
Network Manager
When you assign users a role with the predefined right Utility - Network Manager, they will be able to access the Delinea version of Network Manager that is
similar to the Windows version.
Users assigned a role with this right can view a list of network adapters for Ethernet and wireless connections and configure their IP and DNS settings.
Using an Installed Application or Running Process to Create Application Rights
This section describes how to create an application right by importing values from an installed executable file or from a running process. After values are
imported into the application right definition form, you can select which fields to use as search criteria for matching applications. Applications that match the
search criteria are included in the application definition.
For more information about filling in fields by importing, see Examples of application right definitions.
To define an application right based on an installed application:
1. Follow the procedure for creating a new application right manually to the point where the Definition Settings dialog opens (see Defining an application
right manually).
2. In the Definition Settings dialog, click Import File.
3. Navigate to an application executable file, highlight the file, and click Open.
Fields in the Definition Settings dialog fill in with all of the information that is available for the file that you selected. For example, if you navigated to
C:\Program Files\Centrify\Access Manage and selected the Mmc_config.exe file, the Definition Settings dialog would look similar to this:
Notice that:
The File Type field is set to .exe.
The P a t h option is selected, and the file name and path name are filled in.
Most fields in the File details section are filled in, but none are selected.
The settings shown in this example specify that only the Mmc_config.exe  file located in C:\Program
Files\Centrify\Access Manage is included in the application right. The information in the File details section is not used because no options in
that section have been selected.
4. Choose whether to expand the definition to include other executable files, or to save the definition as it is currently defined (so that it specifies only the
Mmc_config.exe file shown here).
To expand the definition to include other executable files, go to Step 5 and continue from there.
To save the definition as it is currently defined:
In the Description field, type a description for this application definition. This is the string that displays in the list of application definitions on the
Match Criteria tab.
Click O K.
Continue to define the application right as described in Defining an application right manually.
5. To expand the definition to include other executable files, use the File details area to specify characteristics that are used to search for executable
files. All of the characteristics that you specify must be met in order for an executable file to be a match. See Defining an application right manually for
details about operators and syntax for each option in the File details area.
Deselect the P a t h option.
This step is necessary because all of the search options that you select use the AND operator when the search executes. If you leave the P a t h
option selected, the search is constrained to this location and the definition will include only the file that is specified in the Name field.
In the File details area, select options to define search criteria for executable files.
Selecting criteria that are more general will usually result in a greater number of executable files being included in the definition. In the example
shown in Step 3, you would select only the Company option if you wanted to allow this definition to run all .exe files having a company name tag of
Acme Corporation. Select additional options to limit the scope of the search so that fewer executable files are included in the definition.
In the Description field, type a description for this application definition. This is the string that displays in the list of application definitions on the
Match Criteria tab.
Click O K.
Continue to define the application right as described in Defining an application right manually. When you are done, the application right is available
to use.
To define an application right based on a running process:
1. Follow the procedure for creating a new application right manually to the point where the Definition Settings dialog opens (see Defining an application
right manually).
2. In the Definition Settings dialog, click Import Process.
A list of running processes displays. By default, the list does not include these processes:
Processes having an owner of SYSTEM, Local Service, or Network Service
conhost.exe
dllhost.exe
dwm.exe
explorer.exe
svchost.exe
taskhost.exe
To display these processes, select the Show all processes option.
Note: System Idle Process and processes having unsupported file extensions (for example, .scr) are never shown.
3. Highlight a process and click O K.
Fields in the Definition Settings dialog fill in with information from the executable file that launched the process that you selected.
4. Select executable files to include in this definition as described in Step 4 on page 149 through Step 5 on page 150. When you are done, the application
right is available to use.
Examples of Application Right Definitions
This section contains these examples of how to use the Definition Settings dialog to specify an application right definition:
Example 1: Manually specify one application path and file name—Describes how to define an application right to run the Access Manager console by
manually entering the path name and application name.
Example 2: Manually specify one application residing in two locations—Describes how to define an application right to run SQL Server Management
Studio on Windows 2008 and Windows 2012 systems by manually entering the application name and the path names to the application on both systems.
Example 3: Specify one application by importing its location—Describes how to define an application right to run the Access Manager console by  navigating to the centrifydc.msc file and importing its information.
Example 4: Specify several applications by importing and specifying search criteria—Describes how to define an application right to run SQL Server
Management Studio on several versions of the Windows operating system by navigating to the Ssms.exe file on Windows 2008, importing its
information, and constructing application search criteria based on that information.
Example 1: Manually specify one application path and file name
In this example, it is assumed that you want to create an application right to run the Access Manager console application, and you know the path and file name
of the application executable file.
1. Open the Definition Settings dialog and fill it in as follows:
Description—Type a name of your choice (for example, Default Access Manager Console Application).
P a t h—Select this check box.
Name—Type the application name; in this case  centrifydc.msc.
Arguments—Select this check box and specify which arguments can be executed through this application right.
Specific path—Select this option and type the full path name to the  centrifydc.msc executable file: 
C:\Program Files\Centrify\Access Manager
2. Click O K to save the application right definition setting.
Example 2: Manually specify one application residing in two locations
In this example, it is assumed that you want to create an application right to run SQL Server Management Studio on Windows 2008 and Windows 2012
systems. The SQL Server Management Studio executable file resides in different locations in those operating systems, and you know the paths those
locations.
1. Open the Definition Settings dialog and fill it in as follows:
Description—Type a name of your choice (for example, SQL Server Management Studio 2008/2012).
P a t h—Select this check box.
Name—Type the application name; in this case Ssms.exe.
Arguments—Optionally select this check box and specify which arguments can be executed through this application right.
Specific path—Select this option and type the full path names to the Ssms.exe executable file in Windows 2008 and Windows 2012. Separate the
path names with a semicolon(;)
C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE;C:\Program Files\Microsoft SQL

Server\110\Tools\Binn\ManagementStudio
Example 3: Specify one application by importing its location
This example is similar to Example 1; it is assumed that you want to create an application right to run the Access Manager console application. Unlike in
Example 1, you are not sure of the path name to the application executable file and you will navigate to it rather than type it in the form.
1. Open the Definition Settings dialog.

2. Click Import File.
3. Navigate to the  centrifydc.msc executable file, highlight it, and click Open.
4. Verify that the Definition Settings dialog fills in with application information.
5. In the Description field, type a name of your choice (for example, Default Access Manager Console Application).
Example 4: Specify several applications by importing and specifying search criteria
This example is similar to Example 2; it is assumed that you want to create an application right to run SQL Server Management Studio on more than one
version of the Windows operating system, starting with Windows 2008. Unlike in Example 2, you do not want to constrain the latest version of Windows to
Windows 2012. Instead, you want to account for future versions of Windows and provide the capability to run SQL Server Management Studio on future
Windows releases.
1. Open the Definition Settings dialog on a Windows 2008 system.
2. Click Import File.
3. Navigate to the Ssms.exe executable file, highlight it, and click Open.
The Definition Settings dialog fills in with information from the Windows 2008 version of Ssms.exe.
4. Deselect the P a t h option so that the definition is not constrained just to that location.
5. Select the File Description option and keep the default operator and string.
6. Select the Product Version option and change the operator from equal to later or equal.
The definition is now configured to include all .exe files having a file description tag of SSMS - SQL Server Management Studio and a product
version later than or equal to the version that is installed on this Windows 2008 system.
7. In the Description field, either keep the string that was imported with the Ssms.exe file or type a description of your choice.
Defining Network Access Rights
Network access rights allow users to access services on remote computers using another user account on the remote computer. Users who are assigned to a
role with network access rights are only granted the elevated privileges when accessing the remote computer.
To define a network access right:

2. Expand Zones and the parent zone or child zones until you see the zone where you want to define an application right.
4. Select Network Access, right-click, then click New Network Access.
5. On the General tab, type a name and a description for the network access right.
For this Do this
Type the name you want to use for this network access right. For example, if the right allows a user to connect remotely to a Microsoft SQL
Name Server instance using the privileges associated with a database system administrator account, you might include the SQL login name. For
example, you might use a name like sysadmin.
Type a description for this network access right. The description is optional. You can use it to provide a more detailed explanation of the
Description
privileges associated with this right.
Set the priority for this application right. If more than one network access right is included in the roles selected, the priority value determines
which network access right to use. The lower the value, the higher the priority. For example, a right with the priority of 1 takes precedence over
Priority a priority value of 2. If users have multiple roles selected, the priority value of the network access right determines which network access right
takes precedence over the access rights in other roles. For more information about selecting multiple roles for connecting to remote servers,
see Scenario: Using multiple roles for network resources.
1. Click the Access tab to select the account that has the privileges you want to enable for accessing the remote computer.
You can browse for and select a specific user account, create a new account, or access the remote computer using the logged-in user’s account
credentials but with the elevated privileges of a specified group account. Click Add AD Groups or Add Built-in Groups to search for and select a
previously-defined or Built-in group with the privileges you want to add to the logged in user’s account.
In most cases, you select a specific user account only if accessing the remote computer using a service account.
Select Re-authenticate current user if you want to prevent the network access right and its privileges from being used by anyone not authorized to
do so. Selecting this option also allows you to enable multi-factor authentication for the right. For more information see Enabling multi-factor
If you select this option, users are prompted to re-enter their password to verify their identity before they are allowed to select a role for accessing
applications on a remote computer. Forcing users to reauthenticate ensures the privileges associated with the network access right are only granted to
users who have been assigned those privileges.
If you select this option for users who are authenticated using a smart card, users must enter a personal identification number (PIN) or a password to
resume working with the remote server.
2. Click O K to save the network access right.
Using Network Access Rights When There are Two-way Selective Cross-forest Trusts
If you have domains in different forests that have a selective two-way trust relationship, any computer or user accounts that are used to log on to the remote
forest must be granted the “Allowed to authenticate” right on the domain controllers in both forests to get role information. After you grant the computer
used to access the remote server the “Allowed to authenticate” right for the domains in both forests, you can select roles that grant network access rights
from either forest.
If an account is not allowed to authenticate on the remote domain controller, you cannot view or select roles that would otherwise allow you to perform tasks
on the remote server.
Defining Custom Roles with Specific Rights
Rights can be combined or used independently of each other to create role definitions. Role definitions describe job functions that require a specific set of
rights, including the specific days and times the role should be available for performing the operations allowed. If you have created desktop, application, or
network access rights, you must create at least one role definition to use these rights.
To create a new role definition for a job function, you need to do the following:
Create a new role and specify when the role is available.

Specify how users in the role are allowed to log on.
Add specialized Windows access rights to the role, as applicable.
Specify whether the role requires multi-factor authentication before it can be selected.
In most cases, creating a separate role definition for each access right gives you the most granular control over what users assigned to a role can do. For
example, if you create separate role definitions for desktop, application, and network access rights, you can choose which apply to specific users and groups
through role assignments.
Creating a Role Definition with Desktop Rights
Before you can make the desktop rights you have defined available to users or groups, you must create one or more role definitions that include those rights.
Desktop rights are especially useful to include in roles for users who frequently perform tasks that require the privileges associated with the Administrator
group.
To create a new role definition with desktop rights:
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a new role that includes a desktop right.
3. Expand the Authorization node.
5. Type a role name and optional description for the role.
The description can include details about time restrictions for the role and whether the role is audited or not.
6. Select Allow local accounts to be assigned to this role if you want to be able to assign local users or groups to the role you are creating.
If you do not select this option, only Active Directory domain users can be assigned to the role.
7. Click Available Times and use the grid to specify when to allow or deny access for this role definition if you want to restrict when this role is available.
8. Click the System Rights tab and select Console login is allowed to allow users in the role to log on locally.
To use the desktop right, the user must be able to log on locally on the computer. If you want to allow users to log on using a remote desktop connection,
you can also select Remote login is allowed.
Note: Remote computers must be configured to allow remote desktop connections for the “Remote login is allowed” right to be valid. You
can configure a computer to allow remote desktop connections by right-clicking Computer and selecting Properties or from the System
Control Panel, then clicking Remote settings.
Users must be assigned to at least one role with either console login or remote login rights to access any computers where the Agent for Windows is
installed. You can grant access using the Windows Login role definition or the system rights in any custom role definition.
The Windows right PowerShell remote access is allowed allows you to log on remotely to PowerShell.
If you want to allow users to log on even when the Windows agent isn’t running or when audit and monitoring service is required but not available, you
can select the rescue right. Because this right allows users to log on without having their activity audited, you should only assign roles with this right to
trusted administrators or under controlled conditions. For example, assume you have a computer with sensitive information that normally requires all
user activity to be audited. If that computer has application or operating system issues that require you to disable auditing temporarily, you can use a
role with the rescue right to log on to that computer to diagnosis and fix the issue.
9. In the Authentication tab, you can add multi-factor authentication. If you want to require multi-factor authentication for users to access the role,
select Require multi-factor authentication for login. You can also require multi-factor authentication for access to individual rights when you
define the rights to add to roles. For more information see Enabling multi-factor authentication for Windows rights.
10. Click the Audit tab and select an option.
If you select Audit not requested/required, users can log on to audited computers without having their session activity recorded. An audit trail
event is recorded in the Windows event log when users open a desktop with this role, but the detailed record of what took place during the session is not
captured.
If you select Audit if possible, session activity is recorded when users open a desktop with elevated privileges on audited computers and not recorded
when they log on to computers where audit and monitoring service is not enabled or audited computers when auditing is not currently running.
If you select Audit required, users can only open a desktop with elevated privileges when auditing is running. If audit and monitoring service is not
available or not currently running, the role is not available and users cannot use the elevated privileges.
12. Select the role definition, right-click, then click Add Right to add a desktop right to the role definition.
13. Select the desktop right from the list of rights from the current zone and from any parent zones, then click O K to add the right to the role definition.
Creating a Role Definition with Application Rights
Before you can make the application rights you have defined available to users or groups, you must create one or more role definitions that include those
rights. Application rights are especially useful to include in roles for users who infrequently require access to specific applications with the privileges
associated with the Administrator account or a service account on a local computer.
To create a new role definition with application rights:
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a new role that includes an application right.
7. Click the System Rights tab and select Console login is allowed to allow users in the role to log on locally.
To use the Run as selected role utility and an application right, the user must be able to log on locally on the computer where the application runs. If you
want to allow users to log on using a remote desktop connection, you can also select Remote login is allowed.
If you want to require multi-factor authentication for users to access the role, select Require multi-factor authentication. You can also require
multi-factor authentication for access to individual rights when you define the rights to add to roles. For more information see Enabling multi-factor
8. Click the Audit tab and select an audit and monitoring service option.
If you select Audit not requested/required, users can log on to audited computers without having their session activity recorded. An audit
trail event is recorded in the Windows event log when users select this role to run the application, but the detailed record of what took place during
the session is not captured.
If you select Audit if possible, session activity is recorded when users select this role to run the application and not recorded when they use the
application on computers where audit and monitoring service is not enabled or audited computers when audit and monitoring service is not
currently running.
If you select Audit required, users can only select this role to run the application when audit and monitoring service is running. If audit and
monitoring service is not available or not currently running, the role is not available and users cannot use their elevated privileges.
10. Select the role definition, right-click, then click Add Right to add the application right to the role definition.
11. Select the application right from the list of rights from the current zone and from any parent zones, then click O K to add the right to the role definition.
Creating a Role Definition for Network Access Rights
Before you can make the network access rights you have defined available to users or groups, you must create one or more role definitions that include those
rights. Network access rights are especially useful to include in roles for users who require remote access to network services with the privileges associated
with the domain Administrator account or a service account on the remote computer.
2. Expand Zones and the parent zone or child zones until you see the zone where you want to define a new role that includes a network access right.
7. Click the System Rights tab and select Remote login is allowed to allow users in the role to connect to services on the remote computer.
The user must be able to connect to the computer remotely to perform administrative tasks on that computer. If you want to allow users to log on
locally, you can also select Console login is allowed.
If you want to require multi-factor authentication for users to access the role, select Require multi-factor authentication. You can also require
multi-factor authentication for access to individual rights when you define the rights to add to roles. For more information see Enabling multi-factor
8. Click the Audit tab and select an auditing option.
If you select Audit not requested/required, users can connect to remote audited computers without having their session activity recorded. An
audit trail event is recorded in the Windows event log when users select this role to connect to remote servers, but the detailed record of what took
place during the session is not captured.
If you select Audit if possible, session activity recorded when users log on to audited computers and not recorded when they log on to computers
where audit and monitoring service is not enabled or audited computers when audit and monitoring service is not currently running.
If you select Audit required, users can only log on to audited computers when audit and monitoring service is running. If audit and monitoring service
is not available or not currently running, the role is not available and users cannot use their elevated privileges.
10. Select the role definition, right-click, then click Add Right to add a network access right to the role definition.
11. Select the network access right from the list of rights from the current zone and from any parent zones, then click O K to add the right to the role
definition.
Combining Rights in the Same Role Definition
The previous sections illustrate how to create custom role definitions specifically for desktop, application, or network access rights. You can also combine
multiple rights in the same role definition. For example, you can create a role definition that allows a user to open a specific application on the local computer
using a service account with elevated privileges. The same role definition can also include a network access right that enables the user to modify information
on a remote server.
Assigning Users and Groups to a Role
You can assign a role to an Active Directory user or to an Active Directory group. You can assign a role that is defined in the current zone or in a parent zone.
You can also specify optional start and end times for the role assignment.
To assign users and groups to a role in a zone:
2. Expand Zones and the parent zone or child zones until you see the zone where you want to make role assignments.
5. Select the role definition from the list of roles, then click O K.
By default, the role is set to start immediately and never expire. You can set a Start time, End time, or both start and end times for the role
assignment. For example, if the role applies to a contractor who will be hired for a specific amount of time and you want to automatically disable the role
after they finish the job and leave the organization, you can specify the start and end times when you assign the role.
6. Select whether the role assignment applies to all Active Directory accounts, all local accounts, or specific Active Directory and local accounts.
To assign the role to specific accounts, click Add AD Account to search for and select the Active Directory groups or users to assign to the role, then
click O K.
Rights and Role Assignments for Local Users
The rights you assign to users and group in a particular role apply to Active Directory users and groups. They can also apply to locally-defined users and
groups if you configure the role definition to allow local accounts to be assigned to the role. All Windows users, including local users, must be assigned at least
one role that allows them log on locally, remotely, or both.
Restricting Roles that Include Network Access Rights
Because role definitions can include a combination of rights and you can assign roles to local users, Active Directory users, or both, it is possible for you to
assign roles that include network access rights to local accounts. Access Manager does not prevent you from configuring role definitions or role assignments
in this way. However, users who log on with a local account will not be allowed to select the Advanced View or those network access rights for the remote
computer. Therefore, you should avoid configuring role definitions that include network access rights and allow local accounts. Instead, you should keep role
definitions that include network access rights separate from role definitions that allow local accounts to be assigned.
Making Rights and Roles Available in Other Zones
The access rights and role definitions that you create are specific to the zone where you configure them, and to any child zones of that zone. Once
configured, though, you can copy and paste or drag and drop the definitions from one zone to another. After you import the information into a new zone, you
can modify any of the details you have previously defined. For example, you can choose to export all the rights you have defined in one zone but create a
completely new set of role definitions for those rights in the import zone.
Rights, roles, and role assignments are all inherited from parent to child zones, so generally there is no need to import or export roles within a zone hierarchy,
but you may want to do so across zones. For example, if you have set up separate parent zones for different lines of business or different functional groups in
your organization, you might want to import rights and roles from one business unit or functional group to another.
Exporting a Zone’s Rights and Role Definitions
You can export right and role definitions to an xml file that you can then use to import these definitions into another zone.
To export rights and role definitions:

2. Expand Zones and the parent zone or child zones until you see the zone that has the rights and roles you want to export.
3. Expand Select the Authorization node, right-click, then click Export Roles and Rights.
4. Select the information you want to export, then click Next.
5. Click Browse to specify a location and file name for the export file, then click Next.
6. Review the information to be exported, then click Finish.
Importing Rights and Role Definitions into a New Zone
You can import rights and role definitions that you have previously saved from a different zone. You can also copy a paste or drag and drop rights and roles to a
different zone.
To import rights, role definitions, and role assignments:
Before you begin, be certain you have saved rights and role definitions from a different zone and know the location of the xml file in which they are saved.

2. Expand Zones and the parent zone or child zones until you see the zone into which you want to import rights and roles.
3. Select the Authorization node, right-click, then click Import Roles and Rights.
4. Click Browse to navigate to the file that contains the authorization information you want to import, then click Next.
5. Select the information you want to import, then click Next.
6. Review the information to be imported, then click Finish.
Copying Rights and Role Definitions into a New Zone
Exporting and importing information from one zone to another is the best solution if you want to include most or all information about rights and roles in a new
zone. If you want to limit the information copied from one zone to another, you can copy and paste or drag and drop the information instead. With copy and
paste, you can select specific right definitions, role definitions, or role assignments that you want to include in a new zone.
To copy role assignments from one zone to another, however, you should verify that the role definition associated with the role assignment exists in the new
zone or is included in the information you are copying to the new zone.
To copy rights, role definitions, or role assignments:
1. Open the Access Manager.

2. Expand Zones and the parent zone or child zones until you see the zone that has the rights, role definitions, or role assignments you want to copy.
4. Expand Window Right Definitions, Role Definitions, or Role Assignments until you see the specific right, role, or role assignment you want to
copy.
5. Select the specific right, role definition, or role assignment to copy, right-click, then click C o p y.
6. Open a different zone and expand Authorization > Windows Right Definitions, Role Definitions, or Role Assignments, right-click, then click
Paste.
Alternatively, you can select a specific right, role definition, or role assignment and drag it to the appropriate node in a new zone.
Viewing Rights and Roles
You can view the status and effective rights for any user in a zone, whether they have been assigned a role or not. You can view detailed information about the
rights and role assignments for users by selecting Show Effective Windows User Rights in the Access Manager console.
Displaying Rights for an Individual User in the Console
To view role assignments and Windows access rights for a user in the Access Manager console:

2. Expand Zones and the parent zone or child zones until you see the zone that has the user of interest.
3. Right-click, then click Show Effective Windows User Rights.
4. Select a user to see information for the user in the selected zone or click Browse to select a specific computer in the zone if you only want to view user
rights for a particular computer in the selected zone.
5. Click a tab to see the user’s role assignments, desktop rights, application rights, or network access rights.
Role Assignments lists the user’s role assignments, including where the assignment was made. For example, the Object Assigned column
indicates whether the assignment for a user is explicit (user@domain), from a group (group@domain), or inherited from another setting (All AD
Accounts). The Start Time and End Time are only displayed for roles that have time constraints.
Windows Desktops lists the user’s desktop rights granted by the roles to which the user is assigned. The tab identifies the account that can be
used to open a new desktop or run an application, the zone where the desktop right is defined, and the role definition that includes the right.
Windows Applications lists the user’s application rights granted by the roles to which the user is assigned. The tab identifies the specific
application and the account that can be used to run the application, the zone where the application right is defined, and the role definition that
includes the right.
Network Access lists the user’s network access rights granted by the roles to which the user is assigned. The tab identifies the account that can
be used to connect to services on a remote computer, the zone where the network access right is defined, and the role definition that includes the
right.
6. Click Close when you are finished reviewing user rights in a zone or on particular computers.
Scenario: Using a Network Access Role to Edit Group Policies
The steps in this section illustrate a specific scenario of how to configure and use a desktop right and a network access right that allows the user Josh.Adams
to log on with his normal Active Directory credentials, open an application that enables him to edit group policies, then connect to a domain controller with
administrative privileges so that he can edit a Group Policy Object.
1. Install the Agent for Windows on the domain controller.
2. Install the Agent for Windows on a Windows computer that hosts the Group Policy Management console that the Josh.Adams uses to access the domain
controller remotely.
3. Assign Josh.Adams the predefined Windows Login role and the custom role definition gpedit that includes a desktop right and a network access right.
4. Josh Adams logs on to his Windows computer using his Active Directory user name and password.
To use a role with network access rights, you cannot log on using a local user account. You must use a domain user account authenticated using Active
Directory.
5. On his local computer, Josh right-clicks the Delinea icon in the system tray section of the task bar, then selects New Desktop.
6. In his list of available roles, Josh selects his gpedit role, then clicks OK.
7. Josh opens the Group Policy Management console on his local computer, connects to the domain controller in the console, then selects the default
domain policy Group Policy Object.
8. Josh right-clicks the default domain policy, then selects Edit to modify the group policy.
9. When he is done working with the group policies, he switches back to his default desktop.
Scenario: Using Multiple Roles for Network Resources
For the local computer, users can select only one role at a time for their desktop or running an application. However, users can select more than one role to
access network resources. By selecting multiple roles on the client, users can run applications that connect to multiple remote servers to perform
administrative tasks.
In this scenario, Maya.Santiago uses a privileged account to open SQL Server Management Studio on her local computer. From this application, she wants to
add accounts that require domain administrator privileges on a remote domain controller and modify database settings on a remote SQL Server instance. To
do her work, she needs elevated privileges to run SQL Server Management Studio on her local computer and network access rights to contact the domain
controller and the database server.
As the administrator, you have prepared the environment:
You have put computers in appropriate zones and configured appropriate rights.
You have configured a role definition, SideBet-DC-Admin, that grants network access to the domain controller using elevated privileges.
You have also configured a role definition, SQL-DB-Default, that grants network access to SQL Server instances using elevated privileges.
You have assigned Maya.Santiago to the roles.
To use an application that connects to multiple remote servers:
1. Install the Agent for Windows on the domain controller, the computer that hosts the SQL Server instance, and the computer Maya.Santiago uses to
manage the SQL Server instance.
2. Assign Maya.Santiago the custom roles definition SideBet-DC-Admin that includes a desktop right and a network access right.
3. Maya.Santiago logs on to her Windows computer using her Active Directory user name and password.
4. On her local computer, Maya right-clicks SQL Server Management Studio, selects Run with Privilege.
5. Maya clicks Advanced View to see the list of available roles and selects SideBetDCAdmin as the local role that enables her to run local applications
with administrator privileges.
6. Maya then clicks the Select one or more network roles option and selects the SideBetDC-Admin role for remote access to the domain controller
and the SQLDBDefault role for remote access to the database server, then clicks O K.
After she clicks OK, SQL Server Management Studio starts and she connects to the remote SQL Server instance using Windows authentication. The
change to a role with privileges is recorded in the local Windows Application event log.
7. Maya uses SQL Server Management Studio to add and modify information on the domain controller and the SQL Server database.
8. When she is done working, she closes the application and returns to her default desktop and her login account privileges.
Defining Rights for Windows Applications that Encrypt Passwords
Microsoft provides a data protection application-programming interface (DPAPI) to enable applications to secure sensitive information, such as passwords,
using encryption. The Data Protection API is the most common way to secure personal information on Windows computers because the information that is
encrypted for one user cannot be decrypted by another user. Many applications and system services, including Microsoft Encrypting File System (EFS),
Microsoft Internet Explorer, and Google Chrome for example, use the Data Protection API to encrypt passwords.
To use a desktop or application right with an application that uses the Data Protection API, you should select the Self with added group privileges option
for the Run-as account. If you select this option when defining a right, you can install the Agent for Windows on the computer where the application using the
Data Protection API is installed to allow users to run the application with administrative privileges.
If you want to use a specific user account for an application that uses the Data Protection API, you must install the Agent for Windows on both the domain
controller and the computer where the application using DPAPI is installed. You must also make sure the domain controller is in a zone where users who are
going to use the application are granted network access rights. In this scenario, the domain controller must be able to confirm the identity of the specific user
account to allow protected information to be decrypted.
For example, assume you define an application right for running Access Manager using the Windows AM-Owner account and assign the user Steve to a role
that has this application right. When Steve logs on to the computer where Access Manager is installed and opens the application using the role he is assigned,
the Agent for Windows on the domain controller identifies him as the user AM-Owner and provides Jess with the master key for encryption and decryption,
enabling him to use Access Manager to add computers, deploy agents, and perform other tasks.
Enabling Access Across Multi-tiered Application Layers
The traditional client/server scenario involves using a Windows client computer to connect to a Windows server to perform some operation. However, it is
increasingly common that privileged access must cross multiple application layers. For example, you might have users who log on with their normal
credentials who perform administrative tasks on a remote Sharepoint server and those tasks further require access to a SQL Server instance on yet another
computer.
One way to ensure access across multiple applications tiers is to have all of the remote computers involved be in the same zone. At a minimum, the client
computer and the computer in the first tier must have the Agent for Windows installed. If the client computer and the computer in the first tier are in different
zones, which is the most common scenario, you should place computers in any additional tiers in the same zone as the computer in the first tier.
Requiring Users to Justify Privilege Elevation
You can assign some group policies that force your users to provide a reason when they choose to run an application with privilege. There are two group
policies that you can use:
You can use just one of these policies or both. With either of these policies, when a user goes to run an application with privilege, they're prompted with an
additional dialog box where they can enter a ticket number, a reason category, and any comments.
The above dialog box prompts users to enter the following information:
Ticket number: If you have enabled the privilege elevation validator policy and subsequent script, you can validate the ticket number that a user
enters against a ticketing system such as ServiceNow. If you haven't enabled the privilege elevation validator policy, users can enter any text string
here.
Reason: The user selects the reason category that best fits their situation. Their choices are:
Software Installation
Remote System Administration
Local System Administration
Windows Feature Management
System Networking Change
Maintenance (Shutdown, Reboot, Power Off)
PowerShell or Other CLI
Operation (Services, Zone Operations, etc.)
Other
Comment: The user enters any comments about their need to run with privilege. You can view these comments in the audit trail event.
For more details about these policies, see the Group Policy Guide and the group policies' explain text.
A computer role associates a group of computers in a zone with a set of role assignments to users or groups. For example, you might have a set of computers
dedicated to a specific function, such as hosting Oracle databases or payroll processing application. Users who are database administrators for those
computers require different privileges than users who update payroll records on those computers.
Using a computer role, you can associate the group of computers that host an Oracle database with a specific role assignment, for example, users who are
assigned the oracle dba role. The oracle-dba role definition might include desktop and network access rights because the users assigned to the oracle-dba
role require administrative privileges.
You could also create a second computer role that associates the group of computers that host the payroll processing application with a group of users who
are allowed to log on and update payroll records without granting any other administrative privileges. For example, if some of the computers that host an
Oracle database are used for payroll processing, you can define another computer role—payroll-west—that associates just those computers with the role
assignment payroll_mgmt. The payroll_mgmt role definition might have the console login right and an application right specifically for the payroll
application. When users are assigned the payroll_mgmt role, they can log on locally and run the payroll application with elevated privileges only on the group
of computers defined in the computer role payroll-west.
To use computer roles, you must do the following:
Decide on the attribute the computers in a particular group share. For example, you can use a computer role to identify computers in the web farm, that
host specific applications, or serve a specific department.
Identify the sets of users that share common access rights and create Active Directory groups for them. For example, if you are creating a computer
role for Oracle database servers, you might have different access rights for application users, database administrators, and backup operators.
Identify the role definitions each set of users should be assigned. For example, application users role might use the default Windows Login role, while
administrators might require a custom role definition with desktop and network access rights, and backup operators might require a custom role
definition with an application right.
Using Computer Roles to Simplify the Management of Access Rights
Deciding how best to use computer roles requires some planning and configuration that may not be part of your initial deployment plan. To make effective
use of computer roles, you also prepare appropriate role definitions for different sets of users. However, computer roles provide a powerful and flexible option
for managing access to computers using your existing processes and procedures for managing Active Directory group membership.
After you create a computer role, it is easy to manage even as your organization changes and grows. For example, if another Oracle database server comes
online, you add it to the computer group you created for Oracle database servers in Active Directory. If other DBAs join your organization, you add them to the
Active Directory group you created for Oracle administrators. The computer role links the computer group to the role assignment and no additional updates
are needed to accommodate these kinds of organizational changes. If you need to modify the access rights, you can change the role definition and have the
changes apply to all members of the group.
Create an Active Directory Group for a Set of Computers
Computer roles create links between objects in Active Directory and access rights defined in Access Manager. After you have identified a group of computers
that share a common attribute, you should create an Active Directory group for those computers if one does not already exist.
You can also create the computer group and add its members directly from Access Manager when you create the computer role. If you are not preparing the
Active Directory group before creating the computer role, you can skip this section and go directly to Create a new computer role.
To create an Active Directory group for computers in a computer role:
1. Open Active Directory Users and Computers to create a new Active Directory group.
2. For example, create a new Active Directory group for Oracle Database Servers.
3. Select the new computer group, right-click, then click Properties.
5. Click Object Types, select Computers, then click O K.
6. Search for and select the computers that you have identified as Oracle database servers as members of the new group, then click O K.
7. Click O K to save the group.
Create an Active Directory Group for Each Set of Access Rights
In addition to the Active Directory group for the computers in a computer role, you should have an Active Directory group for each set of users that should
have different access rights. By mapping Active Directory groups to role definitions, you can manage group membership and access rights at the same time
using your current procedures.
To create an Active Directory group for each set of users linked to a computer role:
1. Open Active Directory Users and Computers to create a new Active Directory group for each set of users to link to the computer role.
For example, create separate Active Directory groups for application users, database administrators, and backup operators using a naming convention
similar to ComputerAttribute_Role_UserSet. For example, create the following Active Directory groups:
OracleServers_Role_AppUsers
OracleServers_Role_DBAs
OracleServers_Role_Backup
2. Select each new group, right-click, then click Properties.
4. Search for and select the users that you have identified as members of the each group, then click O K.
5. Click O K to save the group membership.
Create a Role Definition for Each Set of Users with Different Access Rights
Before you create a new role definition, identify the specific rights associated with each role and define those rights if they do not already exist. For this
sample scenario, you might create role definitions similar to the following:
Oracle_AppUsers with Windows Login access and an application right for a specific database application.
Oracle_DBAs with Windows Login access and desktop and network access rights on computers in a specific zone.
Oracle_Backup with console login allowed right and an application right that allow members of the group to run backup utilities with the privileges of the
built-in Backup Operators group.
Create a New Computer Role
After you have prepared the appropriate Active Directory groups and role definitions for different sets of users, you can create one or more computer roles.
To create a new computer role:
2. Expand Zones and the parent zone or child zones until you see the zone that has the computer for which you want to define a computer role.
4. Select Computer Roles, right-click and click Create Computer Role.
5. Type a name and description for the computer role.
For example, type OracleServers, and an optional description, such as Oracle database servers in the San Francisco data center.
6. In Computers group list, select <...> to search for the Active Directory group of computers you created in Create an Active Directory group for a set
of computers.
Select <Create group > if you want to create a new Active Directory group of computers and add members now. If you are creating a new group, click
Browse to select a container to use, type a group name, and select the scope of the group, then click O K.
7. Click O K to save the computer role.
8. If you selected an existing computer group, expand Computer Roles > Members to see the computers that are members of this computer role.
If you created a new computer group at Step 6, select the new computer role, right-click Members, then select Add Computer to search for and
select one or more computers to add to the group.
Add Role Assignments to the Computer Role
If you have created the appropriate Active Directory groups and role definitions that you want to assign, you can now assign the roles to set of users as
required.
To add role assignments to users in Active Directory groups:
1. Expand the computer role you just created, for example, expand OracleServers.
3. Select the role definition from the list of roles, then click O K.
For example, select the Oracle_DBAs role definition. By default, the role is set to start immediately and never expire. You can set a Start time, E n d
time, or both start and end times for the role assignment. For example, if the role applies to a contractor who will be hired for a specific amount of time
and you want to automatically disable the role after they finish the job and leave the organization, you can specify the start and end times when you
assign the role.
4. Select whether the role assignment applies to all Active Directory accounts, all local accounts, or specific Active Directory and local accounts, then
click O K to complete the role assignment.
For example, to assign the Oracle_DBAs role to the Active Directory OracleServers_Role_DBAs security group, click Add AD Account. You can then
select Group to search for the group, select it from the results, then click O K.
5. Repeat Step 1 through Step 4 for each group that you want to add to this computer role. For example, repeat the steps to assign the Oracle_AppUsers
role to the OracleServers_Role_AppUsers security group and the Oracle_Backup role to the OracleServers_Role_Backup security group.
6. Select the Role Assignments node to see all of the role assignments you have defined for groups associated with the computer role.
7. Select the Members node to see the computers or groups of computers to which the role assignments apply.
Assigning Roles on Multiple Computers at Once
To simplify the process of assigning Active Directory users or groups to a role, you can perform a bulk role assignment. With a bulk role assignment, you can
assign a role to multiple Active Directory users and groups on multiple computers at the same time. For example, if you have two groups of SQL Server
administrators and three computers where the members of those groups need access to their SQLServerAdmin role, you can select those two groups and
those three computers to be assigned the SQLServerAdmin role in the same process. You can also specify optional start and end times for the role
assignment and have those settings apply for all of the users, groups, and computers you have selected for bulk assignment.
To assign users and groups to a role in a zone:
2. Expand Zones and the parent zone or child zones until you see the zone where you want to make role assignments.
3. Right-click, then select Assign Roles to Computers.
4. Type the user and group names you want to be included in the role assignment, then click O K.
You can specify multiple names separated by a semi-colon (;). You can also search for user and group names by typing part of the name and clicking
Check Names or by clicking Advanced and entering search criteria.
5. Type the computer names you want to be included in the role assignment, then click O K.
You can specify multiple names separated by a semi-colon (;). You can also search for the computer names by typing part of the name and clicking
Check Names or by clicking Advanced and entering search criteria.
6. Select a role for the list of roles available, then click O K.
7. Review the role assignment start and end time and the user and group accounts that are being assigned the role, then click O K.
You can make changes to the start and end times if you want those changes applied for all of the users, groups, and computers that are part of this bulk
role assignment.
After you click O K, the selected users and groups are then automatically assigned the selected role on the selected computers.
Using the Authorization Center Directly on Managed Computers
The Authorization Center is available on managed computers where you have deployed the Agent for Windows and enabled the privilege elevation service.
From the Authorization Center, you can view details about the rights, role definitions, role assignments, and auditing status for any users. Individual users can
see details about their own login rights, effective roles, role assignments, role definitions, and auditing status. Administrators can select any user of interest
to view the details for that user.
To use the Authorization Center on a local computer:
1. Log on to a computer where the Agent for Windows and privilege elevation features are deployed.
2. Click the arrow next to the notifications area in the taskbar.
3. Right-click the Delinea icon, then select Open Authorization Center.
4. Click a tab to see details about the current user’s roles.
Effective Login Rights displays the current user’s local, remote, and PowerShell login rights and whether auditing is requested, required, or not
applicable.
Effective Roles lists the roles that have been assigned to the current user and the status of each role names to which the user is assigned. You
can right-click a role, then select Role Properties to view additional details, such as any time constraints defined for the role and the specific rights
granted by the role.
Role Assignments lists details about the user’s role assignments, including where the assignment was made. For example, the Object Assigned
column indicates whether the assignment for a user is explicit, from a group, or inherited from another setting, for example, from the selection of
All Active Directory Accounts. You can right-click a role, then select Assignment Properties or Role Properties to view additional details, such as
any time constraints defined for the role and the specific rights granted by the role.
Role Definitions lists detailed information about the selected user’s login rights and the audit requirements that have been defined for the roles
the user has been assigned. You can right-click a role definition, then select Properties to view additional details.
Auditing lists the desktops used and auditing status for each desktop started in a session.
5. Click Browse to view information for another user.
6. Type all or part of the user name, then click O K.
If more than one user name is found, select the appropriate user from the results, then click O K.
7. Click Close when you are finished viewing detailed authorization information for the selected user.
Working with the Authorization Cache on Managed Computers
Authorization information—such as your rights, role definitions, and assignments—is cached locally on each computer where you have deployed the Agent for
Windows. The cache saves access privilege information to improve performance and also to persist elevated privilege capabilities for users and groups when
the computer is not connected to Active Directory.
The following sections describe:
Which Server Suite capabilities are and are not persisted by the cache when a computer is disconnected from a domain controller.
Where the cache resides.
How and when to perform cache operations such as refreshing, flushing, and dumping.
Persisted and Non-persisted Capabilities
The Server Suite cache persists several role-based capabilities when a computer is not connected to Active Directory. A computer is considered to be not
connected when the Windows agent is unable to reach one or more of the following entities:
The domain to which the computer is joined.

The domain of any zone in the zone hierarchy. The zone hierarchy is the domain of the zone that the machine is joined to, or any parent zones of that
joined zone.
An Active Directory global catalog (GC) associated with any of these domains.
If the Windows agent can reach all of these entities, it is considered to be connected.
Persisted Capabilities
These capabilities are supported when a computer is not connected:
Users can log in based on role.

Users can run applications based on role.
Users can create desktops based on role.
Computers can be removed from zones.
Delinea software can be installed (but the computer cannot be joined to a zone).
Delinea software can be upgraded, but this practice is not recommended because there will be no authorization data in the cache after the upgrade.
Non-persisted capabilities
These limitations exist when a computer is not connected:
You cannot join a zone or change a computer’s zone.

The use of Network rights is not supported.
Cache Location
The cache resides in  SYSTEMDRIVE\ProgramData\Centrify\DirectAuthorize\Cache.
Performing Cache Operations
You must have administrator privileges to perform the cache operations described here. Available cache operations include:
Refreshing the cache (perform this operation from the user interface or the command line)
Flushing the cache (performed from the command line)
Dumping the cache (performed from the command line)
Refreshing the Cache
As administrator, you can refresh the cache from the user interface or from the command line. Refreshing the cache updates the cache with fresh
information from Active Directory, ensuring that the agent has the most up-to-date information about users’ current rights and roles.
Refreshing the cache is useful if you change authorization information with the management console, and you want to see the updated information on the
Windows agent right away.
Note: In domains containing multiple domain controllers, you might not see the updated information even after you refresh the cache. In cases
such as this, wait for Active Directory replication (typically a few minutes), and then refresh the cache again. Alternatively, wait another 10
minutes and the agent will refresh the data on its own.
You can refresh and flush the cache only on computers that are connected to a domain controller.
To refresh the cache from the user interface:
1. Open the agent configuration panel by clicking Agent Configuration in the list of applications on the Windows Start menu.
2. Click Privilege Elevation Service.
3. Click Settings.
4. Click the Troubleshooting tab.
5. Click Refresh, then click O K to acknowledge the successful operation.
Note: Alternatively, you can execute the dzrefresh command line utility to refresh the cache as described in the next section.
To refresh the cache from the command line:
Execute the dzrefresh command line utility to refresh the cache. Executing dzrefresh performs the same operation as clicking the Refresh button in the
agent configuration panel Troubleshooting tab.
The syntax for running the dzrefresh utility is:
dzrefresh
Flushing the Cache
Execute the dzflush command line utility to flush (clear) the cache. Flushing the cache removes all cache data and reloads it from Active Directory. You
should flush the cache only when directed to do so by Support. Under most circumstances, you should refresh the cache rather than flush the cache.
The syntax for running the dzflush utility is:
dzflush
Dumping the Cache
Execute the dzdump command line utility to dump the cache to standard output or to a redirect file that you specify on the command line. You can also use
the options shown here to display only specific types of cache data, such as zone hierarchy, role definitions, right definitions, and other data.
You should execute the dzdump utility only when directed to do so by Support.
The syntax for running the dzdump utility is:
dzdump [/d [directory-path]] [/w=screen-width] [/s] [/n] [/g] [/l] [/a] [/r] [/i] [/t] [/z] [/u] [/h]
If you execute dzdump with no options, all dzagent in-memory cache is dumped.
Setting valid options
You can use the following options with dzdump:
/d Dump cache files from the default location.
/d=directory-path Dump cache files from the specified location.
/w=screen-width Use the specified width rather than the default of 80 for word-wrap. Set /w=0 to disable word-wrap.
/s Display SID mappings.
/n Display name mappings.
/g Display assignee mappings.
/l Display assignments in the joined zone hierarchy.
/a Display assignments for SIDs.
/r Display role definitions.
/i Display right definitions.
/t Display access token information.
/z Display zone hierarchy.
/u Display recent user log-ins.
/h Display help information.
Configuring PowerShell Remote Access
You can run PowerShell commands on remote computers and have the agent handle the authentication and privilege elevation for you. In order to run remote
PowerShell commands, the following requirements apply:
The target computer needs to have the Agent for Windows installed with the Privilege Elevation Service enabled.
Assign the user to a role with the "PowerShell remote access is allowed" system right granted.
If you're using the Audit & Monitoring Service, when a user attempts to run PowerShell remotely on a computer, the system triggers an audit trail event. Audit
& Monitoring Service is an optional service.
To assign PowerShell remote access to a user:
1. In the Access Manager console, open the zone that the Windows system to be managed belongs to (Access Manager is not necessary installed on the
machine with the Windows agent).
2. Under Role Definitions, right-click a role that you'd like to assign PowerShell remote access permission to and select Properties.
3. Under System Rights > Windows rights, select PowerShell remote access is allowed.
4. Right-click Role >Assignment and select Assign Role.
5. Select the role as defined above and assign the Windows account to it.
What Gets Audited for Remote PowerShell Commands and Scripts
For cases where someone runs individual PowerShell cmdlets, the audit trail event captures the following details:
Specific cmdlets that were run

Arguments
Return codes
User who ran the cmdlets
The timestamp when the user ran the cmdlets
For cases where someone runs a PowerShell script, the audit trail event captures the name of the script as well, and if the script was run remotely the audit
trail event captures the contents of the script. If the script is very long, the audit trail will truncate it and add an ellipsis (...).
Note: If the user runs a PowerShell script on the target system from that same system, the audit trail event does NOT capture the contents of the
script. This is due to a limitation in Windows Remote Management. Basically, the thing to remember is that if you send over script text to a remote
system, the audit trail captures the script text; if you send over just a script filename, that's what the audit trail captures.
Examples of Remote PowerShell Commands
For example, if a user runs individual PowerShell commands on a remote system, they would start the session with a command similar to the following:
Enter-PSSession -ComputerName targetcomputername
The audit trail event captures details about any commands that the user enters during the above PowerShell session.
As another example, if a user runs a script without first creating the remote session and runs the script against a remote, target system from another system,
the user might run a command similar to the following:
Invoke-Command -ComputerName targetcomputername -FilePath {c:\script.ps1}
In this second example, you'll know that the user ran a script because there'll be a isscript=true parameter in the audit trail.
As a final example, if a user runs a script without first creating the remote session and runs the script from the target system, the user might run a command
similar to the following:
Invoke-Command -ComputerName targetcomputername -Command{c:\script.ps1}
Hiding the Remote PowerShell Script Text
There may be situations where your users have scripts to run on remote systems but you don't want or need the script text to appear in the audit log. To hide
the script text from the audit log, change the following registry to 1 (the default value is 0): 
SOFTWARE\Policies\Centrify\DirectAuthorize\Agent\HideRemotePsScript (REG_DWORD)
You can set the HideRemotePsScript option by group policy.
Authentication Service Enforcement
Any time you open the Access Manager console, a background process determines the availability of licenses.
As you increase the number of licenses in use, license enforcement is progressive. If the number of computers is less than 90% of the number of licenses you
have purchased, there’s no affect on any auditing features. If the number of computers is more than 90% of the licenses purchased, enforcement depends on
the number of licenses in use:
90-100% of the licensing limit displays a warning message that you are close to over deployment, but you can continue to use all authentication and
privilege elevation features.
100-120% of the licensing limit displays a warning message that you must acknowledge by clicking O K when you open the console, after which you can
resume using the console.
Over 120% of the licensing limit displays a warning message for 60 seconds when you open the console. If you see the 60 second warning message, use
the License dialog box to add license keys to continue using features.
You can contact Delinea to purchase additional licenses or remove some computers to bring the number of licenses used into compliance.
Configuring MFA with RADIUS for Privilege Elevation Service for Windows Checklist
This document provides a configuration checklist for 3rd party multi-factor authentication providers such as Duo, Okta, SecurID (or any other vendor that
provides a RADIUS service) to provide identity validation with the Privilege Elevation Service in the Microsoft Windows platform.
If you have an identity service provider (such as Duo, Okta, SecureID, and so forth) that you use for MFA logins, you can integrate authentication and privilege
elevation with your identity provider and the RADIUS protocol to require MFA for privilege elevation tasks, such as Run with Privilege and New Desktop.
Make sure that you work with your RADIUS expert along with your network and directory services lead administrators during the design and configuration
tasks.
The checklist below includes links to documented procedures.
Note: If you use Privileged Access Service, although you can enable MFA with RADIUS, the recommended practice is that you use the native
integration.
RADIUS Configuration
Step# Notes
Step
RADIUS requirements
Gather the following settings

for your RADIUS service: IP
1 address or fully qualified
domain name Port Timeout
settings Pre-shared secret
Verify that you can generate

2 a RADIUS one-time password
successfully.
Verify that identity

authentication is working
3
correctly with your RADIUS
system.
Have access to someone who

is knowledgeable about your
RADIUS system and can
4
answer questions or help
troubleshoot issues, if
needed.
Windows and Active

Directory requirements for
RADIUS configuration
A Windows computer to use

as a RADIUS client for initial
5
testing, including: Client
name Client IP address
Make sure that client

systems can reach the
RADIUS server over the
network (check your firewall
6 settings). You may need help
also from your network team
if your RADIUS cluster has a
load-balancer in the front
end.
You have administrative

access to the designated
7 Windows computer so that
Step# Notes
Step
you can install software and

do configurations.
You have Active Directory

account access so that you
8 can modify group policies
that apply to the target
computer.
You have access to the Group

9
Policy Management Console.
Your Active Directory expert

must decide how the group
policy layout and scope will
10 be designed so that the group
policies are applied to the
clients based on their RADIUS
service availability.
Authentication and Privilege

Elevation Services
Requirements for RADIUS
configuration
Access Manager console is

11 installed on the client For details, see Running the setup program on a Windows computer.
computer.
The Agent for Windows is

installed on the client system,
you've configured the system
12 to work with Privilege For details, see Installing the Agent for Windows.
Elevation Service, including
joining the computer to a
zone.

access to Access Manager so
13
that you can manage roles
and rights.
The group policy templates

from release 19.6 or later are
installed. For RADIUS
14 For details, see Installing group policy extensions separately from Access Manager.
configuration, you need at
least the Delinea Windows
settings group policies.
If you want to capture the

RADIUS events in your SIEM
In GPME, go to computer Configuration > Policies > Audit Trail Settings > Global Settings > Send audit trail to log
15 system, make sure the Audit
file (this is not configured by default). For details, see "Send audit trail to log file" in the Group Policy Guide.
trail is configured to go to the
local log file.
Step# Notes
Step
You have a role and user to

test with. Make sure the role
Make sure that you can elevate privileges successfully for that user and role before you try to configure RADIUS
16 has rights for privilege
authentication.
elevation, such as New
Desktop rights or Run as Role.
Configure a system to use

RADIUS for privilege
elevation (using group
policies)
Configure the following group policies: Windows > MFA Settings > Specify the authentication source for privilege
elevation : set this policy to RADIUS Authentication. Windows > MFA Settings > Remote Authentication Dial-In
User Service (RADIUS) Settings > Enable Remote Authentication Dial-In User Service (RADIUS): enable this
Enable and configure the policy. Specify the RADIUS connection timeout: Configure to match your RADIUS timeout setting. Specify the
17
RADIUS group policies. RADIUS server IP address: enter your RADIUS IP address. Specify the RADIUS server port number: enter your
RADIUS port number (the default is 1812). For details, see "Remote Authentication Dial-In User Service (RADIUS)
Service Settings" in the Group Policy Guide. After you update the policies, do a group policy update on the Windows
client computer.
Configure the role to require For example: Right-click your test role and choose Properties. The Role Properties dialog box opens. Click the Run
18 re-authentication using As tab. Select Re-authenticate current user and then select Require multi-factor authentication. Click OK to apply
multi-factor authentication. the changes.
Run dzflush to make sure that

19 the agent has the changes For details, see Using dzflush.
from Access Manager.
The RADIUS secret is unique to each system and will match the secret that the RADIUS server has. You can set the
pre-shared secret by either of the following methods on the client computer: Run the Set-CdmRadiusSecret
Set the RADIUS shared
20 cmdlet to set the RADIUS shared client secret. For details, see the DirectAuthorize PowerShell cmdlet help. Use
secret.
the Agent Configuration settings dialog box to configure the RADIUS server, including the pre-shared secret. For
details, see Configuring agent settings for the Identity Platform.
TEST AND VERIFY
For example, if your role has New Desktop rights: Right-click the System Tray and select New Desktop. In the
Verify that a user can elevate
dialog box that appears, select your test role and click OK. If the RADIUS authentication has been configured
21 privileges by entering the
successfully, you are prompted to enter a password for RADIUS authentication. Enter the password and click Next
RADIUS one-time password.
to continue. You can also view the audit trails for the successful authentication in the system's event log.
Verify that a user cannot

elevate privileges after
22
entering an incorrect RADIUS
one-time password.
Adding Remote Users Automatically
If desired, you can configure your deployment so that members of the Windows Login group or the Windows Remote Login group are also automatically added
to the Remote Desktop Users group and the ConsoleLogonUser group.
To make this change, add the following registry entry on each computer where you have installed the Agent for Windows: 
HKEY_LOCAL_MACHINE\SOFTWARE\Centrify\DirectAuthorize\Agent\EnableAddUsersToRdpAndConsoleLogOn = 1
If you later uninstall the agent, the uninstall process removes the affected user accounts from the Remote Desktop Users group and the ConsoleLogonUser
group. Only the user accounts that the agent added to those groups are affected.
Enabling Users to Run Applications with Alternate Accounts
Alternate accounts are typically a privileged or administrator account in Active Directory that's associated with an owner account. You can log in to the
alternate account using your main account.
For example, system administrators typically have several accounts, a user account for general log-ins and an administrative account to access specific
systems and services.
Here are the things you need to do in order to enable the ability to run with alternate accounts:
1. Set up alternate accounts for users in Privileged Access Service

2. Install a cloud connector in your domain and the Web Server (IWA) service is enabled.
3. Enable the policy entitled "Enable run with alternate account."
4. (Optional but recommended) Configure the following policies to set up a grace period after which time users running applications with alternate
accounts must re-authenticate:
"Require re-authentication to run application with alternate account"
"Configure Windows authentication grace period for run with alternate account"
5. Install the Agent for Windows and enable the Identity Platform service on each computer where you want users to be able to run with alternate
accounts.
If you don't enable the run with alternate account feature, your users can still run applications with these alternate accounts by logging in to Privileged
Access Service and checking out the password.
Managing Local Windows Users and Groups
You can manage your local Windows users and groups, if desired. This way, you can centrally manage the accounts.
Overall, to manage local users and groups on Windows systems, you'll need to
Install the Agent for Windows on each Windows system where you want to manage local accounts.
Enable local account management on those Windows systems in the Privilege Elevation settings for the agent. For details, see Enabling Windows local
account management.
In Access Manager, you can then add, edit, or remove local users and groups. For details, Adding local Windows accounts and Removing local Windows
accounts
Manage the passwords for local Windows accounts. For details, see Creating and managing local Windows user passwords.
Use group policies to manage local Windows accounts. .
Adding Local Windows Accounts
Before you enable local account management on your Windows computers, add the local users and groups in Access Manager.
Note: {/b}If you first enable local account management with the enforce option and if you have any existing local accounts on that system but not defined in a
zone, then the service will remove those local users during the next synchronization. Built-in local Windows accounts are not removed.
To add a local Windows user:
1. In Access Manager, navigate to either a zone or a Windows computer and go to Windows Data
2. Right -click Local Users and select Add User to Zone or Add User, depending on where you're adding the user.
3. Enter the user name and click O K.
4. Specify the attributes for the local Windows user:
Full name: The first and last name of the new local Windows user.
Description: A description of the user.
State: Specify one of the following:
Enable: Set the state to Enable for a local Windows account that is in use.
Disable: Set the state to Disable for a local Windows account that is not in use.
Remove: If you've chosen not to enforce local account management, mark the user as Remove and the service will remove the user at the
next synchronization interval.
Note: {/b}The service will not remove any built-in local Windows accounts, even if you mark it as Remove in Access Manager.
Password options: If desired, select any of the following:
User must change password at next logon: The service will force the local Windows user to change the account password the next
time that the user logs in to the computer. Note that this option applies only to new accounts.
User cannot change password: The user won't be able to change the password.
Password never expires: The user's password will never expire.
The new user will be available on the affected systems after the next local account synchronization.
To add a local Windows group:
1. In Access Manager, navigate to either a zone or a Windows computer and go to Windows Data
1. Right -click Local Groups and select Add Group to Zone or Add Group, depending on where you're adding the group.
2. Enter the group name and click O K.
2. Specify the attributes for the local Windows group:
Description: Enter a description of your choice.
Members: Click A d d to launch the Add Members dialog. In a comma-separated list, type the names of the users who will be in the group.
Note that Access Manager does not check the validity of the user names that you provide. You should ensure that all of the names that you provide
are local Windows user names that currently exist.
State: Specify either Enable or Remove.
Enable: Set the state to Enable for a local Windows account that is in use.
Remove: If you've chosen not to enforce local account management, mark the group as Remove and the service will remove the group at
the next synchronization interval.
The new group will be available on the affected systems after the next local account synchronization.
Enabling Windows Local Account Management
You can have Delinea manage your local Windows user and group accounts; to do so, you need to enable and configure a few settings. Install the agent and
enable local account management on each Windows system where you want to manage local accounts.
Be aware that if you enable local account management, the service does not delete any built-in Windows users or groups, even if you mark one of those
accounts for remove.
Note: {/b}Windows local account management is not supported on domain controllers.
To configure local account management for Windows:
1. From the Privilege Elevation Service Settings dialog box Local Account Management tab, click Configure.
The Local Account Management Configuration dialog box opens.
2. Select the Enable local account management option.
3. Select Yes to enforce local account management or N o to not enforce local account management.
Enforcing local account management means that after you remove a local Windows user or group from Access Manager, the service will remove the
local user or group from the computer after the next synchronization.
If you choose not to enforce local account management, in order to remove a user you mark it as removed rather than explicitly removing the account
from Access Manager.
4. Specify a script that will run when the service synchronizes local account information with Access Manager and the affected computers. The script can
set the passwords for the local accounts and also display a list of enabled, disabled, or removed users.
For details, see Creating and managing local Windows user passwords.
There is a sample script provided that you can use as a starting point:
C:\Program Files\Centrify\Agent for Windows\SampleNotification.ps1
The script will run after each synchronization of local accounts when the any of the following have occurred:
New local users are added

Local users are enabled
Local users are disabled
Local users are removed
5. Specify a synchronization interval.
This interval controls how often the service synchronizes local account information between Access Manager and the affected computers. The default
is 60 minutes.
6. Click O K to save your changes and close the dialog box.
Creating and Managing Local Windows User Passwords
After you create local Windows users, you still need to assign a password to each user. Instead of manually setting the passwords in Local Users and Groups,
you'll set up the initial passwords for your local user accounts by way of a PowerShell script.
There is a sample script provided that you can use as a starting point:
C:\Program Files\Centrify\Agent for Windows\SampleNotification.ps1
In general, the script should both set passwords and notify you of changes in local accounts. The script will run after each synchronization of local accounts
when the any of the following have occurred:
New local users are added

Local users are enabled
Local users are disabled
Local users are removed
Typically, the script should perform the following user account tasks:
Assign a random password to newly provisioned local users.

Provide the user account information, including the generated passwords, to your password management solution.
After you have the script set up, you can use group policy to automatically run it. .
How you set up the passwords and the script depends on if you're using a password management system or not. Below are the ways you can set up local user
passwords.
Use Privileged Access Service to manage local Windows account passwords:
1. Register for Privileged Access Service.
2. Download the Client for Windows software package.
3. On each Windows computer where you will assign passwords to local users, run the cenroll command to register the computer as a managed resource.
4. Create a PowerShell notification script that runs on each of these Windows computers, gives each user a random password, and sends the password to
Privileged Access Service.
In the script, you can set it to run the csetaccount command to send the password to Privileged Access Service.
5. Using one of the following two methods, configure the notification script to run after the agent synchronizes local account information:
In the local account management settings for the agent
Agent settings > Local Account Management tab > Configure > Local Account Management Configuration dialog box
In the group policy
(Settings > Windows Settings > Local Account Management > Notification Command Line)
Use a third-party system to manage local Windows account passwords:
1. Create a PowerShell script that runs on each of these Windows computers and gives each user a random password.
2. Include a section in the script that submits the passwords to the password management product for storage and maintenance.
3. Using one of the following two methods, configure the notification script to run after the agent synchronizes local account information:
In the local account management settings for the agent
Agent settings > Local Account Management tab > Configure > Local Account Management Configuration dialog box
In the group policy
(Settings > Windows Settings > Local Account Management > Notification Command Line)
Removing Local Windows Accounts
If you have enabled local account management on a Windows system, there are two different ways to remove users. Your approach depends on if you've
configured to enforce local account management or not.
Be aware that if you enable local account management, the service does not delete any built-in Windows users or groups, even if you mark one of those
accounts for remove.
To remove a local Windows user or group if local account management is enforced:
In Access Manager, right-click the user or group and select Delete.
The account is removed from Access Manager immediately. When the service next synchronizes local account information, the service removes the
user or group from the affected Windows systems too.
To remove a local Windows user or group if local account management is not enforced:
In Access Manager, right-click the desired user or group and select Change Profile State, then select Remove.
The account is marked as "Remove" and remains visible in Access Manager. When the service next synchronizes local account information, the service
removes the user or group from the affected Windows systems too.
Managing Auditing and Audit Permissions
This chapter describes how to use the Master Auditor role and group policies to control who is audited and who can search and play back captured user
sessions for an installation.
Configuring Selective Auditing
If you are using identity and privilege management features, you can control audit and monitoring service by using Access Manager to configure role
definitions with different audit requirements, and then assigning those role definitions to different sets of Active Directory users. For more information about
using role definitions to control auditing, see Defining custom roles with specific rights.
If you are using audit and monitoring service without also using identity and privilege management features, you can use group policies to control which
Windows users to audit, or to capture activity for all Windows users.
To control audit and monitoring service using group policies:
2. Expand the forest and domains to select the Default Domain Policy object.
3. Right-click, then click Edit to open Group Policy Management Editor.
4. Expand Computer Configuration > Policies, then select DirectAudit Settings.
5. Select the Audited user list to identify specific users to audit.
When you enable this group policy, only the users you specify in the policy are audited. If this policy is not configured, all users are audited.
6. Select the Non-audited user list to identify specific users that should not be audited.
When you enable this group policy, only the users you specify are not audited. If this policy is not configured, all users are audited. If you enable both the
Audited user list and the Non-audited user list policies, the users you include in the Non-audited user list take precedence over the Audited user list.
The following table details the effect of configuring and enabling the Audited user list and Non-audited user list group policies, and including or not including
Windows users in those lists.
Non-
Audited
audited How the setting affects auditing
user list
user list
Not Not
No users are defined for either policy, so all users accessing audited computers are audited.
configured configured
Not Only the users you specify in the Audited user list policy are audited. If no users are specified when the policy is enabled, no users
Enabled
configured are audited.
Not
Enabled Only AUL is enabled, but user is not listed in it.
configured
Not If no users are specified in the Non-audited user list and the policy is enabled, no users are exempt from auditing. All users are
Enabled
configured audited.
If both policies are enabled, the non-audited user takes precedence over the audited list of users. If a user is specified in the
audited list, that user is explicitly audited. If a user is specified in the non-audited list, that user is explicitly not audited. If the same
Enabled Enabled
user is specified in both lists, the user is not audited because the non-audited user takes precedence. If no users are specified for
either policy, all users are audited because the non-audited user takes precedence.
Enabling Audit Notification
If you enable audit notification, users see a message informing them that their actions are being auditing when they log on. fter you enable notification, the
message is always displayed on audited computers if the session activity is being recorded.
To enable audit notification for an installation:
1. In the Audit Manager console, right-click the installation name, then select Properties.
2. Click the Notification tab.
3. Select Enable notification.
Deselect this option to turn off notification.
4. Click the browse button to locate and select a text file that contains the message you want to display.
A notification message is required if you select the Enable notification option. The contents of the file you select are displayed below the file location.
The maximum text file size is 30 KB.
5. Click the browse button to locate and select an image to appear as a banner across the top of the audit notification.
Displaying a banner image is optional when you enable notification. The maximum image file size is 15 KB. For the best image display, use an image that
is 468 pixels wide by 60 pixels high.
Note: {/b}Animated GIF files are not supported for use as audit notifications. If you do specify an animated GIF, the image displays as a static image.
6. Click O K or Apply.
Users will see the notification message the next time they log in.
7. If you enable notification after you have deployed agents, update the local policy on the audited computers by running the following command:
gpupdate /FORCE
Managing Audit Roles and Auditors
Audit roles grant access to auditors to search, replay, and delete specific audited sessions using the Audit Analyzer console. Each audit role identifies a set of
audited sessions, the list of auditors who have access to those sessions, and what the auditors in a specific role are allowed to do.
You identify a set of sessions by specifying criteria you want to use, for example, all sessions from a particular audited computer, associated with a specific
application, or recorded during a specific period of time.
You identify the auditors for a set of sessions by specifying individual Active Directory users or Active Directory groups of auditors. If you use Active Directory
groups, you can manage the privileges for all of the members of the group using your existing procedures for managing Active Directory groups. You can also
configure the type of access granted to each member of the audit role.
You create and assign users and groups to audit roles using the Audit Manager console. You create the audit roles by rightclicking on the Audit Roles node. You
add users and groups to an audit role by right-clicking on the specific role name.
Every installation automatically has a Master Auditor role. The Master Auditor has access to all audit data and permission to read, replay, update the review
status, and delete sessions for the entire installation. The Master Auditor can also create roles, assign users, set permissions, and delegate administrative
tasks for all of the audit stores in the installation. You cannot rename, delete, or modify permissions for the Master Auditor, but you can assign other users and
groups to the Master Auditor role.
Granting Permission to Manage Audit Roles
The Master Auditor can grant the Manage Audit Role permission for an installation to one or more audit team leaders. The Manage Audit Role permission
grants full control over all of the audit roles in the installation. An audit team leader can then create new roles, change the permissions specific audit roles
grant, add or remove members, and remove roles.
When creating an audit role, an audit team leader defines the following:
Target session type and optional other criteria.

A collection of rights on the target sessions: Read, Update Status, Replay, and Delete.
For example, an audit team leader might define the following audit roles to control what different team members can do:
A role named Windows Session Viewer for first level reviewers with a target of Windows sessions and only the right to Read session information. The
members of the First Review group who are assigned to the Windows Session Viewer audit role can read, but not delete, replay or update the status of
Windows sessions in the installation.
A role named Incident Escalation for security managers with a target of Windows sessions from the last 72 hours, and permission to Read, Replay, and
Update Status for the targeted session. The members of the Security group who are assigned to the Incident Escalation audit role can read, replay, and
update the review status of Windows sessions from the previous 72 hours, but not delete any of the sessions they have reviewed.
Creating a New Audit Role
If you are the Master Auditor or have been granted the Manage Audit Role right, you can create new audit roles for your organization.
To create a new audit role:
2. Select Audit Roles, right-click, then click Add Audit Role.
3. Type a name and description for the new audit role, then click Next.
4. Select the type of session.
For example, select Windows session to limit this audit role to sessions captured by the Agent for Windows.
5. Click A d d to select additional criteria, such as time constraints, review status, or application used.
After you click Add, select an attribute and the appropriate criteria, then click O K. For example, if you select Time, you can then select specific date
range or a period of time, such as the past 24 hours or this year.
6. Click Execute Query to test the criteria you have selected by examining the results the query returns.
7. Click Close to close the query results, then click Next.
8. Select the rights to allow for this role, then click Next.
9. Review your settings for this role, then click Next.
By default, the Assign Users and Groups to the Audit Role option is selected so that you can immediately begin populating the new audit role.
10. Click Finish to begin adding users and groups to the role.
Assigning Users and Groups to an Audit Role
If you selected the Assign Users and Groups to the Audit Role option at the end of the Add Audit Role wizard, the Assign Users and Groups to the Audit Role
wizard opens automatically. You can also open the wizard at any time by right-clicking a specific audit role name in the Audit Manager console and choosing
Assign Users and Groups.
To assign users and groups to an audit role:
2. Expand Audit Roles, and select a specific audit role name.
3. Right-click, then click Assign Users and Groups.
4. Type all or part of a name and click O K.
If there is more than one name that matches the criteria you specify, select the appropriate name from the names found, then click O K. A user or group
can be a member of more than one audit role.
Delegating Audit-related Permissions
As the Master Auditor, you can delegate administrative tasks to other Active Directory users or groups. When you grant administrative rights to designated
users and groups, you make them “trustees” with permission to perform specific operations. Because delegating administrative tasks to other users is a key
part of managing an installation, it is covered in the next chapter.
However, one of the permissions you can delegate to other users and groups is the Manage Audit Role permission. With this permission, selected trustees can
create, modify, and delete audit roles. For more information about delegating administrative tasks, see Setting administrative permissions.
Modifying an Audit Role's Properties
The Master Auditor and the audit roles you define are listed under Audit Roles in the Audit Manager console. Selecting a specific audit role name displays a list
of members in the right pane. If you are the Master Auditor or been granted the Manage Audit Role permission, you can modify the properties for an audit role
after you have created it by selecting the role in Audit Manager, right-clicking, then selecting Properties. For example, you can change the name or
description of an audit role, specify the type of sessions members of the role can access, the privileges the audit role grants, and the users and groups who
are assigned to the audit role.
How Access Roles and Audit Roles Differ
Depending on whether you have enabled audit and monitoring service together with identity and privilege manager on an agent-managed computer, you
might have two sets of roles or just one set of roles and the information captured and the activity allowed depends on the type of role being used.
Identity and Privilege Management Only
If you have only enabled identity and privilege management on a computer and defined access roles:
Users will not be able to log on if they are assigned to a role where is audit and monitoring service required.
Users will be able to log on if they are assigned to a role where the audit if possible option is set. In this case, only identity and privilege management
audit trail events are captured. For example, the agent records successful and failed logons and when users change from one role to another. Because
audit and monitoring service is not enabled, the agent does not capture a video record of all user activity. You also are not able to define audit roles to
control who can read or delete audit trail records.
Users will be able to log on if they are assigned to a role that does not require audit and monitoring service. In this case, only identity and privilege
management audit trail events are captured.
Auditors will not be able to review user activity on these computers. You also are not able to define audit roles to control who can read or delete audit
trail records.
If no audit and monitoring service components are installed, you must use the Windows Event Viewer to search for and review audit trail events.
Auditing Only
If you have enabled only audit and monitoring service on a computer and defined access roles:
Users will be able to log on if they are assigned to a role where audit and monitoring service is required as long as the agent is running.
Users will be able to log on if they are assigned to a role where the audit if possible option is set. In this case, logging on starts a video record of all user
activity on the computer. Because identity and privilege management are not enabled, the user cannot select any access roles that provide desktop,
application, or network access rights. The user cannot change roles so only the audit trail records successful and failed logons events.
Users will be able to log on if they are assigned to a role that does not require audit and monitoring service. In this case, audit trail events are recorded,
but no session activity is captured.
Auditors will be able to review all or selected user activity on these computers, and you can define audit roles to control who has access to the captured
user sessions based on the criteria you specify.
Identity and Privilege Management and Auditing on the Same Computer
If you have enabled audit and monitoring service together with identity and privilege management on the same computer and defined access and audit roles:
Users will be able to log on if they are assigned to a role where audit and monitoring service is required as long as the agent is running. If the agent is
stopped for any reason, the user will be allowed to log on only if also assigned a role with a rescue system right.
Users will be able to log on if they are assigned to a role where the audit if possible option is set. If the audit and monitoring service service is active and
you have enabled video capture auditing, both audit trail events and user activity are captured. For example, the agent records successful and failed
logons and user activity when users change from one role to another. If the audit and monitoring service service is not enabled or not currently active,
the agent does not capture a video record of all user activity.
Users will be able to log on if they are assigned to a role that does not require audit and monitoring service. In this case, only audit trail events are
captured.
Auditors will be able to review user activity associated with specific roles on these computers, and you can define audit roles to control who has access
to the captured user sessions based on the criteria you specify.
Managing Auditing for an Installation
This chapter describes how to secure and manage the audit and monitoring service infrastructure after the initial deployment of Delinea software on
Windows computers. It includes tasks that are done by users assigned the Master Auditor role for an installation and users who are Microsoft SQL Server
database administrators.
Securing an Installation
For production deployments, you can take the following steps to secure an audit and monitoring service installation:
Use the Installation group policy to specify which installation agents and collectors are part of. By enabling the Installation group policy you can prevent
local administrators from configuring a computer to be part of an unauthorized installation.
Configure a trusted group of collectors to prevent a hacker from creating a rogue collector to collect data from agents.
Configure a trusted group of agents to prevent a hacker from performing a Denial of Service attack on the collector and database by flooding a collector
with false audit data.
Encrypt all data sent from the collector to the database.
Before you can follow these steps to secure an installation, you must have access to an Active Directory user account with permission to create Active
Directory security groups, enable group policies, and edit Group Policy Objects.
To secure an installation using Windows group policy:

2. Expand the forest and domain to select the Default Domain Policy object.
4. Expand Computer Configuration > Policies > CentrifyDirectAudit  Settings, then select Common
Settings.
5. Double-click the Installation policy in the right pane.
8. Click O K to close the Installation properties.
Securing an Audit Store with Trusted Collectors and Agents
By default, audit stores are configured to trust all audited computers and collectors in the installation. Trusting all computers by default makes it easier to
deploy and test audit and monitoring service in an evaluation or demonstration environment. For a production environment, however, you should secure the
audit store by explicitly defining the computers the audit store can trust.
You can define two lists of trusted computers:
Audited computers that can be trusted.

Collector computers that can be trusted.
To secure an audit store:
1. Open the Audit Manager console.
2. Expand the installation and Audit Stores nodes.
3. Select the audit store you want to secure, right-click, then select Properties.
4. Click the Advanced tab.
5. Select Define trusted Collector list, then click A d d.
6. Select a domain, click O K, then search for and select the collectors to trust and click O K to add the selected computers to the list.
Only the collectors you add to the trusted list are allowed to connect to the audit store database. All other collectors are considered untrusted and
cannot write to the audit store database.
7. Select Define trusted Audited System list, then click A d d.
8. Select a domain, click O K, then search for and select the audited computers to trust and click O K to add the selected computers to the list.
Only the audited computers you add to the trusted list are allowed to connect to the trusted collectors. All other computers are considered untrusted
and cannot send audit data to trusted collectors.
9. Click O K to close the audit store properties dialog box.
The following example illustrates the configuration of trusted collectors and trusted audited computers.
In this example, the audit store trusts the computers represented by P, Q, and R.Those are the only computers that have been identified as trusted collectors
in the audit store Properties list. The audit store has been configured to trust the audited computers represented by D, E, and F. As a result of this
configuration:
Audited computers D, E, and F only send audit data to the trusted collectors P, Q, and R.
Trusted collectors P, Q, and R only accept audit data from the trusted audited computers D, E, and F.
The audit store database only accepts data for its trusted collectors P, Q, and R, and therefore only stores audit data that originated on the trusted
audited computers D, E, and F.
Disabling a trusted list
After you have added trusted collectors and audited computers to these lists, you can disable either one or both lists at any time to remove the security
restrictions. For example, if you decide to allow audit and monitoring service data from all audited computers, you can open the audit store properties, click
the Advanced tab, and deselect the Define trusted Audited System list option. You don’t have to remove any computers from the list. The audit store
continues to only accept data from trusted collectors.
Using security groups to define trusted computers
You can use Active Directory security groups to manage trusted computer accounts. For example, if you create a group for trusted audited computers and a
group for trusted collectors, you can use those groups to define the list of trusted collectors and audited computers for the audit store. Any time you add a
new computer to one of those groups, thereafter, it is automatically trusted, without requiring any update to the audit store properties.
Securing Network Traffic with Encryption
The last step in securing an installation is to secure the data collected and stored through encryption. The following summarizes how data is secured as it
moves from component to component:
Between an audited computer and the spooler that stores the data locally when no collectors are available, audit data is not encrypted. Only the local
Administrator account can access the data by default.
Between the audited computer’s data collection service (wdad) and the collector, data is secured using Generic Security Services Application Program
Interface (GSSAPI) with Kerberos encryption.
Between the collector and the audit store database, data can be secured using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or
AES (Windows 2008) encryption if the database is configured to use SSL connections.
Between the audit store and management databases, data can be secured using Secure Socket Layer (SSL) connections and ARC4 (Windows 2003) or
AES (Windows 2008) encryption if the database is configured to use SSL connections.
Between the management database and the Audit Manager console, data can be secured using Secure Socket Layer (SSL) connections and ARC4
(Windows 2003) or AES (Windows 2008) encryption if the database is configured to use SSL connections.
The following illustration summarizes the flow of data and how network traffic is secured from one component to the next.
Enabling Secure Socket Layer (SSL) communication
Although the database connections can be secured using SSL, you must configure SSL support for Microsoft SQL Server as part of SQL Server administration.
You must also have valid certificates installed on clients and the database server. If you are not the database administrator, you should contact the database
administrator to determine whether encryption has been enabled and appropriate certificates have been installed. For more information about enabling SSL
encryption for SQL Server and installing the required certificates, see the following Microsoft support article:
http://support.microsoft.com/kb/316898
Enabling encryption for Microsoft SQL Server Express
If you use Microsoft SQL Server Express, encryption is turned off by default. To secure the data transferred to the database server, you should turn encryption
on.
To enable encryption for each audit store and management database:
1. Log on to the computer hosting an audit store or management database with an account that has database administrator authority.
2. Open SQL Server Configuration Manager.
3. Select the SQL Server Network Configuration node, right-click Protocols for DBINSTANCE, then select Properties.
4. On the Flags tab, select Yes for the Force Encryption option, then click O K to save the setting.
Using a service account for Microsoft SQL Server
When you install Microsoft SQL Server, you specify whether to use Windows authentication or a mix of Windows and SQL Server authentication. You also
specify the accounts that the database services should use. By default, system accounts are used. If SQL Server uses a domain user account instead of a
system account, you should ensure that the account has permission to update the SQL Server computer object in Active Directory. If the account has
permission to update the computer where SQL Server is running, SQL Server can publish its service principal name (SPN) automatically. Getting the correct
service principal name is important because Windows authentication relies on the SPN to find services and DirectManage Audit uses Windows
authentication for console-to-audit management database connections. If the SPN is not found, the connection between the console and audit management
database fails.
The audit management database-to-audit store connection and the collector-to-audit store connection can use either Windows authentication or SQL
Server authentication. If SQL Server authentication is used, it does not matter whether the SQL Server instance uses a system account or a service account.
If you have configured SQL Server to use Windows authentication only, be sure that the Windows account is allowed to connect to the audit management
database and to the audit store database.
Setting Administrative Permissions
When you create a new installation, you become the primary administrator for that installation. As the primary administrator and Master Auditor, you have full
control over the entire installation and the ability to delegate administrative tasks to any other Active Directory user or group. When you grant administrative
rights to designated users and groups, you make them “trustees” with permission to perform specific operations. You can set granular permissions to tightly
control what specific users can do or grant broad authority over operations in an installation.
If you have a large or widely-distributed installation, you can also install additional Audit Manager and Audit Analyzer consoles for the users who have been
delegated administrative tasks to use.
To delegate administrative tasks to other users:
2. Select the installation name, right-click, then click Properties.
3. Click the Security tab to delegate administrative tasks for the entire installation.
4. Click A d d to add Active Directory users or groups to the list of trustees who granted any type of rights on this installation.
5. Select a user or group listed, then select the appropriate rights for that trustee, then click O K.
The following table lists the rights available.
Select this
To grant these rights to a trustee
permission
Full Control All operations on the selected installation.
Change
Add or remove users and groups as trustees for the installation. Modify permissions for trustees on the selected installation.
Permissions
Modify Name Modify display name for the selected installation.
Manage
Management Add or remove management databases for the selected installation.
Database List
Manage Audit
Add or remove audit stores for the selected installation.
Store List
Manage Enable a trusted group of collectors for this audit store. Add a collector to the trusted group of collector in this audit store. Remove
Collectors collector from the trusted collectors in this audit store. Remove disconnected collector records from this audit store.
Manage Enable trusted group of audited computers for this audit store. Add a computer to the trusted group of audited computers in this audit
Audited store. Remove a computer from the trusted group of audited computers in this audit store. Remove disconnected audited computer
Systems records from this audit store.
Manage Audit Add, modify, or remove audit roles in the selected installation. Assign users and groups to audit roles. Remove users and groups from
Role roles.
Manage
Add, modify, or remove queries in the selected installation.
Queries
Manage
Add or remove publication locations for the selected installation.
Publications
Manage
Add or remove license keys for the selected installation.
Licenses
Modify
Enable or disable audit notification in the selected installation. Select the notification message. Select a banner image.
Notification
Modify Audit Enable or disable the option to capture video of all user activity on audited computers. Control whether users are allowed to update the
Options review status of their own sessions. Control whether users are allowed to delete their own sessions.
View Enable to view audited computers and sessions.
1. Click O K to complete the delegation of administrative rights for the selected installation.
You can also delegate administrative tasks for individual audit stores and management databases, and set permissions on audit roles. For information about
delegating administrative tasks for audit stores, see Configuring permissions for an audit store. For information about delegating administrative tasks for
management databases, see Configuring permissions for the management database.
For information about setting permissions on audit roles, see Managing audit roles and auditors.
Managing Audit Stores
An audit store defines a set of Active Directory sites or subnets and a collection of databases that contain audit data. Typically, an installation has one audit
store with multiple databases. However, you can add audit stores if you are auditing computers in a large and widely distributed network or have multiple
Active Directory sites with computers you want to audit.
Configuring the Scope of an Audit Store
In most organizations, a single audit store is used to map to an Active Directory site. However, there are situations where you might want to define the scope
of an audit store based on subnets. For example:
If you have a subnet that Active Directory considers part of a site that is connected over a slow link you might want to configure a separate audit store
and collectors that service audited computers in the remote subnet.
If you have very large Active Directory site, you might require multiple audit stores for load distribution. You can accomplish this by partitioning an Active
Directory site into multiple audit stores based on subnets. Each subnet has its own audit store, set of collectors, and audited computers.
You can configure the scope of an audit store by adding or removing Active Directory sites or subnets.
To configure the scope for an audit store:

2. Expand the installation node, then expand Audit Stores and select a specific audit store name.
3. Right-click, then select Properties.
4. Click the Scope tab.
5. Click Add Site to select an Active Directory site from the list of sites found or click Add Subnet to type a specific subnet address and mask.
Configuring Permissions for an Audit Store
If you are the Master Auditor or have Change Permission rights, you can modify the rights granted to Active Directory users or groups. When you enable rights
for designated users and groups, you make them “trustees” with permission to perform specific operations.
To configure permissions for managing the audit store:
3. Right-click, then select Properties.
5. Click A d d to add Active Directory users or groups to the list of trustees who granted any type of rights on this audit store.
Select this
permission
Full Control All operations on the audit store.
Change
Modify permissions on this audit store.
Permissions
Select this
permission
Modify
Modify display name for this audit store.
Name
Manage
Add a subnet or Active Directory site to the audit store. Remove a subnet or Active Directory site from the audit store.
Scopes
Manage SQL Set the allowed incoming collectors for this audit store’s databases. Set the allowed incoming management databases for this audit store’s
Logins databases.
Manage Enable a trusted group of collectors for this audit store. Add a collector to the trusted group of collector in this audit store. Remove collector
Collectors from the trusted collectors in this audit store. Remove disconnected collector records from this audit store.
Manage Enable trusted group of audited computers for this audit store. Add a computer to the trusted group of audited computers in this audit store.
Audited Remove a computer from the trusted group of audited computers in this audit store. Remove disconnected audited computer records from
Systems this audit store.
Manage Add audit store databases to this audit store. Attach audit store databases to this audit store. Detach an audit store database from this audit
Databases store. Change the active database in this audit store. Modify the display name of an audit store database.
Manage
Database Enable or disable database trace. Export database trace.
Trace
Managing Audit Store Databases
During the initial deployment, your installation only has one audit store database. As you begin collecting audit data, however, that database can quickly
increase in size and degrade performance. Over time, an installation typically requires several Microsoft SQL Server databases to store the data being
captured and historical records of session activity, login and role change events, and other information. As part of managing an installation, you must manage
these databases to prevent overloading any one database and to avoid corrupting or losing data that you want to keep.
One of the biggest challenges in preparing and managing Microsoft SQL Server databases for storing audit data is that it is difficult to estimate the level of
activity and how much data will need to be stored. There are several factors to consider that affect how you configure Microsoft SQL Server databases for
auditing data, including the recovery method, memory allocation, and your backup and archiving policies.
For more complete information about managing and configuring SQL Server, however, you should refer to your Microsoft SQL Server documentation.
Selecting a Recovery Model
Standard backup and restore procedures come in three recovery models:
Simple—The simple recovery model allows high-performance bulk copy operations, minimizes the disk space required, and requires the least
administration. The simple recovery model does not provide transaction log backups, so you can only recover data to the point of the most recent full or
differential backup. The default recovery model is simple, but is not appropriate in cases where the loss of recent changes is not acceptable.
Full—The full recovery model has no work-loss exposure, limits log loss to changes since the most recent log backup, and provides recovery to an
arbitrary time point. However, the full recovery model uses much more disk space.
Bulk-logged—The bulk-logged recovery model provides higher performance and minimizes the log space used by disk-intensive operations, such as
create index or bulk copy. With the bulk-logged recovery model, you can only recover data to the point of the most recent full or differential backup.
However, because most databases undergo periods of bulk loading or index creation, you can switch between bulk-logged and full recovery models to
minimize the disk space used to log bulk operations.
When a database is created, it has the same recovery model as the model database. Although the simple recovery model is the default, the full and bulk-
logged recovery models provide the greatest protection for data, and the full recovery model provides the most flexibility for recovering databases to an
earlier point in time. To change the recovery model for a database, use the ALTER DATABASE statement with a RECOVERY clause.
Regardless of the recovery model you choose, you should keep in mind that backup, restore, and archive operations involve heavy disk I/O activity. You should
schedule these operations to take place in off-peak hours. If you use the simple recovery model, you should set the backup schedule long enough to prevent
backup operations from affecting production work, but short enough to prevent the loss of significant amounts of data.
Configuring the Maximum Memory for Audit Store Databases
Because Microsoft SQL Server uses physical memory to hold database information for fast query results, you should use a dedicated instance to store
auditing data. Because SQL Server dynamically acquires memory whenever it needs it until it reaches the maximum server memory you have configured, you
should set constraints on how much physical memory it should be allowed to consume.
The maximum server memory (max server memory) setting controls the maximum amount of physical memory that can be consumed by the Microsoft SQL
Server buffer pool. The default value for this setting is such a high number that the default maximum server memory is virtually unlimited. Because of this
default value, SQL Server will try to consume as much memory as possible to improve query performance by caching data in memory.
Processes that run outside SQL Server, such as operating system processes, thread stacks, socket connections and Common Language Runtime (CLR)
stored procedures are not allowed to use the memory allocated to the Microsoft SQL Server buffer pool. Because those other processes can only use the
remaining available memory, they might not have enough physical memory to perform their operations. In most casts, the lack of physical memory forces the
operating system to read and write to disk frequently and reduces overall performance.
To prevent Microsoft SQL Server from consuming too much memory, you can use the following formula to determine the recommended maximum server
memory:
Reserve 4GB from the first 16GB of RAM and then 1GB from each additional 8GB of RAM for the operating system and other applications.
Configure the remaining memory as the maximum server memory allocated for the Microsoft SQL Server buffer pool.
For example, if the computer hosting the Microsoft SQL Server instance has 32GB of total physical memory, you would reserve 4 GB (from first 16 GB) + 1GB
(from next 8 GB) + 1 GB (from next 8 GB) for the operating system, then set the Maximum server memory for Microsoft SQL server to 26 GB (32 GB – 4 GB – 1
GB – 1 GB = 26).
For more information about how to configure Microsoft SQL Server maximum memory setting and other memory options, see the following Microsoft article:
https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms178067(v=sql.105)
You should configure the maximum memory allowed for the Microsoft SQL Server instances hosting audit store databases and the management database.
However, this setting is especially important to configure on the Microsoft SQL Server instance hosting the active audit store database.
Using Transact-SQL to Configure Minimum and Maximum Memory
You can control the minimum and maximum memory that the SQL Server buffer manager uses by issuing Transact-SQL commands. For example:
sp_configure ‘show advanced options’, 1

reconfigure
go
sp_configure ‘min server memory’, 60
reconfigure
go
sp_configure ‘max server memory’, 100
reconfigure
go
For more information about configuring SQL Server and setting minimum and maximum server memory using T-SQL, see https://docs.microsoft.com/en-
us/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-2017
Estimating Database Requirements Based on the Data you Collect
To determine how audit and monitoring service will affect database capacity, you should monitor a pilot deployment of 20 to 25 agents with representative
activity to see how much data is produced daily. For example, some audited computers might have few interactive user sessions or only short periods of
activity. Other audited computers might have many interactive user sessions or long sessions of activity on average.
During the pilot deployment, you want to the following information:
How many interactive user sessions occur daily on each computer?

How long do sessions last on average?
What are the activities being captured, and what is the average size of each session being captured?
How long do you need to store the captured data to balance performance and storage?
What is the data retention period for audited data?
From the information you collect in the pilot deployment and the data retention policy for your organization, you can estimate the database size using the
following guideline:
For example, if an average session generated 100 KB in the database and the installation had 250 agents, 10 sessions per agent, and a six-month retention
period (about 130 working days), the storage requirement for the audit store database would be 36.9 GB:
250 agents x 10 sessions/agent each day x 100 KB/session x 130 days = 32,500,000 KB
The following table shows examples of the data storage requirement in an installation with Windows agents, typical levels of activity with an average of one
session per day on each audited computer, and the recovery mode set to Simple:
Agents Average session length Average session size Daily Weekly 6 Months
100 20 minutes 806 KB - low activity 79 MB 394 MB 10 GB
50 25 minutes 11.56 MB - high activity 578 MB 2.81 GB 73.36 GB
100 20 minutes 9.05 MB - high activity 905 MB 4.42 GB 115 GB
In this example, an installation with 100 Windows agents with low activity would require approximately 10 GB for the audit store database to keep audit data
for 6 months. An increase in the number of interactive sessions, session length, or average session size would increase the database storage required.
If SQL Server requires more space to accommodate the new data, it expands the database file immediately, which can cause degraded performance. To
reduce the effect of database expansion on performance, allocate sufficient space to support database growth. In addition, monitor database space and
when space is low, schedule a database expand operation for an off-peak time.
Adding New Audit Store Databases to an Installation
When you first set up an installation, you also create the first audit store and audit store database. By default, that first database is the active database. As
you begin collecting audit data, you might want to add databases to the audit store to support a rolling data retention policy and to prevent any one database
from becoming a bottleneck and degrading performance.
Only one database can be the active database in an audit store at any given time. The computer hosting the active database should be optimized for
read/write performance. As you add databases, you can change the older database from active to attached. Attached databases are only used for querying
stored information and can use lower cost storage options.
Note: {/b}A single instance of Microsoft SQL Server can host multiple databases.
Audit store databases have the following characteristics:
A database can be active, attached, or detached.

Only one database can be actively receiving audit data from collectors.
A database cannot be detached while it is the active database.
A database that was previously the active database cannot again be the active database.
If a detached database contains parts of sessions presented to the Audit Analyzer, a warning is displayed when the auditor replays those sessions.
Rotating the Active Database
Database rotation is a management policy to help you control the size of the audit store database and the performance of database operations. There are
several reasons to do database rotation:
It is more difficult to manage one large database than multiple small databases.
Performance is better with multiple small databases.
Backing up, restoring, archiving, and deleting data all take significantly more time if you work with one large database.
Database operations take very little time when you work with multiple small databases.
For audit and monitoring service, you can implement a database rotation policy by having the collector write data to a new database after a certain period of
time. For example, the collector in site A writes data to the database siteA-2014-11 in November, then write data to database siteA-2014-12 in December and
to the database siteA-2015-01 in January. By rotating from one active database to another, each database stays more compact and manageable.
Creating a New Database for Rotation
You can rotate from one active database to another at any time using the Audit Manager console.
To create a new database for rotation:

2. Expand the installation node, then expand Audit Stores and a specific audit store name.
3. Select Databases, right-click, then select Add Audit Store Database to create a new database.
4. Select the Set as Active database option so collectors start writing to the newly created database.
It is possible to write a script to automate the database rotation process. For details, see the SDK documentation.
Database Archiving
To implement periodic archiving, add a new active database, leave one or more previous databases attached, and take the oldest database off-line for
archiving.
Queries During Rotation and Archiving
If the database backup program supports online backup, the Audit Analyzer can still query the database while the backup is in progress. However, the backup
program may block updates to the session review status. If the backup program does not support online backup, the database will be offline until the backup
is complete.
Database Backups
You can back up a database whether it is attached to the audit store or detached from the audit store.
Allowed Incoming Accounts
You can specify the accounts that are allowed to access the audit store database. By configuring these accounts, you can control which collector computers
can connect to the audit store database and which management databases have access to the data stored in the audit store database.
Your account must have Manage SQL Login permission to configure the incoming accounts.
To configure allowed accounts:
3. Select a database under the audit store, right-click, then select Properties.
5. Click A d d to add a collector or management database account. For example:
![alt](images/8d96b4edb390e2b9de495a3a7399d708.png "Add Collector or Management Database Account)
6. Select an authentication type.
If you select Windows authentication, you can browse to select a computer, user, or group to add.
If you select SQL Server authentication, you can select an existing SQL Server login or create a new login.
Connections should use Windows authentication whenever possible. However, computers in an untrusted forest cannot connect to an audit management
database using Windows authentication. To allow connections from an untrusted forest, add a SQL Server login account as the incoming account for the
Managing the Management Database
The audit management database keeps track of where components are installed and information about the installation. To connect to the database or
manage its properties, select a specific installation name in Audit Manager, right-click, then select Management Databases.
Configuring the Scope of the Management Database
The audit management database stores information about the set of Active Directory sites or subnets it supports. You can modify the scope of the
management database if you are auditing computers in a large and widely distributed network or have multiple Active Directory sites with computers you
want to audit.
To configure the scope for a management database:

2. Select the installation name, right-click, then select Management Database.
3. Click Properties, then click the Scope tab.
4. Click Add Site to select an Active Directory site from the list of sites found or click Add Subnet to type a specific subnet address and mask.
Configuring Permissions for the Management Database
If you are the Master Auditor or have Change Permission rights, you can modify the rights granted to Active Directory users or groups. When you enable rights
for designated users and groups, you make them “trustees” with permission to perform specific operations.
To configure audit store security:
2. Select the installation name, right-click, then select Management Database.
3. Click Properties.
5. Click A d d to add Active Directory users or groups to the list of trustees who granted any type of rights on this management database.
Select this
permission
Full Control All operations on the management database.
Change
Modify permissions on the management database.
Permissions
Modify Name Modify display name for this management database.
Add a subnet or Active Directory site to the management database. Remove a subnet or Active Directory site from the management
Manage Scopes
database.
Set the allowed incoming accounts for the management database. Database owner is by definition an allowed user. Set the outgoing
Manage SQL Logins
account for the management database.
Remove Database Remove this audit management database from the installation.
Manage Database
Enable or disable database trace. Export database trace.
Trace
Managing Collectors
You can view information about the collectors you have deployed in the Audit Manager console. For example, for each collector, you can see the location of
the collector on the network, whether the collector is connected to or disconnected from the audit store, and how long a connected collector has been
running since it was last restarted, the audit store to which the collector is assigned, and the active database to which the collector is currently sending audit
data. You can also see the audited computers that currently connected to each collector and the audited computers that are not currently connected to this
collector.
If you install the collector service on a computer but it has never connected to any agents or audit stores, it is not included in collector list on the Audit
Manager console.
Monitoring Collector Status Locally
In addition to the information available in the Audit Manager console, the Windows computers on which you have installed a collector provide a local Collector
Control Panel applet. The Collector Control Panel displays information about current connectivity and status for the local collector. You can use the control
panel to configure the collector port number, installation, and authentication type if you want to make changes after the initial deployment. You can also use
the control panel to start, stop, or restart the collector service, and to generate diagnostic information about the collector.
1. Log on to the computer on which you have installed a collector.
2. In the list of applications on the Windows Start menu, click Audit Collector Control Panel to open the audit collector control panel.
3. On the General tab, click Configure to change the port number, installation, or type of authentication to use when connecting to the audit store.
The General tab also displays current configuration and status for the local collector service. If you make changes, the new information is displayed
after a short period of time.
4. Click S t o p if you want to temporarily stop a running service, or Restart if you want to stop and immediately restart a running collector service.
5. Click the Troubleshooting tab, then click Diagnostics to generate diagnostic information about the installation the collector is part of, the Active
Directory site or subnets associated with the audit store the collector connects to, the collector status, and other information. For example:
After you generate diagnostic information, you can right-click to select all of the text. With the text selected, right-click, and select Copy to copy and
paste the diagnostic report into a text file.
6. Click Options to specify the level of detail to include in the log file or to turn off logging.
The default log level reports informational messages, warnings, and errors. You can click View Log to see information in the current log file.
Removing Collectors
If you want to remove a collector, you can use the Programs and Features > Uninstall a program control panel or the setup program you used to install the
collector.
If you run the setup program, select the collector from the list of components, then click Next. Because a collector is installed, the wizard prompts you the
Change, Repair or Remove the collector. Click Remove.
Managing Audited Computers and Agents
You can see information about audited computers and the audit and monitoring service status of Agents for Windows using the Audit Manager console. For
example, for each audited computer, you can see the computer name and IP address, whether the audited agent is currently connected or disconnected, and
how long the agent has been running since it was last restarted. You can also see the collector to which the agent is sending data and the audit store and audit
store database where the audit data is stored.
Monitoring Agent Status Locally
In addition to the information available in the Audit Manager console, the Windows computers on which you have installed a Agent for Windows with audit and
monitoring service enabled include a local agent configuration panel applet. The agent configuration panel displays information about current connectivity
and status for the local agent. You can use the agent configuration panel to configure the color depth, offline storage, or installation if you want to make
changes after the initial deployment. You can also use the agent configuration panel to generate diagnostic information about the agent.
To use the agent configuration panel:
1. Log on to the computer on which you have installed a Agent for Windows with audit and monitoring service enabled.
2. In the list of applications on the Windows Start menu, click Agent Configuration to open the agent configuration panel.
3. Click Auditing and Monitoring Service.
4. Click Settings.
5. On the General tab, click Configure to change the color depth, offline storage file location and maximum size, and the installation to use for the local
agent.
Note:The offline storage location should be an empty folder. If you select a folder that contains any files other than the spooled audit data,
those files may be moved or lost.
The General tab also displays current configuration and status for the local agent. If you make changes to the configuration, the new information is
displayed after a short period of time. If the agent cannot connect to any collector, it spools audit data to the offline data location. When it finds a
collector, the agent sends the spooled data to it. The offline storage space is not reclaimed until all of the spooled data has been sent to a collector.
6. Click the Troubleshooting tab, then click Diagnostics to generate diagnostic information about the installation the agent is part of, the collector the
agent sends data to, the size of offline storage, and other information. For example:
After you generate diagnostic information, you can right-click to select all of the text. With the text selected, right-click, and select Copy to copy and
paste the diagnostic report into a text file.
7. Click Options to specify the level of detail to include in the log file or to turn off logging.
The default log level reports informational messages, warnings, and errors. You can click View Log to see information in the current log file.
Setting the Color Depth for Captured Sessions
Because audit and monitoring service captures user activity as video, you can configure the color depth of the sessions to control the size of data that must
be transferred over the network and stored in the database. A higher color depth also increases the CPU overhead on audited computers but improves
resolution when the session is played back. A lower color depth decreases the amount of data sent across the network and stored in the database. In most
cases, the recommended color depth is medium (16 bit). The CPU and storage estimates in this guide are based on a medium (16 bit) color depth.
To change the color depth for captured sessions:
1. Log on to the computer where the Agent for Windows is installed.

3. Click Auditing and Monitoring Service.
4. Click Settings.
5. On the General tab, click Configure
7. Follow the prompts displayed to change any other configuration settings.
Removing an Audited Computer
If an audited computer has been removed from the installation, the audited computer will continue to be listed on the Audit Manager console as
Disconnected. To remove the decommissioned audited computer, select Delete from its context menu.
Adding an Installation
Although a single installation is the most common deployment scenario, you can configure multiple installations. For example, you can use separate
installations to provide concurrent production and test-bed deployments or to support multiple administrative domains within your organization.
To create a new installation:
2. Select the root node, right-click, then select New Installation.
3. Follow the prompts displayed.
The steps are the same as the first installation. For more information, see Creating a new installation.
4. Choose the appropriate installation for each collector using the Collector Configuration wizard.
5. Choose the appropriate installation for each agent using the Agent Configuration wizard.
Delegating Administrative Tasks for a New Installation
The account you use to create a new installation is the default administrator and Master Auditor with full control over the entire installation and the ability to
delegate administration tasks to other Active Directory users or groups. You can grant permission to perform administrative tasks to other users by opening
the Properties for each component, then clicking the Security tab.
Opening an Installation in a New Console
If you create multiple installations at the same site, you can select the installation name, right-click, then select New Window From Here to keep consoles
for different installations separate from each other. Creating a new window for each installation can help you avoid performing operations on one installation
that you intended to perform on another.
Closing an Installation
The Audit Manager console allows you to manage multiple installations. To remove the current installation from the console, but not physically remove the
database or the information published to Active Directory, you can select the installation name, right-click, then select Close.
Publishing Installation Information
DirectManage Audit publishes installation information to a service connection point (SCP) object in Active Directory so that audited computers and
collectors can look up the information. If the published locations for multiple SCPs in the same installation are not the same, or if collectors cannot read from
at least one of the published locations, the collectors are unable to determine which audit store is the best match for the sites and subnets, and so they do not
attempt to connect to an audit store.
Permission to publish to Active Directory
Only administrators who have been delegated permission to modify various attributes of the installation can publish those attributes to Active Directory.
If you do not have Active Directory permission to modify the installation, the updates are kept in the audit management database, and a message is issued to
notify you that the installation information could not be updated in Active Directory.
Synchronizing Installation Information
If you have an Active Directory account with permission to publish information about the installation, you can update the service connection point.
To publish the service connection point for an installation:
3. Click the Publication tab, then click Synchronize to publish the information.
In a multi-forest or DMZ environment, this tab lists multiple Active Directory locations to which to publish.
4. Click O K to close the installation properties.
Removing or Deleting an Installation
Before you can remove or delete an installation, you must do the following:
Run the setup program to remove all agents and collectors and collector service connection points (SCPs).
Detach and remove all audit store databases.
Open the Installation Properties and click the Publications tab to make sure only one installation service connection point (SCP) is listed.
Note: {/b}To remove service connection points on other sites, contact an administrator with publication permission on those sites.
To remove or delete an installation, select the installation in the Audit Manager console, right-click, then select Remove to open the Remove installation
dialog box.
Click Remove to remove the installation but not delete the management database from the SQL Server instance.
Click Delete to remove the installation and delete the management database from the installation of SQL Server.
Note:All the publications published to Active Directory are removed when you remove or delete an installation.
Delinea software includes diagnostic tools and log files to help you trace the source of problems if they occur. Diagnostic reports and log files allow you to
periodically check for issues and view information about operations on the computers you manage. The information is useful for troubleshooting and in
resolving cases with the help of Delinea Support.
This chapter describes how to find log files, set the level of detail recorded in log files, and use diagnostic tools to retrieve information about the operation of
the Agent and Server Suite components. This chapter also covers common questions to help you identify and correct problems on the computers you
manage.
Solving Problems with Logging On
After you have installed the Agent for Windows and joined the computer to a domain, users cannot log on without a role assignment. The role, however, can be
assigned to a local account or a domain account, or the role can be assigned the right to access a remote computer. Consequently, users might encounter
problems logging on after the agent is deployed. For example, you might find that users can log on to the computer using a local account but cannot log on
using their domain account or have trouble connecting to a remote server.
If users report problems logging on, there are some things you can try to troubleshoot the issue:
Check the logon rights for the affected users.
To do this, log on as an administrator and execute dzinfo user-name (where user-name is the name of the user experiencing problems logging on). You
can also check user logon rights using the Authorization Center.
Try to log on using a local user account or using a different domain account if you have more than one account available.
Determine whether the computer you are using is connected or disconnected from the network. In rare cases, authorization information might not be
available when a computer disconnected from the network.
If users cannot log on to a remote computer, confirm that they have a role that has the remote logon system right and that the computer itself is
configured to allow users to log on remotely. Open the Authorization Center to review the list of roles and their associated rights for any user.
Check the computer’s local security policy or applied group policies to verify whether the user is allowed to log on interactively or through a remote
desktop connection. For example, most domain users are not allowed to log on locally on domain controllers.
Depending on how your organization has configured native Windows security policies, users might need to be members of a specific Windows security
group—such as Server Operators or Remote Desktop Users—to log on to specific computers locally or remotely even if they have been granted access
rights using the Windows Login role or a custom role definition.
Check to see whether the computer is in Rescue mode.
In Rescue mode, access to a computer is granted only to users who have Rescue rights. For information about adding Rescue rights to a role, see
System rights allow users to log on. In general, a computer enters Rescue mode because the Windows agent authorization service has stopped.
Possible causes include the following:
The computer is not connected and the local authorization cache has not been initialized or is corrupt.
The local authorization cache cannot be updated because the file system is full.
See Working with the authorization cache on managed computers for more
information about the authorization cache and the conditions under which
a computer is considered to be not connected.
Accessing Network Computers with Privileges
Depending on how you have defined the roles users are assigned, it is possible for users to see potentially misleading information in certain applications or be
unable to perform the administrative tasks as they expect. For example, if users select a role with administrative privileges to access an application such as
SQL Server Configuration Manager or Microsoft SQL Server Management Studio and connect to a remote SQL Server instances, it might appear as if they
have permission to start and stop services or perform other tasks. However, if the role does not include network access rights for the remote SQL Server
instance, users will not have the appropriate permission to perform those tasks.
You can check whether the selected role includes network access rights using the Authorization Center. If the role being used does not include network
access rights, check whether the user has additional network roles available to use in conjunction with the local role. If the role being used includes network
access rights, you should check whether those rights are applicable on the network computer the user is attempting to manage. Users must be assigned to
the role that has network access rights on the remote server.
Refreshing Cached Information on Managed Computers
Authorization information is cached on the local computer to improve performance and to allow the use of elevated privileges even if users are disconnected
from the network. If you make changes to rights, role definitions, or role assignments, you can refresh the information stored in the cache on managed
computers to ensure the agent has the most up-to-date information about current rights and roles. If users are experiencing authorization problems or issues
with their access rights (for example, if the management console shows that a user has logon rights, but dzinfo or the authorization center does not show
that the user has logon rights), you should try refreshing the cache to make sure any changes you have made take effect.
You can refresh the cache using agent configuration panel or the dzrefresh command line program in a Command Prompt window if you have the appropriate
permissions.
Analyzing Information in Active Directory
One important way you can troubleshoot your environment is by running the Analyze command. The Analyze command enables you to selectively check the
integrity of information stored in Active Directory. With the Analyze wizard, you can check for a variety of potential problems, such as empty zones, invalid
role assignments, or orphaned role assignments.
Note: When you run the Analyze command, only the zones that are open are checked.
To check for problems in the Active Directory forest:
If you are prompted to connect to a forest, specify the forest domain or domain controller to which you want to connect.
2. Select the root node, right-click, then click Analyze.
3. Select the types of checks you want to perform, then click Next to generate the report.
You can select All to perform a complete check of the Active Directory forest. However, some of the analysis options are only applicable for Linux and
UNIX computers or UNIX user and group profiles. For more information about any analysis option, see the Access Manager help or the Administrator’s
Guide for Linux and UNIX.
4. Review the result summary, then click Finish.
5. If the result summary indicates any issues, you can view the details by selecting Analysis Results in the console tree and viewing the information
listed in the right pane.
6. Select individual warnings or errors, right-click, then select Properties for additional information.
Common Scenarios that Generate Errors and Warnings
For most organizations, it is appropriate to check the data integrity of the Active Directory forest on a regular basis. Although running the Analyze command
frequently may not be necessary for small networks with few domain controllers, there are several common scenarios that you should consider to determine
how often you should check the forest for potential problems.
The most likely reasons for data integrity issues stem from:
Multiple administrators performing concurrent operations.

Administrators using different domain controllers to perform a single operation.
Replication delays that allow duplicate or conflicting information to be saved in Active Directory.
Insufficient permissions that prevent an operation from being successfully completed.
Network problems that prevent an operation from being successfully completed.
Partial or incomplete upgrades that result in inconsistency of the information stored in Active Directory.
Using scripts or ADSI Edit rather than the console to create, modify, or delete objects in Active Directory, which may lead to corrupted or invalid
information.
Running Analyze periodically helps to ensure that the scenarios that can cause problems are reported in the Analysis Results, enabling you to take corrective
action.
Responding to Errors and Warnings
Depending on the type of warning or error generated in the Analysis Results, you might be able to take corrective action or access additional information. For
example, if a computer account lacks the necessary permission to update Active Directory with the agent version it has currently installed, the Analysis
Result will enable you to update the computer’s account permissions to allow changes to that attribute.
To review additional information or take corrective action, select the error or warning in the list of Analysis Results after running the Analyze wizard, right-
click, then select Properties. For more information about responding to analysis results, see the Access Manager help or the Administrator’s Guide for Linux
and UNIX.
Running Diagnostics and Viewing Logs for the Agent
The Agent for Windows provides logging and diagnostic services. If you have administrative access on a local computer, you can generate diagnostic
information about the operation of the Agent for Windows and view and save the current content of the log file from the agent configuration panel. For
example, you can generate diagnostic information about user sessions, user roles, desktops, and elevated account access, as well as detailed information
about auditing from the agent configuration panel.
There are three different types of diagnostics information available:
Audit & Monitoring Service provides the diagnostic information related to the auditing and monitoring service.
Identity Platform provides the diagnostic information related to Privileged Access Service, such as for MFA. This diagnostics tool runs the following
tests:
Agent Service Connectivity Check: Checks to see if the agent is in service, and if the agent is running in a normal state. Also determines
whether the agent is in a zone, or is configured to use zoneless mode.
Connector Connectivity Check: Determines whether all connectors in the network can be connected properly. whether the certificates
(IWA and cloud) have been installed properly. Also determines whether the agent can be connected without a trusted certificate problem.
Identity Platform Connectivity Check: Determines whether a connection to the cloud tenant is functional. Checks for problems with DNS,
the firewall, and proxy server settings.
MFA Configuration Check: Determines whether the local computer has been configured properly. If the computer is in a zone, the test also
checks whether MFA complies with the configuration defined in the zone.
MFA Role and Permission Check: Verifies whether role permissions are set properly in the Privileged Access Service Admin Portal.
Offline MFA Provisioning Check: Determines if the computer has been configured with an offline MFA profile or not.
Privilege Elevation Service provides the diagnostic information related to privilege management.
You can view these diagnostics tools either from the Windows system tray or from the agent configuration panel.
To view diagnostics from the Windows system tray:
1. Log on to a computer where the Agent for Windows is installed.

2. In the Windows system tray, right-click the Delinea icon and click Troubleshooting, then select the service for which you want to view diagnostic
information (your options may vary depending on what services are enabled on the computer):
Audit & Monitoring Service opens a dialog box with a text-based summary of diagnostic auditing and monitoring information.
Identity Platform runs a series of connectivity tests and lists out the results of each test.
Privilege Elevation Service opens a dialog box with a text-based summary of diagnostic privilege elevation information.
To generate diagnostics or view the log file from the agent configuration panel:

3. Select the service for which you want to view information:
Audit & Monitoring Service opens a dialog box with a text-based summary of diagnostic auditing and monitoring information.
Identity Platform runs a series of connectivity tests and lists out the results of each test.
Privilege Elevation Service opens a dialog box with a text-based summary of diagnostic privilege elevation information.
4. Click Settings.
6. Click Diagnostics to generate diagnostic information.
7. Select the Diagnostic Information displayed, right-click, then select C o p y to copy and paste the output to a file for further analysis.
8. Click View Log to display the current log file for the local agent.
9. Click Options to see or change the location of the log file or the level of detail recorded in the log file.
Sample Diagnostic Report
For example, if you are viewing information about the privilege elevation service, the diagnostic report might be similar to this:
Product: Infrastructure Services (Name and Version information)

Computer: DC2008R2-LG
Joined Domain: finsterwald.org
Zone: finsterwald.org/Acme Pubs/Zones/HeadquartersAgent State: Connected
Time: 2017-10-16 12:38:03.620 -08:00
Session information:
Session 1
SAM Name: FINSTERWALD\anton.splieth
Logon Type: Console
Always Audit: Yes
Desktops:
Default
GUID: de1dd94a-b671-4b37-baa4-9b2c1b70e776
DZ Logon Id: (0x0)
Local Role: Self
Network Roles: Self
Always Audit: Yes
Audit Flag: On
UAC Restrictions: No
SQL-DBA
GUID: fccb2382-3800-4f3c-9569-922048f91375
DZ Logon Id: (0x9ba99)
Local Role: SQL-DBA/Headquarters
Network Roles: Self
Always Audit: Yes
Audit Flag: On
Network Drives: No
Logon information:
Logon ID (0x9ba99)
Logon GUID: 38407dd1-0165-458e-b45d-686a07e87805
Base Logon ID: (0x77163)
Base SAM Name: FINSTERWALD\anton.splieth
ElevatedAccount: (ElevatedSelfAccount, AdditionalGroups=(count=1, items=(S-1-5-32-544)))
Network Roles: None
Should Audit: Yes
Logon ID (0x22bfee)
Logon GUID: 1b50b739-461c-410e-803c-ed52d4ba1e80
Base Logon ID: (0x77163)
Base SAM Name: FINSTERWALD\anton.splieth
Network Roles: None
Should Audit: Yes
Domain last access information:

Forest finsterwald.org: Connected
Domains: finsterwald.org: Connected
Multi-factor Authentication information: None
Done.
Enabling Detailed Logging for Audit and Monitoring Service Components
In addition to the log files for the Agent for Windows, there are log files for other audit and monitoring service components to record information about
operations performed by those components on a local computer. If you have audit and monitoring service components installed, you can view the log files or
change log file options for those components to assist Delinea Support when troubleshooting issues.
Enabling Detailed Logging for an Audited Computer
If you are troubleshooting an audit and monitoring service-related issue, you should enable detailed logging for the audit and monitoring service service on
the computers being audited. For Windows computers, you can enable detailed logging using the agent configuration panel.
To enable detailed logging on an audited computer:
1. Log on to an audited computer.
3. Click Audit & Monitoring Service.
4. Click Settings.
6. Click Options, change the logging level to Trace messages, then click O K.
7. Note the log folder location or click Browse to specify a different location for the log file, then click O K.
8. Click View Log to view the current log file.
From the log file window, you can also click File > Save As to save the log file.
9. Send an email to Delinea Support with the log file from the location specified in Step 7 as an attachment.
10. Click Options, change the logging level back to its default setting of Informational messages, then click O K.
Enabling Detailed Logging for the Collector Service
If you are troubleshooting an audit and monitoring service-related issue, you should enable detailed logging for the collector service on the computers where
the collector service runs.
To enable detailed logging on a collector:
1. In the list of applications on the Windows Start menu, click Audit Collector Control Panel to open the audit collector control panel.
3. Click Options, change the logging level to Trace messages, then click Apply.
5. Click View Log to view the current log file.
From the log file window, you can also click File > Save As to save the log file.
7. Click Options, change the logging level back to its default setting of Informational messages, then click O K.
8. Click Close to return to the Collector Control Panel.
Enabling Detailed Logging for Audit and Monitoring Service Consoles
In most cases, troubleshooting audit and monitoring service-related issues requires information about the operation of the agent and the collector or
database activity. However, in some cases, it might be necessary to capture detailed information about the operation of Audit Manager or Audit Analyzer.
To capture detailed information for Audit Manager or Audit Analyzer:
1. Log on to a computer where the Audit Manager or Audit Analyzer console is installed.
3. Click Audit & Monitoring Service.
4. Click Settings.
6. Click Options.
7. In the Log Settings tab, change the logging level to Trace messages, then click O K.
10. Click Options, change the logging level back to its default setting of Warning messages, then click O K.
Enabling Audit and Monitoring Service Performance Counters for the Collector
If you have enabled audit and monitoring service and installed the collector service on a local Windows computer, you can add audit-specific performance
counters to Performance Monitor to help you analyze and resolve audit-related issues. When you install the collector, the performance counters are added
automatically. When you uninstall the collector, the counters are automatically removed from Performance Monitor.
For more information about troubleshooting in an audit installation, see the Auditing Administrator’s Guide.
Tracking Database Activity
Database traces are used to help diagnose problems in the management database or audit store databases. For example, database traces can help to
identify inconsistencies caused by hardware errors or network interruptions. After you enable database tracing, DirectManage Audit tracks all of the SQL
statements and debug messages from the audit management database or audit store, and records the information in the database server.
Note: Tracing database operations affects database performance. You should only activate a database trace if you require this information for
troubleshooting. Before you start a database trace, try to reduce the load on the database instance as much as possible, then only perform the
actions needed to reproduce the issue you are troubleshooting. Turn off database tracing as soon as you have logged the activity you need for the
analysis of database operations. The trace for each database can take up to 800MB of server disk space. After you turn off database tracing,
restart the SQL Server instance to reset the disk space.
Starting a Database Trace
You can start a database trace for a management database or an audit store database.
To start database tracing:
2. Select an installation name, right-click, then click Properties.
3. Click the Database Trace tab.
This tab displays basic information about the management databases and audit store databases for the selected installation. In the Trace Status
column, you can see whether tracing is enabled or disabled for each database.
4. Select a management or audit store database in the list, then click Enable to start tracing on the database selected.
5. Click O K, then perform the database actions for which you want to capture information.
Stopping the Database Trace
You should turn off database tracing immediately after you have logged the activity you need for the analysis of database operations.
To stop database tracing:

3. Click the Database Trace tab.
4. Select the management or audit store database that has tracing enabled, then click Disable to stop tracing on the database selected.
5. Click Export to save the database trace from the selected databases to a file with comma-separated values (.csv).
6. Follow the prompts displayed in the Export Database Trace wizard to save the information to a file.
Exporting the Database Trace for a Management Database
The Export Database Trace wizard prompts you for different information depending on whether the database trace is for a management database or an audit
store database. For example, if you generate a database trace for a management database then click Export, the Export Database Trace wizard prompts
you for user accounts.
To export the database trace:
1. Select a start date and time for the From filter and an end date and time for the T o filter, then click Next.
2. Click A d d to search for and select users, then click Next.
By default, you can search for users in the entire directory, you can click Object Types or Locations to change the scope of the search scope, or click
Advanced specify other criteria.
3. Accept the default folder location or click Browse to select a different location, then click Next.
4. Review your selections, then click Next.
By default, the wizard save the file as installation_name.csv and opens the file location.
5. Click Finish, then click O K to close the installation properties.
Exporting the Database Trace for Audit Store Databases
When you select an audit store from the lower area of the Database Trace tab on the Properties page and click the lower Export button, the wizard
opens with a date/time Export Criteria page. On the second page, the wizard asks you to pick the domain and computer.
To export the database trace:
1. Select a start date and time for the From filter and an end date and time for the T o filter, then click Next.
2. Click A d d to search for and select collectors, then click Next.
By default, you can search for computers in the entire directory, you can click Object Types or Locations to change the scope of the search scope,
or click Advanced specify other criteria.
3. Click A d d to search for and select management database computers, then click Next.
4. Accept the default folder location or click Browse to select a different location, then click Next.
5. Review your selections, then click Next.
By default, the wizard save the file as audit_store_name.csv and opens the file location.
6. Click Finish, then click O K to close the installation properties.
Delegating Database Trace Management
You can delegate the authority to manage database tracing by granting the Manage Database Trace permission to other users for a management database
or an audit store database.
Controlling Audit Trail Events
By default, audit trail events are recorded when users log on, open applications, select roles that elevate their privileges, and perform other tasks. You can use
domain group policies to control the global location of the audit trail events. For example, you might want to store audit trail events in the audit store database
instead of the Windows event Application log if you want to make them available for querying and reports.
You can also override domain group policy and configure local or category-specific audit trail targets using a local administrative template or group policy.
To configure global or per-category audit trail targets using an ADM administrative template:
Note: These settings override the settings defined in the Set global audit trail targets group policy.
1. Open the Group Policy Object Editor to display Local Computer Policy, and select Computer Configuration > Administrative Templates.
2. Right-click, select Add/Remove Templates, then click A d d.
3. Navigate to the AuditManager folder, select auditrail.adm, click O K, then click Close.
4. Open the Classic Administrative Templates folder and select AuditTrail.
5. Specify global or separate targets for audit trail events:
Enable Set global audit trail target settings to configure a single location for audit trail events for Access Manager and the Agents.
If you want to have separate targets for audit trail events, you can enable the other audit trail group policies to override the global policy setting
with a different target.
6. Specify the location for saving audit trail events, and then click O K:
0 to disable audit trail events
1 to store audit trail events in the audit store
2 to send audit trail events to the Windows event Application log
3 to send audit trail events to both the audit store and the Application log.
To configure per-category audit trail targets using a local group policy from an XML template:
Note: These settings override the settings defined in the Set global audit trail targets group policy.
1. Ensure that the Audit Trail Settings were updated with the most recent XML template.
2. Open the Group Policy Object Editor to display Local Computer Policy, and select Computer Configuration > Audit Trail Settings.
3. In Audit Trail Settings, separate folders for each audit trail category contain Send audit trail to Audit database and Send audit trail to log
file group policies. Enable these group policies in each category that you want to configure to use a specific audit trail target. The target that you
specify for each category is used instead of the target specified in the Set global audit trail targets group policy.
Summary of Audit Trail Events
Different components log different audit trail events. For example, the auditing and authorization services on a managed Windows computer track
successful logon attempts and the use of Window access rights. Access Manager audit trail events record changes to the configuration of zones, such as the
delegation of administrative tasks, the assignment of roles, and changes to the user and group profiles in a zone. For your reference, the following sections
summarize the audit trail events recorded by Agents on managed Windows computers.
Additional audit trail events for Access Manager, Audit Analyzer, Audit Manager, and UNIX commands can be recorded in the target you specify for the audit
trail. The event message provides detailed information about the operation performed or unsuccessfully attempted, including in most cases the reason the
operation was unsuccessfully.
For a complete list of audit trail event identifiers and their corresponding descriptions, see the AuditTrailEvent.xml file provided in the Documentation folder.
This file is generated directly from the underlying source code and provides the most up-to-date information about the events on which you can query and
report.
Offline MFA Profile Authentication
In some environments, using an offline MFA profile for multi-factor authentication is not compatible with FIPS mode. See the Multi-factor Authentication
Quick Start Guide for details about this restriction.
Authentication Service Known Issues
When troubleshooting, be aware of the following issues and constraints:
Import users and groups before importing the sudoers file (Ref: IN-90001).
Sudoers Import creates user roles but not the users. It is recommended that you import users and groups prior to importing the sudoers file. Otherwise,
no sysRights are created for the users.
Pre-create computers before importing computer role from sudoers file (Ref: IN-90001).
The computers contained in the sudoers file must either be joined to a zone or pre-created.
Delegating zone administration permissions for SFU zones (Ref: IN-90001)
Delegate permissions to add, remove or modify users for SFU zone are not supported.
Users with rights to import user and groups into a zone also gain rights to modify profiles (Ref: IN-90001)
Any users who are given the right to "Import users and groups to zone" are automatically also given the right to "Modify user/group profiles".
Using domain local groups to manage resources (Ref: IN-90001)
Domain local groups can only be used to manage resources in the same domain as the group. So, for instance, a domain local group in domain A may be
used to manage a computer in domain A but not one in domain B, despite a trust relationship between the two domains.
Domain local groups from other domains shown in search dialog (Ref: IN-90001)
When using the search dialog in the Access Manager to delegate zone control to a group, domain local groups from child domains will be shown
incorrectly in the results and should be ignored. The search results when using the ADUC extension do not show these domain local groups.
Analyze forest and SFU zones (Ref: IN-90001)
The analyze forest feature in the Access Manager does not report empty zones or duplicated users or groups in a SFU zone.
Working with users that have more than one UNIX mapping (Ref: IN-90001)
Authentication Service supports Active Directory users that have more than one UNIX profile in a zone. However, if you are upgrading from
DirectControl 4.x or earlier and have existing users with more than one UNIX mapping, you should use DirectControl 5.0.0 or later to remove all but one
of the UNIX profiles for each of these Active Directory users and then re-add them.
In addition, you should always use DirectControl console 5.0.0 or later when modifying these users.
In the Profile tab of the Properties page of a computer joined to a hierarchical zone, you cannot move this computer to a classic zone. Nor can you move
it to a zone in another domain. There are no such limitations with a computer joined to a classic zone. (Ref: IN-90001)
Extra results when analyzing duplicate service principal names (Ref: IN-90001)
When running the Analyze / Duplicate Service Principal Names report, kadmin/changepw is incorrectly returned as a duplicate. The SPN is actually
found multiple times, but this is by Microsoft design as it is the default account for the Key Distribution Center service in all domains.
Secondary groups not imported from XML files (Ref: IN-90009)
Using the Import Wizard to import user information from XML files does not import secondary group membership.
Using Windows Command Line Programs
This chapter provides a summary of the command line programs you can run on computers that have the Agent for Windows installed to perform
troubleshooting and administrative operations.
Using CopyGroup and CopyGroupNested
The CopyGroup and CopyGroupNested commands help you provision users when there are trust relationships between domains. You can use them to mirror
group membership and group hierarchy from a trusted domain and forest to a target domain and forest.
These utilities are located in the Zone Provisioning Agent’s Tools folder.
To use these command line utilities, you must have an account that can log on to the trusted source domain and the target domain. The account should also
have read permission on the source domain and permission to update the target domain.
For example, assume you have configured the AJAX domain to have a one-way trust with the DEVOPS domain and you have your Active Directory users and
groups defined in the DEVOPS domain. If you want to allow the users and groups in the DEVOPS domain to log on to computers that are joined to the AJAX
domain, you can log on to the AJAX domain controller with an account that has administrative privileges in both the AJAX and DEVOPS domains, then run the
CopyGroup utility to mirror the group membership from a group in the DEVOPS source domain as zone users in the AJAX target domain.
For more information about the command line arguments and options for these utilities, see the usage message displayed for each utility.
Using dzinfo
The dzinfo command line program provides detailed information about the effective rights, role definitions, and role assignments for a specified user. The
command output includes all of the same information that you can view using the Authorization Center as described in Using the Authorization Center
directly on managed computers. However, using dzinfo as a command line utility allows you to view and capture all of the output from the command in a
single window, which you can then save as a text file for troubleshooting and analysis or in reports.
The syntax for the dzinfo program is:
dzinfo [/v] [user_name] [/h]
The /v is an optional argument that enables you to view verbose output for the command. The user_name is an optional argument that enables you to view
information for the specified user account. However, you must be logged on as a local administrator to specify the user_name argument. If you log on with an
account that does not have local administrative privileges you cannot return authorization information for another user account.
If you run the dzinfo command without the user_name argument, the command returns authorization information for the currently logged-on user account.
The command returns detailed information about the rights, roles, and role assignments for the specified user (richl in the AJAX domain) similar to the
following:
From the Access Manager
Effective roles for AJAX\richl:
Domain Admin/portland
Zone: CN=portland,CN=global,CN=Zones,OU=Acme,DC=ajax,DC=org
Status: Active
Windows Login/global
Zone: CN=global,CN=Zones,OU=Acme,DC=ajax,DC=org
Status: Active
Effective Login Rights for AJAX\richl:
Console Login: Permitted
Audit Level: Audit if possible
Remote Login: Permitted
PowerShell Remote Access: Permitted
Role Assignments for AJAX\richl:
Status: Active
Account: AJAX\richl
Scope: Zone
Zone: ajax.org/Acme/Zones/global/portland
Local Role: No
Network Role: Yes
Effective: Immediate
Expires: Never
Status: Active
Account: AJAX\Domain Admins
Scope: Zone
Zone: ajax.org/Acme/Zones/global
Local Role: Yes
Network Role: No
Effective: Immediate
Expires: Never
Role Definitions:
Status: Active
Description: None
Zone: CN=portland,CN=global,CN=Zones,OU=Acme,DC=ajax,DC=org
Login Permitted: No
Rescue Right: No
Require MFA: No
Available Hours: All
Rights:
ADUC/portland
Type: Application
Description: None
Priority: 0
Run As: AJAX\Administrator
Application: mmc.exe
Path: C:\Windows\system64
C:\Windows
C:\Program Files
C:\Program Files (x86)
C:\Windows\SysWOW64
Arguments: "C:\Windows\system64\dsa.msc"
Match Case: No
Require Authentication: No
Application Criteria:
None
Domain Admin Network Access/portland
Type: Network Access
Description: None
Priority: 0
Run As: AJAX\Administrator
Require Authentication: No
Status: Active
Description: Predefined system role for general Windows login users.
Zone: CN=global,CN=Zones,OU=Acme,DC=ajax,DC=org
Login Permitted: Console & Remote & PowerShell Remote
Rescue Right: No
Available Hours: All
Rights:
None
Computer is joined to zone ajax.org/Acme/Zones/global/portland
Auditing for AJAX\richl:
Session ID 2:
Desktops:
Default: Not currently auditing.
Auditing is not available on this computer.
Using dzjoin
The dzjoin command line program enables you to automatically join users to the zone in which their roles and rights are assigned, or to join them to a specific
zone by zone name, when they log on to their computer. The dzjoin command line program is particularly useful for organizations that use non-persistent
virtual desktop infrastructures.
The syntax for the dzjoin command is:
dzjoin [/c <domain controller>] [/d] [/u <username>] [/f] [/h] [/r [y|n|yes|no]] {/z <zonename> | /s | /v]
Note: {/b}If the u option is specified but no password is found in the redirected input, you will be prompted for a password.
Use
this To do this
option
/c Specify a domain controller to connect to.
/d Retrieve zone data before restarting
Specify the user name to join zone using custom credentials. The user name must be in the format: USER@DOMAIN or DOMAIN\USER. The
/u
credentials are for remote access only. For the password, you can specify by redirected input. Otherwise, this tool will prompt user for password.
/f Suppress any warnings and/or questions.
/h Displays the command help.
Suppress the restart warning and specify to restart machine, if required, after joining zone. If no restart is required, this option is ignored. If no
/r
argument is provided, e.g. '/r', the default is to restart (example: '/r yes').
/z Join a zone using the zone name. If the zone name is not unique, use the canonical name instead.
Join to the zone where this computer is already pre-created in the zone or had previously been joined to the zone (but remotely left in a
/s
disconnected situation).
/v Display the agent version.
Note: You can also use the PowerShell command Join-CdmZone to join a zone.
Using dzleave
To leave a zone, use the dzleave command. The syntax for the dzleave command is:
dzleave [/c <domain controller>] [/u <username>] [/a|/f] [/r [y|n|yes|no]] [/v] [/h]
Use
this To do this
option
/a Remove the role assignment from the computer zone.
Use
this To do this
option
/c Specify a domain controller to connect to.
Specify the user name to leave zone using custom credentials. The user name must be in the format: USER@DOMAIN or DOMAIN\USER. The
/u
credentials are for remote access only. For the password, you can specify by redirected input. Otherwise, this tool will prompt user for password.
/f Suppress any warning and/or question(s). In case the domain cannot be contacted, this tool will perform a local zone leave automatically.
Specify whether to restart machine, if required, after leaving zone without prompt. If no restart is needed, this option is ignored. If no argument is
/r
provided, example: '/r', the default is to restart ('/r yes').
/v Show the agent version.
Note: You can also use the PowerShell command Exit-CdmZone to leave a zone.
Using dzdiag
The dzdiag command line program provides detailed diagnostic information for the local computer. The command output includes all of the same
information that you can view by clicking Diagnostics on the Troubleshooting tab as described in Running diagnostics and viewing logs for the agent.
The syntax for the dzdiag command is:
dzdiag [/h] [/o]
The /h is an optional argument that displays the command help.
The /o is an optional argument that allows you to output just the offline MFA provisioning information. You can use this option to see if a user has configured
an offline MFA profile or not and details about their offline MFA configuration.
You must be logged on as a local administrator to run the dzdiag command.
The command returns detailed information about desktop sessions similar to the following:
Product: Server Suite version-number ( build-number)

Computer: SERVER01
Joined Domain: acme.local
Zone: acme.local/Program Data/Centrify/Zones/global  Auditing: Available
Agent State: Connected
Time: 2018-10-04 17:41:41.491 -07:00
Session information:
Session 3
SAM Name: SERVER01\Administrator
Logon Type: Console
Always Audit: Yes
Desktops:
Default
GUID: 3e2c9799-b398-459f-a7a2-ed3a5359af3f
DZ Logon Id: (0x0)
Local Role: Self
Network Roles: Self
Audit Status: Currently Auditing
Network Drives: No
Logon information:
Logon ID (0x5bd925)
Logon GUID: 50972030-e9ed-45dc-b7b7-ecf588ef152d
Base Logon ID: (0x1aff6e)
Base SAM Name: ACME\admin
Local Role: Windows Login/CN=global,CN=Zones,CN=Acme,CN=Program Data,DC=acme,DC=local
Network Roles: None
Should Audit: Yes
Logon ID (0x5c2fe6)
Logon GUID: 053ef6cd-10cc-4383-b614-437c1a2067e3
Network Roles: None
Should Audit: Yes
Logon ID (0x5deca8)
Logon GUID: ce0da851-90f5-4cb6-a71b-25e2b116be75
ElevatedAccount: (ElevatedServiceAccount, ServiceAccount=S-1-5-21-1132289714-2257106472-2904894658-500)
Network Roles: None
Should Audit: Yes
Logon ID (0x613c40)
Logon GUID: 8ca4e342-4f4a-4e85-8e05-4d1332272c31
ElevatedAccount: (ElevatedServiceAccount, ServiceAccount=S-1-5-21-1132289714-2257106472-2904894658-1108)
Network Roles: None
Should Audit: Yes
Domain last access information:

Forest acme.local: Connected and Agent can authenticate
Domains:
acme.local (ACME): Connected
The offline MFA provisioning information:

None
Multi-factor Authentication information:

Platform Instance: https://tenant.my.centrify.net/  Last Used Platform Instance: <none>
Platform Certificate Exists: No
Disable Web Proxy: No
AD Site: Default-First-Site-Name
Platform Instance Override: <none>
Connector Override: <none>
MFA Enabled (NotJoined): No
Platform Instance (NotJoined): <none>
Web Proxy: <none>
Connectors:
Connector: server01.acme.local
FQDN: server01.acme.local
Tenant: https://tenant.my.centrify.net/  Last Known Availability: Yes
Last Access Time: -
IWA Enabled: Yes
IWA HTTPS Port: 8443
Proxy Enabled: Yes
Proxy Server: server01.acme.local:8080
AD Site: Default-First-Site-Name
Using dzrefresh
The dzrefresh command line program enables you to refresh the authorization cache from a Command Prompt window. Running the dzrefresh command
provides the same functionality as clicking Refresh on the Troubleshooting tab in the local agent configuration panel as described in Performing cache
operations.
The syntax for the dzrefresh command is:
dzrefresh
You must be logged on as a local administrator to run the dzrefresh command. The command output indicates whether the refresh of the authorization cache
is successfully initiated.
Using dzflush
The dzflush command line program flushes the authorization cache and reloads all authorization information from Active Directory. Depending on the size of
the authorization store, users might experience a temporary loss of the ability to use the rights granted to them while the authorization information is
reloaded. To prevent any loss of access privileges, in most cases you should use the dzrefresh command instead of the dzflush command to ensure that the
agent is using the latest authorization information. You should only use the dzflush command if Delinea Support recommends that you do so.
The syntax for the dzflush command is:
dzflush [/h] [/l]
Use this
To do this
option
/h Show the command usage.
Synchronize local Windows account information between Access Manager and the Windows systems where local account management is
/l
enabled. Note: Local account management is not supported on domain controllers.
You must be logged on as a local administrator to run the dzflush command. The command output indicates whether the authorization cache is successfully
flushed.
Using dzdump
The dzdump command line program enables you to view and capture the current content of the authorization cache. You can use command line options to
control the information contained in the output for the command.
The syntax for the dzdump command is:
dzdump [/d [directory-path] ] [/w=screen-width] [/s] [/n] [/g] [/l] [/a]

[/r] [/i] [/t] [/z] [/u] [/h]
If you specify no command line arguments, the dzdump command returns complete inmemory information from the authorization agent (dzagent) cache.
You can use the following command line arguments to refine the output for the command:
Use
this To do this
option
Dump cache files from the default location or a specified location. You can use this option with a directory path to dump cache files from a
specified location. For example, to dump cache files from the directory C:\AcmeAZstore:/d=C:\AcmeAZstore Note that you cannot use the /d
option to dump cache files directly on a computer where the Agent for Windows is currently running. However, you create a copy of the cache,
/d
then dump the cache from the saved copy. For example, copy all files in the cache directory—the default location for cache directory is  c:\ProgramData\Centrify\DirectAuthorize\Cache—to a temporary directory. You can then dump the authorization cache
by running dzdump and specifying the temporary location.
Use the specified screen-width for word-wrapping the command output. If you don’t specify this options, the default screen width is 80
/w
characters. To disable word-wrapping of the command output, specify a screen-width of zero. For example: /w=0
/s Display security identifier (SID) mappings
/n Display name mappings
/g Display assignee mappings
/l Display assignments in the joined zone hierarchy
/a Display assignments for security identifiers (SID)
/r Display role definitions
/i Display right definitions
/t Display access token information
/z Display zone hierarchy
/u Display recent user logon activity
/h Displays the command help
You can use any combination of display options to display only the information of interest. If you do not specify any display options, the dzdump command
displays all of the information in the authorization cache.
You must be logged on as a local administrator to run the dzdump command. You should note that the command output from a dzdump command can contain
sensitive information. You should only use the dzdump command if Delinea Support recommends that you do so.
Depending on the display options you specify, the command returns detailed information about the authorization cache.
Using runasrole
The runasrole command-line program enables you to run a specified Windows application using a specified access role. You can use command line options to
control whether the role is used as a local role, a network role, or both, and whether to use the current environment or the environment variables associated
with the “Run As” user account. The runasrole command line program is equivalent to selecting the Run with Privilege menu option when right-clicking an
application shortcut or executable.
The syntax for the runasrole command is:
runasrole /role:role[ /zone] [options] application [argument]
runasrole /localrole:role[ /zone] [options] application [argument]
runasrole /networkrole:role[ /zone] [options] application [argument]
You must specify the role to use in the rolename/zonename format. You must also specify an appropriate path to the application you want to access,
including any required or optional arguments.
You can use the following command line arguments and options with the runasrole command:
Use the role name you specify as both a local role and a network role. You can specify this option to run an application locally and
/role access a remote server using the same role, if applicable. You should only use this option if the role you are assigned and want to use
has both local and network access rights defined.
/localrole Use the role name you specify as a local role.
/networkrole Use the role name you specify as a network role.
/env Use the current environment variables instead of the environment variables associated with the "Run As" user account.
Use mapped network drives when running an application with the selected role. By default, you cannot use mapped network drives
/netdrives that are associated with you logged-on user account when running applications using a role with elevated privileges. If you want to
use a mapped network drive when accessing an application using a selected role, include the /netdrives option in the command line.
/removetimestamp Remove the grace period on Windows authentication and MFA for the current user session.
Prevents the runasrole program from exiting immediately after opening the specified application. If you specify this option, the
runasrole program starts the specified application and waits until the application session ends before exiting. When the application
session ends, the runasrole program exits and returns the same result code as the application. If you specify this option and the
/wait
application is a command line utility, the runasrole program redirects the application's input and output to the command line console.
You should note that some applications use a Microsoft API that does not support redirection of standard input and output. For
applications that don’t support redirection, the /wait option has no effect and is ignored.
Examples
To use the same role to open the Computer Management application locally and access a remote server in zone1, you might run a command similar to the
following:
runasrole /role:role1/zone1 mmc.exe c:\windows\system64\compmgmt.msc
To use the role named SQLdba from the finance zone as a local role to open the Services application, you might run a command similar to the following:
runasrole /localrole:SQLdba/finance mmc.exe c:\windows\system64\services.msc
To use role1 from zone1 as a local role to open the Computer Management application and use network access rights from role2 in zone2, you might run a
command similar to the following:
runasrole /localrole:role1/zone1 /networkrole:role2/zone2 mmc.exe compmgmt.msc
To open the Services application using the role named SQLdba from the finance zone and have the runasrole program remain open until you close the
Services application, you might run a command similar to the following:
runasrole /wait /role:SQLdba/finance mmc.exe c:\windows\system64\services.msc
Running an application from a shortcut
In most cases, you can use the runasrole program to run specified Windows applications using the application shortcut. However, there are many different
types of application shortcuts and the RunAsRole program does not support all of them. You can use the RunAsRole program to execute applications with the
following recognized shortcut target extensions:
.bat
.cmd
.cpl
.exe
.msc
.msi
.msp
.ps1
.vbs
.wsf
How to determine whether RunAsRole supports an application shortcut
You can determine whether you can use the RunAsRole program to execute an application from the application shortcut by checking the file extension for the
target application in the application’s shortcut properties dialog box.
To check the file extension for a target application shortcut
1. Select an application shortcut.
2. Right-click the shortcut, then click Properties to display the file properties.
3. Click the Shortcut tab and check the target field.
If the target file extension displayed is a supported file extension, you can use RunAsRole to execute the application from the application shortcut. You
should note that a shortcut target field might include both the file name for the application executable and one or more arguments. As long as the
application executable has a supported file extension, you can use RunAsRole to execute the application with the specified arguments from the
shortcut. For example, if the shortcut target is C:\Windows\System64\control.exe printers, the application executable
C:\Windows\System64\control.exe is a supported file extension with printers supplied as an argument. Therefore, you would be able use RunAsRole to
run the application from its shortcut.
Using RunAsAlternate
The runasalternate command line program enables you to log in to an application using an alternate account.
For example, system administrators typically have several accounts, a user account for general log-ins and an administrative account to access specific
systems and services.
The syntax for the runasalternate command is:
runasalternate [/account:accountname] application [argument] [/h]
You can use the following command line arguments to refine the output for the command:
application Run an application using the alternate account set in Privileged Access Service.
argument (optional) Specify an application argument
/account Specify the alternate account owned by this user for which the application is to be run. This can be useful in cases where a user has
accountname more than one alternate account.
/h Display the command help
If you have only one alternate account defined, you don't need to specify the /account option.
For more information about alternate accounts, see Enabling users to run applications with alternate accounts.
Working with Server Core and Windows Server 2012
The Agent for Windows can be installed on Windows computers that are configured to run the Server Core operating environment. Server Core is a Windows
installation option that provides a low-maintenance server environment with limited functionality.
Most Agent operations are not affected by running on Server Core. However, there are specific features that are not available or not applicable because of
the limitations of the Server Core environment itself. For example, the Run with Privilege menu option is not available on Server Core computers because
Server Core does not support Windows Explorer and other graphical user interface applications. However, you can use the runasrole command line utility to
run specific applications using a specified role.
Similarly, no Delinea notification area applet or desktop rights are available on Server Core computers. However, you can access the Authorization Center,
agent configuration panel, and agent command-line utilities from the Server Core command prompt.
The following list summarizes the Agent for Windows features that are not supported on Server Core computers:
You cannot create, select, or switch desktops or use any desktop-related features because the Windows desktop is not available on Server Core.
You cannot select Run with Privilege as a right-click menu option for applications because Windows Explorer is not available on Server Core.
You cannot open the Authorization Center or access the Delinea notification area applet because the Windows desktop and Windows Explorer are not
available on Server Core.
You cannot open applications such as the agent configuration panel from Start menu shortcuts because the Windows desktop and Windows Explorer
are not available on Server Core.
You should note that only the Agent for Windows is supported for the Server Core environment. A small number of other Server Suite components for
Windows support a command line interface, but are not configured to support a Server Core environment.
Server Core Supported PLatforms
Delinea supports the following versions of the Server Core environments:
Windows Server 2008 R2 Server Core

Windows Server 2012 Server Core
Windows Server 2012 Minimal Server Interface
Windows Server 2012 R2 Server Core
Windows Server 2012 R2 Minimal Server Interface
You should note that Server Core is not supported on Windows Server 2008 because Windows Server 2008 Server Core does not support any version of the
.NET Framework. The Agent for Windows requires the .NET Framework. For more information about the supported libraries and .NET functionality on Server
Core, see the reference material available on the Microsoft Developer Network website for the operating system you have deployed.
For general information about Server Core on Windows Server 2008 R2, see: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-
server-2008-R2-and-2008/cc753802(v=ws.10)
For general information about Server Core on Windows Server 2012 R2, see: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-
server-2012-R2-and-2012/hh831786(v=ws.11)
Installing the Agent on a Computer Running Server Core
You cannot use the autorun.exe or the setup.exe program to install components on a computer that is configured to run as a Server Core environment.
Instead, you must install from Microsoft Installer (.msi) files using the msiexec command-line program.
To install the Agent for Windows on Server Core:
1. Use the Deployment Image Servicing and Management (DISM) or another command-line tool to enable the .NET Framework.
For example, if you are using Windows Server 2012 or later and the .NET Framework is located on the installation media in the D:\sources\sxs folder, use
the following command:
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:D:\sources\sxs
To install .NET Framework on Windows Server 2008 R2, run the following commands to enable the required features:
Dism /Online /Enable-Feature /FeatureName:NetFx2-ServerCore-WOW64
Dism /Online /Enable-Feature /FeatureName:NetFx3-ServerCore-WOW64
Dism /Online /Enable-Feature /FeatureName:NetFx2-ServerCore
Dism /Online /Enable-Feature /FeatureName:NetFx3-ServerCore
2. Copy the Agent for Windows files to the Server Core computer.
For example:
copy D:\Common\Centrify* C:\Agent
copy D:\Agent\* C:\Agent
3. Install the Common Component service using the .msi file.
For example, to install the Common Component on a computer with 64-bit architecture, you might use the following command:
msiexec /i "Common Component64.msi" /qn
4. Install the Agent for Windows using the .msi file.
Run the following command:
msiexec /i "Agent for Windows64.msi" /qn
5. Restart the computer with the appropriate shutdown options to complete the installation and start agent services.
For example, you might run the following command:
shutdown /r
Note that restarting the computer is not required if you install only auditing features.
Opening Consoles on Server Core Computers
Because the primary interface for the Server Core environment is a command prompt with only limited support for graphical user interface features, you
must use the command line to open the consoles that enable you to join or leave a zone, view your rights and roles, and configure agent settings.
Joining a Zone
One of the first tasks after installing the Agent for Windows is to join a zone. You can do by launching the agent configuration panel from the command
prompt.
To open the agent configuration panel to join a zone:
1. Navigate to the Agent for Windows installation directory.

2. By default, the agent files are installed in the C:\Program Files\Centrify\Agent for Windows directory. 
3. Run Centrify.DirectAuthorize.Agent.Config.exe. 
4. Click Change.
5. Click Browse.
6. Type all or part of the zone name, click Find Now, then select the zone to join and click O K.
7. Click Close to exit the agent configuration panel.
If you later need to change the zone, run diagnostics, refresh the authorization cache, or view or modify log settings, you can run  Centrify.DirectAuthorize.Agent.Config.exe to perform those tasks.
Viewing Authorization Details
By default, identity management, privilege management, and audit and monitoring service features are enabled after you install and configure the Agent for
Windows. To see details about your rights, role definitions, role assignments, and auditing status, you can launch the Authorization Center from the command
prompt.
To open the Authorization Center on a computer with the Server Core operating system:
1. Navigate to the Agent for Windows installation directory.
By default, the agent files are installed in C:\Program Files\Centrify\Agent for Windows directory. 
2. Run Centrify.DirectAuthorize.Auth.Center.exe. 
Configuring Auditing Options
By default, identity management, privilege management, and audit and monitoring service features are enabled when you install the Agent for Windows. To
configure audit and monitoring service options and specify the audit installation for the agent, you can launch the agent configuration panel from the
command prompt.
To open the agent configuration panel to configure auditing features:
1. Navigate to the Agent installation directory.
By default, the agent files are installed in the  C:\Program Files\Centrify\Audit\Agent directory.
2. Run agent.configure.exe.
3. Click Configure.
4. Select a color quality, then click Next.
Because the Server Core operating system uses very few graphical elements, in most cases you should accept the default setting of Low for the color
quality. This setting minimizes the storage requirements for auditing if you have enabled video capture auditing.
5. Accept the default offline data location and maximum size or type a different location, then click Next.
You can also drag the slider to change the maximum percentage of the drive the offline data can consume. In most cases, however, you should leave the
default setting unchanged.
6. Select the audit installation, then click Next.
7. Review your configuration settings, then click Next.
8. Click Finish to close the configuration wizard.
9. Click Close to exit the agent configuration panel.
Running Command Line Programs
The Agent for Windows includes several command line programs for performing administrative tasks. The following command line programs are supported
on Server Core computers:
dzinfo
dzjoin
dzdiag
dzrefresh
dzflush
dzdump
runasrole
For more information about the command line options or output for these commands, see Using Windows command line programs or run the command with
the /help option.
Unsupported Windows Server 2012 Features
Windows Server 2012 includes support for claims, compound authentication, and Kerberos armoring. The core Agent for Windows does not provide support
for these advanced authentication features. To take full advantage of these advanced authentication services, however, requires you to make the following
changes to your environment:
Deploy Dynamic Access Control.
Upgrade all of your domain controllers and application servers to Windows Server 2012 or later.
Upgrade all of your workstations to Windows 8 or later.
Raise the domain functional level to Windows Server 2012.
If you have a mixed environment that includes Windows 7 and Windows 8 or later workstations and Windows Server 2008 or Windows Server 2008 R2 domain
controllers, you can configure the administrative template for claims, compound authentication, and Kerberos armoring to use the Not supported option
(default).
To use the Supported configuration option, you must deploy Dynamic Access Control, configure Windows 8 and later client-side support for claims,
compound authentication and Kerberos armoring, and ensure you have domain controllers running Windows Server 2012 to handle the authentication
requests for those computers. You should not install the Agent for Windows on any computers configured to support claims, compound authentication and
Kerberos armoring to prevent authentication failures.
In addition, Server Suite does not provide any specific support for authenticating access to Server Message Block 3.0 (SMB3.0) file shares that are supported
in Windows Server 2012. The SMB protocol operates as an application layer for providing shared access to computers, printers, and other devices. This
protocol has been extended to provide shared access to virtual machines and SQL user databases.
Server Suite Unix/Linux Quick Start
This Quick Start Guide provides a brief summary of the steps for installing and getting started with Server Suite software. For more information about any
step, see the appropriate sections in the Unexpected Link Text or Unexpected Link Text.
1. Run the setup program for Authentication & Privilege components on a Windows administrator's workstation.
The setup program simply copies the necessary files to the local Windows computer, so there are no special permissions required to run the setup
program other than permission to install files. Follow the prompts displayed to select which components to install.
2. Open Access Manager to start the Setup Wizard and create an organizational structure and the containers for Licenses and Zones.
In the Setup Wizard, you can accept the default organizational structure or create a custom organizational unit for Server Suite objects, add license
keys, and configure a few basic permissions and setup options.
3. In Access Manager, create a new zone with the default options. For example, create a new zone named Demo.
4. In Access Manager, add Active Directory users to the new zone.
Select the new Demo zone.

Right-click, select Add User to Select User Type, then select Active Directory users to search for and select existing Active Directory users.
Select Define user UNIX profile and deselect assign roles.
Accept the defaults for all fields.
5. Create a child zone.
Select the Demo zone.

Right-click, then select Create Child Zone.
Type a name for the zone, for example, Child1 and an optional description, then click Next and Finish to create the new child zone.
6. Assign a role for the users you added to the Demo zone.
User profiles are inherited by child zones, so the users you added to the Demo zone automatically have a profile in Child1. To log on to a computer, users
must have a profile and a role assignment. You can assign the default UNIX Login role to enable users to log on.
Expand Child Zones, Child1, and Authorization.

Select Role Assignments, right-click, then click Assign Role.
Select the UNIX Login role from the results and click O K.
Click Add AD Account.
Search for and select one of the Active Directory users you added to the Demo zone, then click O K.
7. On the Linux or UNIX computer, log on as root. if you are installing on a computer running Linux or UNIX.
8. Run the install.sh command.
./install.sh
The installation script checks whether the computer meets all system requirements, such as a supported operating system, available disk space, DNS
and network connectivity, and your Active Directory configuration.
If the computer meets all requirements, you can choose to install all Server Suite, or a customized set of services. You can also choose whether to
automatically join the domain and restart the local computer to complete the installation. After you make your selections, the script installs a platform-
specific Server Suite Agent and any other packages.
Alternatively, you can install using a native package manager or another software distribution utility. The command line syntax and the agent package
name will depend on the operating system on which you are installing.
To manually join the domain after installation, use the adjoin command. In either case, you must specify the zone to join. For example, if you created the
Child1 zone, you might run a command similar to this:
adjoin myDomain -z Child1
In Step 4, you created a profile for an Active Directory user in the Demo zone. In Step 6, you assigned the user the UNIX Login role. You can now verify
authentication by logging off as root and logging on to the computer you just joined to the Active Directory domain with the Active Directory user
account and password you assigned the UNIX Login role.
That’s it!
From here, if you want to explore further, you can:
Create and assign additional roles to users

Create new child zones
Import existing UNIX users and groups
Override user attributes in child zones
Set group policies for UNIX computers and users
Run reports
Import and manage NIS maps in Active Directory
For more information about any topic, see the Server Suite documentation set.
Prepare to Use Multi-Factor Authentication
This guide is intended for UNIX or Windows administrators who intend to configure multi-factor authentication for computers managed by Server Suite.
Configuration information for Delinea customers who are not using Server Suite to manage their environment, but want to configure multi-factor
authentication to log in Windows computers, should go to Downloading the Server Suite Agent for Windows.
There are two separate scenarios for which you might want to require multi-factor authentication:
Login access to Server Suite-managed computers.

As part of a re-authentication process so that users who are attempting to use Application, Network, and Desktop rights on Windows machines, or
command rights with elevated privileges or in a restricted shell on UNIX machines, must provide a password and another form of authentication before
they can execute the selected command.
With these two scenarios in mind, you can configure multi-factor authentication based on user roles or computer roles, for specific applications, or for
individual commands. You can also skip multi-factor authentication for applications that do not support it or for other reasons on a case-by-case basis by
enabling and applying group policy or by setting configuration parameters.
Secure Login Access
You can configure multi-factor authentication for users logging on to Server Suite-managed computers to improve the security of physical or virtual data
centers. You can do this by assigning the predefined require MFA for login role to users who are required to provide more than one form of authentication.
Alternatively, for UNIX and Linux roles, you can also create custom role definitions with the Require multi-factor authentication for login system right
selected. Because the Windows Login role can be assigned to local accounts, there is no system right for multi-factor authentication, therefore you must
assign users the require MFA for login role.
Roles and role assignments are important when configuring multi-factor authentication for login access to Server Suite-managed computers in hierarchical
zones.
Before configuring multi-factor authentication, you should be aware that multi-factor authentication for Server Suite-managed computers relies on the
infrastructure provided by the Delinea Platform.
Note: For Linux and UNIX computers, logging on requires a PAM application such as login, ssh, or a desktop manager. Most programs that enable users to log
in support multi-factor authentication. However, some desktop manager programs that run on older operating systems might not support multi-factor
authentication.
Multi-Factor Authentication and Smart Card PIN Login
A smart card user logging in by way of a Personal Identification Number (PIN) will not authenticated by multi-factor authentication. (Ref: CS-38641)
Secure Privileged Access
If you have installed Server Suite, you can require multi-factor authentication when users perform operations with an elevated access right, in addition to
requiring multi-factor authentication when users log in. For Linux and UNIX computers, for example, you can also create command rights that require multi-
factor authentication when executing commands using elevated privileges (dzdo) or in restricted shell (dzsh) environments. For Windows computers, you
can create desktop, application, and network access rights that require two-step authentication to use the elevated privileges associated with the desktop,
application, or network access.
Before configuring multi-factor authentication for any type of access right, you need to perform some preliminary steps to prepare your environment.
Preview the Preliminary Steps
Because multi-factor authentication for Server Suite-managed computers relies on the infrastructure provided by the Delinea Platform, there are steps that
require access to a Delinea Platform instance and the administrative portal. As a preview, here are the steps involved in preparing the identity platform to
support multi-factor authentication for Server Suite-managed computers:
Register for the Delinea Platform.

Install and configure at least one Cloud Connector for communication with the platform. Your machine account must have login access to the
connector machine.
Verify the users who are required to provide more than one form of authentication have valid Active Directory accounts that are active in the
platform.
Add or select the authentication profiles that specify the types of authentication challenges to support.
Create a role with the appropriate computer members and administrative rights for multi-factor authentication.
Verify the server authentication instance URL you want to use if you have access to more than one authentication instance.
After you have completed the preliminary steps, you can assign users the predefined require MFA for login role or, for users of UNIX and Linux machines, a
custom role with the Require multi-factor authentication for login system right to require two-step authentication when logging on. These
preliminary steps are also required if you want to create command rights that require two-step authentication when executing commands using elevated
privileges (dzdo) or in restricted shell (dzsh) environments on UNIX and Linux machines, or when creating roles with elevated Windows rights.
Register for Privileged Access Service
Multi-factor authentication for Server Suite-managed computers relies on the infrastructure provided by Privileged Access Service and authentication and
privilege elevation. Privileged Access Service enables you to securely manage users, roles, policies, devices, and applications in the identity platform. You
can also define the types of authentication challenges you support and where the multi-factor authentication rules apply.
Sign Up and Activate Your Account
To get started, you should register for an account in Privileged Access Service if you are not already a subscriber. You can request a free trial or subscribe to
Privileged Access Service through the Delinea website.
If you don’t already have a subscription, you can start by requesting access to Privileged Access Service by visiting the Delinea website.
After you register for a Delinea account with a valid email address, you will receive an “Activate Your Delinea Account” email followed by a “Your Delinea
Account Is Ready Next Steps” email with your account details. Your account details include the user name and temporary password for an administrative
account that is a member of the predefined System Administrator role and a unique customer identifier. For example, your email message might have
account details similar to the following:
Privileged Access Service management: https://abcd1234.my.centrify.net/manage
Your User Name: admin_maya.garcia@acme.net
Your Temporary Password: 1234abcepassword (You'll be asked to change this when you log in)
Customer ID: ABCD1234
Use your account details to log in and set a new password for your administrative account.
Start or Skip the Wizard
After you log in successfully, you will see a Welcome to Privileged Access Service message with the option to start or skip the quick start wizard.
If you click Start the Wizard, you are prompted to manage mobile devices, add web applications, add mobile applications, add users, and invite users. You
can click Next to skip any or all steps. None of the steps in the wizard are required to set up multi-factor authentication.
If you are only interested in preparing for multi-factor authentication, you can select the Don’t show this to me again option, then click Skip. If you click
Skip now, you can run the wizard at any time after configuring multi-factor authentication by clicking Start Wizard on the Getting Started dashboard.
If you have not completed these preliminary steps, stop here and verify that you have received the “Your Delinea Account Is Ready - Next Steps” email and
that you can log in to the Privileged Access Service platform with the account information in the email.
Plan Multi-Factor Authentication for Server Suite-Managed Computers
Privileged Access Service is most often used to store information about people and devices, to identify different classes of users and devices, and to define
the policies that specify what different classes of users and devices can do. To support multi-factor authentication, however, you must also add Delinea-
managed computers to the access service.
Any computer that will require multi-factor authentication must also be added as a member of an identity platform-based role. This step is similar to adding
computers to a zone. For multi-factor authentication, an identity platform-based role has computers as members and is managed through Privileged Access
Service. It is separate from the role definitions and role assignments you manage using Access Manager or other Server Suite components.
Install and Configure a Connector
The connector is a multipurpose service that enables secure communication between your internal network and Privileged Access Service. Multi-factor
authentication requires at least one connector to be installed on your network inside of the firewall. The connector provides the link between your internal
Active Directory forest and the Privileged Access Service platform.
You can install more than one connector for your organization to support fail-over and load balancing. You might also want to install more than one connector
if you are using multiple instances of Privileged Access Service or have access to more than one customer-specific Identity platform instance URLs. In most
cases, you should install at least two connectors in a production environment.
Note: Make sure that the account you're logged into on the computer has the appropriate permissions to install the Cloud Connector.
For details about installing and configuring the connector, please see the following topics in the Privileged Access Service help:
Installing a connector
Configuring a connector
Installing a connector
Configuring a connector
Establishing a Connector Identity for Multi-Factor Authentication
In order to enable multi-factor authentication for Delinea-managed UNIX and Linux machines, the connector must validate the machine credentials using the
Integrated Windows Authentication (IWA) service. To use the IWA service, your connectors must be configured to use an HTTPS-enabled port.
To configure connectors to use an HTTPS-enabled port, you must either download a host certificate issued by Delinea, or upload a host certificate issued by
a Certificate Authority (CA) already trusted by your environment.
To configure Windows computers for multi-factor authentication, you must establish an initial trust relationship between the Windows machine and the
Cloud Connector. Since the connector accesses the IWA service through a secure HTTPS channel, you must validate the correct certificate during
installation when enabling multi-factor authentication for login.
If you are operating in an evaluation environment, and cannot easily set up the required certificate trust relationship, you have the option to skip this step
during installation and trust your own connector without enrolling in the IWA service. In this case, the computer is connected directly to the Delinea Platform,
and multi-factor authentication can be enabled. Note, however, that this should only be done in an evaluation environment, as it has serious security
implications in a live production environment.
If you have chosen not to establish the trust relationship, but wish to do so in the future, you can either leave and then rejoin a zone if you are joined to one, or
you can disable and then re-enable multi-factor authentication for login to launch the configuration wizard.
To configure a connector to use a Delinea-issued root certificate
1. In the Admin Portal, click Settings > Network.

2. Select the connector you want to configure, and choose Modify from the Actions menu.
3. In IWA Service, click Download your IWA root CA Certificate to retrieve the public certificate for the tenant-specific CA certificate issued by
Delinea.
4. Click Download to download the host certificate issued by Delinea for your connector.
You can export the IwaTrustedRoot.cer trusted root CA certificate issued by Delinea and manually install it on a local computer, or use group policy to
distribute the certificate file as a trusted root certificate to multiple computers
Note: Express users cannot use group policies to distribute certificates in bulk to UNIX and Linux computers. To distribute the certificates, you must
download and install the certificate in the appropriate directory on each computer.
To Import the Certificate Manually to a Local Windows Computer
1. Right click on the certificate you downloaded in To configure a connector to use a Delinea-issued root certificate.
2. Select Install Certificate to start the Certificate Import Wizard.
3. Select Local Machine and click Next.
4. Select Place all certificates in the following store and click Browse.
5. Select Trusted Root Certification Authorities and click O K.
6. Click Next and then Finish to complete the Wizard.
A Windows Security Warning may be displayed. Click Yes to finish installing the certificate.
To Export the Certificate for Bulk Group Policy Distribution
1. Select the trusted root certificate you downloaded, right-click, then click Open.
2. Click the Details tab and click Copy to file to start the Certificate Export Wizard, then click Next.
3. Select DER encoded binary X.509 (.CER) as the file format, then click Next.
4. Click Browse to select a location on the local server, type a file name and click Save, then click Next.
5. Click Finish.
To Distribute the Certificate using Group Policy
1. Open Group Policy Management to select the group policy object that defines the IP Security policies, then click Edit.
2. Click Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root
3. Select Trusted Root Certification Authorities, right click, and select Import to open the Certificate Import Wizard.
4. Click Next on the Welcome screen.
5. Browse to find the root certificate you downloaded, then click to accept the default values on each screen.
6. Click Finish to complete the wizard.
The root certificate is now in the Active Directory Trusted Root Certification Authorities container. Group policy publishes all certificates in this
container to computers joined to the domain. You can also run the gpupdate command from a command prompt to push the certificates to the
computers in the domain.
Using a certificate not issued by Delinea with the Cloud Connector
If you want to use a certificate issued by a CA that is trusted by your organization, you must upload the certificate from the Cloud Connector Configuration
program. Doing this ensures that the computer credentials can be validated for secure communication between the connector and the authentication server.
The issuer of the certificate must also be trusted by resources running agents.
To use an externally issued certificate for a Cloud Connector
1. In the Admin Portal, click Settings > Network > Centrify Connectors.
2. Select the connector you want to configure, and choose Modify from the Actions menu.
3. Click IWA Service.
4. Click Upload and navigate to the location of the certificate trusted by your organization.
Note: You may get the following error while enrolling a Windows agent/machine into the cloud-based CIS with debugging enabled:
An error occurred while sending the request. ---\> System.Net.WebException:
The underlying connection was closed: Could not establish trust relationship for
the SSL/TLS secure channel. ---\> System.Security.Authentication.AuthenticationException:
The remote certificate is invalid according to the validation procedure.
If so, check your local machine trusted root CA. The server may not have the corresponding DigiCert Global Root CA installed. If so, export the local
certificate. Then import the certificate to the server. After that, you should be able to enroll the server.
Verify Open Ports
Multi-factor authentication requires the following ports to be open for inbound communication and domain traffic:
Port 8080 for HTTP API proxy
Port 8443 for secure HTTP (HTTPS) connections
Installing the connector automatically sets Windows firewall rules to open these ports. However, if you are using a third-party firewall instead of the default
Windows firewall, you should manually modify the port rules to allow the Server Suite Agent for Windows to communicate with the Cloud Connector. Both
ports are required because integrated Windows authentication over HTTPS uses port 8443 to enable the connector to receive inbound connections from the
agents.
Log on and Verifying Connector Settings
After you have installed and configured at least one connector, you can use either the Admin Portal or your default browser to log in to the Delinea Platform.
To log in and verify settings
1. Open a browser and log in to your customer-specific identity platform instance URL.
2. Type the user name from your account details and the password you set when you activated the service.
If you see the Welcome message, select the “Don’t show this to me again” option, then click Close.
By default, the Getting Started dashboard is displayed in the Admin Portal. The Getting Started dashboard has links to topics that explain important
tasks—such as creating roles and adding users—for the Delinea Platform. You will perform similar steps to prepare for multi-factor authentication.
However, you can skip those steps for now. For multi-factor authentication, you should first verify some settings on your connector and, if necessary,
prepare a new Active Directory group for the computers where you plan to use multi-factor authentication.
3. Click Settings > Network > Centrify Connectors.
4. Select the connector and then select Modify from the Actions menu to display the connector Configuration.
5. Verify the following options are selected under IWA Service:
Enable Web Server
This option is required to enable integrated Windows authentication for agents and multi-factor authentication.
6. Click Save.
Prepare a Group for Delinea-Managed Computers
After verifying connector settings, you can use Active Directory Users and Computers or other tools to prepare an Active Directory group for the computers
where you plan to require multi-factor authentication. Although you can use any existing Active Directory group for this purpose, the steps in this guide
assume you will use a new group specifically for multi-factor authentication.
Multi-factor authentication requires computers to be members of an identity platform role assigned a specific administrative right in the Delinea
Platform. You can add individual computers independently without using an Active Directory group. However, using an Active Directory group is the
recommended approach and facilitates the deployment of computer roles that link user role assignments to computer groups.
To Add an Active Directory Group for Multi-Factor Authentication
2. Select a location, right-click, then select New > Group.
For example, if you are using the default deployment structure, you might expand the Centrify organization unit and select Computers, then right-click
to create a new group in that organizational unit.
3. Type a group name, select the group scope, and verify the group type, then click O K.
For example, type MFA-Group, select Global for the group scope, and verify the group type is Security, then click O K.
Add a User or Group for MFA to a Role with an Admin Portal-Specified pPolicy
Offline MFA mode is not triggered during logon to the computer once the agent has successfully connected to the cloud. Logon will fail if the cloud fails to
authenticate the user, the user is not allowed to perform the MFA logon, or if the user is not assigned to any profile in the portal.
To add a user or group to a role in the Admin Portal
1. Create a new role or double-click an existing role that is policy-specified.

2. Click Members > A d d.
3. Enter a search string to locate the Active Directory groups or users you are using that require multi-factor.
4. Select the group or user and then click A d d.
5. Click Save.
Prepare a Role for Delinea-Managed Computers in the Admin Portal
After you have prepared an Active Directory group for the computers where you plan to require multi-factor authentication, you can use the Admin Portal to
prepare a role for those computers.
To prepare a role in the Admin Portal:
1. In the Admin Portal, click Core Services, then click Roles.
2. Click Add Role.
3. Type a role name and, optionally, a role description.
For example, type MFA-LinuxComputers as the role name and Role for multi-factor authentication of Linux Computers as the role description, then click
Save.
4. After naming the role, click Members, then click A d d.
5. Type a search string to locate the Active Directory group you are using for computers that require multi-factor authentication.
For example, if you created a group called Audited Servers in Preparing a group for Delinea-managed computers, you might type “aud” as the search
string to locate that group. Alternatively, you can search for and add individual computers to the role if you are not using an Active Directory group.
Adding individual computers to the role, however, is not a scalable approach for most organizations.
This step creates the link between the Delinea-managed computers and the identity service. There is no change to how you manage the computers you
add to the identity service. This link is required to allow Privileged Access Service to provide authentication profiles to managed computers.
6. Select the group, then click A d d.
7. Click Administrative Rights, then click A d d.
8. Select the Computer Login and Privilege Elevation administrative right, then click A d d.
This administrative right is only applicable for the computers that are members of the identity platform role. The right does not apply to users and is
ignored for any users added as members of the role. In general, you should not add users to any role that is intended for multi-factor authentication on
Delinea-managed computers.
9. Click Save.
Prepare Authentication Profiles
With Server Suite, you can require multi-factor authentication for two distinct situations:
As part of the login process so that users who are attempting to log in to Delinea-managed computers must provide multiple forms of authentication
before they are granted access.
As part of a re-authentication process so that users who are attempting to use Application, Network, and Desktop rights on Windows machines, or
command rights with elevated privileges or in a restricted shell on UNIX machines, must provide a password and another form of authentication before
they can execute the selected command.
To configure the types of authentication challenges allowed in each situation, you can prepare one or more authentication profiles in the Admin Portal. If
you have already configured authentication profiles for other purposes, you can reuse those profiles for multi-factor authentication or add new profiles
specifically for the computers you manage using Server Suite. You can prepare one profile to use for both login access and for the use elevated privileges or
you can prepare separate profiles for each situation.
Create an Authentication Profile
The first step in preparing authentication profiles is to create the profile.
To create an authentication profile:
1. Open a browser and log on to Privileged Access Service using your customer-specific URL.
2. Navigate to Settings > Authentication.
Three default authentication profiles are available out-of-the-box:
Default New Device Login Profile: Uses Password for the first challenge and Mobile Authenticator, Text message (SMS) confirmation code,
Email confirmation code, or OATH OTP Client for the second challenge with a 12 hours pass-through duration.
Default Other Login Profile: Uses Password for the first challenge and no secondary challenge with a 12 hours pass-through duration.
Default Password Reset Profile: Gives the option for users to use Mobile Authenticator, Text message (SMS) confirmation code, Email
confirmation code, or OATH OTP Client for the first challenge with a 12 hours pass-through duration.
3. Select an existing Authentication Profile or click Add Profile.
The fields needed to add new profile.
1. Type the authentication profile name.
2. Select the types of authentication to present for the first challenge.
Note: The second authentication is not needed. Challenge two is a third mechanism.
3. Click O K.
The pass-through option does not apply to Windows, Linux, or UNIX MFA logins unless you specify otherwise in the policy settings.
Select the authentication mechanism(s) you require and want to make available to users. Some authentication mechanisms require additional
configurations before users can authenticate using those mechanisms. See Authentication mechanisms for information about each authentication
mechanism.
For example, you can require that the first challenge be the user’s account password. Then for the second challenge, users can choose between an email
confirmation code, security question, or text message confirmation code.
If you have multiple challenges, Privileged Access Service waits until users enter all challenges before giving the authentication response (pass or fail). For
example, if users enter the wrong password for the first challenge, we will not send the authentication failure message until after users respond to the second
challenge.
If users fail their first challenge and the second challenge is SMS, email, or phone call, the default configuration is that Privileged Access Service will not send
the SMS/email or trigger the phone call. Contact support to change this configuration.
Assign Login Authentication Profiles
The next step is to assign login authentication profiles to policies. In this task, you set up a policy so that if specified conditions are met, the affected users
proceed according to a specified authentication profile. If those conditions aren't met, you can specify a default authentication profile or block access
entirely.
For example, you could set a policy that says that during work hours of Monday to Friday, 8:00 am to 5:00pm, users log in using an authentication profile that
requires a password and a security question. For users logging in outside of those days or times, users will have to login with a password, security question,
and an email confirmation code.
As a reminder, you use authentication profiles to define the necessary authentication methods to use. You define authentication rules to specify
where to enforce those authentication profiles inside of a policy set.
To assign a login authentication profile to a policy set:
1. In the Admin Portal, go to Access > Policies and either click Add Policy Set to create a new policy or click an existing policy to edit.
2. Create or edit the policy set and assign it to the desired users or resources.
For details, see "Creating policy sets and policy assignments" in the Privileged Access Service help.
3. In the Policy Settings area, navigate to Authentication > Centrify Server Suite Agents > and click one of the following settings:
Policy Setting Description
Linux, UNIX and For Linux and UNIX Servers or Workstations where the Server Suite Agent for *NIX is installed and enabled. For Windows Servers
Windows Servers where the Server Suite Agent for Windows is installed and enabled
Windows For Delinea-managed workstations where the Server Suite Agent for Windows is installed and enabled. The operating system
Workstations variant determines if it's a workstation.
Privilege Elevation For systems where either the Server Suite Agent for *NIX or Serer Suite Agent for Windows is installed and enabled.
Note: For any of the above policy settings, the role assignment associated with this policy must include computer objects or groups in Active Directory and
also the "Computer Login and Privilege Elevation" administrative rights.
1. Select Yes in the Enable authentication policy controls drop-down.
The Authentication Rules section displays. You use this section to define which authentication profiles apply under which conditions.
2. (Optional) If you want to specify conditions for which different authentication rules apply, click Add Rule. Otherwise, proceed to step
The Authentication Rules window displays.
3. Click Add Filter, and then click the same drop-down to spicy which kind of condition.
For example, you can create a rule that requires a specific authentication method when users access Privileged Access Service from an IP address that
is outside of your corporate IP range. Supported filters are:
Filter Description
The authentication factor applies as follows: For Privileged Access Service on-premise, the authentication factor is the connector's IP address
when you log in. When using HTTP proxy, the authentication factor is the HTTP Proxy server’s IP address when you log in. For Privileged Access
IP Service, the authentication factor is the tenant connectors’ public IP address when you log in. When using HTTP proxy, the authentication factor
Address is the HTTP proxy server’s public IP address when you log in. This option requires that you have configured the IP address range under Settings >
Network > Corporate I P Range. Note: For Windows machines that can access the Internet, the authentication factor is the machine's IP
address when you log in.
Identity
The authentication factor is the cookie that is embedded in the current browser by the directory service after the user has successfully logged in.
Cookie
Day of
The authentication factor is the specific days of the week (Sunday through Saturday) when the user logs in.
Week
Date The authentication factor is a date before or after which the user logs in that triggers the specified authentication requirement.
Date
The authentication factor is a specific date range.
Range
Time
The authentication factor is a specific time range in hours and minutes.
Range
Risk Level: The authentication factor is the risk level of the user logging on to Admin Portal. For example, a user attempting to log in to Privileged
Access Service from an unfamiliar location can be prompted to enter a password and text message (SMS) confirmation code because the
external firewall condition correlates with a medium risk level. This Risk Level filter, requires additional licenses. If you do not see this filter,
contact Delinea support. The supported risk level are: Non Detected — No abnormal activities are detected. Low — Some aspects of the
Risk
requested identity activity are abnormal. Remediation action or simple warning notification can be raised depending on the policy setup. Medium
Level
— Many aspects of the requested identity activity are abnormal. Remediation action or simple warning notification can be raised depending on
the policy setup. High — Strong indicators that the requested identity activity is anomaly and the user's identity has been compromised.
Immediate remediation action, such as MFA, should be enforced. Unknown — Not enough user behavior activities (frequency of system use by the
user and length of time user has been in the system) have been collected.
For the Day/Date/Time related conditions, you can choose between the user’s local time and Universal Time Coordinated (UTC) time.
4. Click the A d d button associated with the filter and condition.
5. Select the authentication profile you want applied if all filters/conditions are met in the Authentication Profile drop-down.
The authentication profile defines which authentication methods to use. If you have not created the necessary authentication profile, select the A d d
New Profile option in the list (it's at the bottom of the list).
6. Click O K to close the Authentication Rules dialog box.
7. If desired, continue adding authentication rules. You can drag the rules to change the order of priority. The highest priority rule is at the top of the list.
8. Select a default profile to be applied if a user does not match any of the configured conditions in the Default Profile (used if no conditions
matched) drop-down.
Note: If you have no authentication rules configured and you select Not Allowed in the Default Profile dropdown, users will not be able to log in to
the service.
9. If this policy setting is for Linux, UNIX, and Windows Servers, you have the option to configure how the pass-through duration applies. The pass-through
duration is how long before the user needs to re-authenticate, and you define the pass-through duration in the authentication profile (for example, the
default is 30 minutes). Select one of the following options:
Never (default): Always prompt for MFA and ignore the pass-through setting.
If Same Source and Target: Apply the pass-through duration if the user is logging in from the same system and where they're logging in to is
the same system as compared to the initial login.
If Same Source: Apply the pass-through duration if the user is logging in from the same system as compared to the initial login.
If Same Target: Apply the pass-through duration if the user is logging in to is the same system as compared to the initial login.
10. If desired, you can add multiple policy settings to the same policy set.
11. Click Save.
Assigning Privilege Elevation (Re-authentication) Profile
Finally, you must assign privilege elevation profiles.
1. For Elevated Privileges Profile, click Privilege Elevation Policies > Privilege Elevation, select Yes for Enable authentication policy controls, and
Add Rule > Add Filter, click Authentication Profiles and display the list of existing profiles and select a profile to use or click Add New Profile.
You can use the same profile for server access, and to re-authenticate for roles and rights that require multi-factor authentication. However, if you
want to specify different authentication challenges from which a user can select when executing UNIX commands or accessing Windows applications,
select Add New Profile.
As with the Login Authentication Profile, you can select multiple types of authentication to present for the first and second challenges. However, only
the authentication challenges that are applicable for a user can be presented when the user attempts to access privileged Windows rights or execute
UNIX commands with elevated privileges (dzdo) or in a restricted shell (dzsh).
2. Click Save.
Configuring Roles and Rights to Use Multi-Factor Authentication
You can prepare for multi-factor authentication before or after installing Server Suite components. The steps in this section summarize what to do to finish
configuring multi-factor authentication for login access and executing commands for computers in hierarchical zones. You can use Access Manager, adedit,
or Access Module for PowerShell scripts to complete most of the next steps.
For more information about performing these tasks, see the following documentation:
Planning and Deployment Guide

Administrator’s Guide for Linux and UNIX
Administrator’s Guide for Windows
For example, see the Administrator’s Guide for Linux and UNIX for more detailed information about how to create zones, configure role definitions, and add
command rights for Linux and UNIX computers.
To Configure Multi-Factor Authentication
1. Install Access Manager and other components.
2. Create at least one hierarchical zone.
3. Verify the Identity platform instance URL for the zone by displaying the zone properties, then clicking the Platform tab.
If necessary, you can click Browse to select a different Identity platform instance if you have access to more than one customer-specific Identity
platform instance URL.
4. Assign the predefined require MFA for login role definition to the Active Directory users who have access to computers where you want to require multi-
factor authentication and who are already assigned the UNIX Login or Windows Login role.
Alternatively, you can create one or more custom UNIX or Linux role definitions that include the Require multi-factor authentication system right.
Note that you can also use the Access Module for PowerShell to set the system right described in this step.
5. Define the rights you would like to add to the role and select the Require multi-factor authentication reauthentication option on the Attributes
tab.
After you create rights that require multi-factor authentication, add the rights to the appropriate role definitions and assign the roles to the appropriate
Active Directory users.
Note that you can also use the Access Module for PowerShell to require multi-factor authentication for command execution.
6. Refresh the agent.
For a UNIX computer requiring multi-factor authentication, run adflush -f or restart the agent to test multi-factor authentication for login access and
command execution.
For a Windows computer requiring multi-factor authentication, run dzrefresh from a command prompt. Depending on your permission settings, you may
need to open the command prompt using “Run as administrator.”
Note: When you initially update or install the Server Suite Agent for Windows and configure multi-factor authentication for login, there may be a slight
delay while the cache refreshes. During this short period, users who are required to use multi-factor authentication to log in may only be asked for their
Active Directory credentials. When they logout from their machine, the cache will have refreshed, and they will then be required to use multi-factor
authentication in future login attempts.
Configuration Options for Linux and UNIX Computers
After you have completed the basic steps to enable multi-factor authentication, you might want to customize the configuration to suit your environment or to
address specific scenarios. For example, you might want to enable group policies or set configuration parameters if you want to modify the default multi-
factor authentication operations.
For more information on setting group policies for multi-factor authentication, please see the Group Policy Guide. For information on setting configuration
parameters, see the Configuration and Tuning Reference Guide.
The next sections discuss the most common customization scenarios.
Add Rescue Rights
You should have at least one role with the “rescue” system right for the UNIX and Linux computers in hierarchical zones where you are requiring multi-factor
authentication. This system right enables selected users to log in in cases where multi-factor authentication cannot be completed. For example, if a UNIX
computer where multi-factor authentication is required is disconnected from the network and cannot access the Delinea Platform, only users with the
“rescue” right will be able to log in until the connection to the identity platform is restored.
Configuring Secure Shell (ssh) for Multi-Factor Authentication
If you are planning to require multi-factor authentication for secure shell (ssh) sessions and you want to use a native secure shell package, you should review
the settings in the secure shell configuration file (sshd_config) to be sure that the ChallengeResponseAuthentication option is set to yes.
You can edit the file manually or enable the “Allow challenge-response authentication” group policy to automatically configure this setting. You can find this
group policy in the Group Policy Management Editor under Computer Configuration > Policies > Centrify Settings > SSH Settings. For more information about
adding, enabling, and applying Centrify group policies and the other group policies you can use for secure shell sessions, see the Group Policy Guide.
Enforcing Multi-Factor Authentication for Single Sign-on Login Access
If you use the Delinea OpenSSH package, you can require multi-factor authentication for secure shell connections even for single sign-on access to remote
computers. In this scenario, users must respond to the authentication challenges to open the secure shell connection then be silently authenticated to
additional services and computers. Note that this scenario is only supported if you are using the Delinea version of the OpenSSH package and not supported
for native secure shell packages. To enable multi-factor authentication for single sign-on using secure shell sessions, you must enable and apply the Enable
SSO MFA group policy. You can find this group policy in the Group Policy Management Editor under Computer Configuration > Policies > Centrify Settings >
SSH Settings. For more information about adding, enabling, and applying Centrify group policies and the other group policies you can use for secure shell
sessions, see the Group Policy Guide.
If you are not enabling and applying group policies for Delinea-managed computers, you can manually enforce multi-factor authentication for single sign-on
by setting the secure shell configuration parameter SSOMFA to yes in the /etc/centrifydc/sshd/sshd_config file.
If you enable the group policy or set the parameter and auditing is set to required, users who access a Delinea-managed computer using ssh or PuTTY are
prompted to respond to the multi-factor authentication challenges before starting the shell session. Securing the shell session with multi-factor
authentication prevents unauthorized users from using the secure shell session to connect to remote services and computers.
Require Multi-Factor Authentication for PAM Applications
If you select the “Multi-factor authentication required” system right in a role definition, the PAM applications you add to the role will require users to provide a
secondary form of authentication to log in successfully. You define the forms of authentication available and presented to the user in the authentication
profile you have configured in the Privileged Access Service using the administrative portal.
Note that some applications do not support multi-factor authentication and users might be denied access to applications that they would otherwise be able
to use. For example, if a specific version of an application that you want to use only supports a single layer of authentication—such as a password challenge—
users would be prevented from logging on and using the service even if they are assigned to a role with the predefined login-all PAM application right.
If you want to grant access to applications that only support one layer of authentication in roles where you are generally using the “Multi-factor
authentication required” system right, you must add those applications to the list of applications for which you want to skip multi-factor authentication. You
can update the list of applications for which to skip multi-factor authentication by enabling and modifying the “Specify programs for which multi-factor
authentication is ignored” group policy or setting the pam.mfa.program.ignore configuration parameter in the centrifydc.conf file.
Before assigning roles with multi-factor authentication required to users, you should test access to all of the applications you expect users to access to verify
they won’t be unexpectedly denied access simply because multi-factor authentication isn’t supported. Because the applications that don’t support multi-
factor authentication will depend on the platforms and the versions of the applications you plan to support, testing in your own environment is the only way to
determine which applications to add to the pam.mfa.program.ignore configuration parameter.
The most common applications that are known to only support a single password challenge and response for authentication are ignored for multi-factor
authentication by default. For example, some versions of vsftpd, java, and httpd do not support multi-factor authentication and are ignored by default.
Additionally, while some platforms support multi-factor authentication for all PAM applications, they may not allow you to require multi-factor authentication
for GUI log in. For example, for users running AIX, Solaris, and HP-UX, multi-factor authentication for GUI login is not supported.
Configure Multi-Factor Authentication in Legacy Zones
If you want to configure multi-factor authentication for UNIX and Linux computers in classic zones or in Auto Zone, you must follow different steps than in
hierarchical zones. For multi-factor authentication on computers in the “legacy” types of zones, you must either enable and apply group policies or set
configuration parameters.
You can find these group policies in the Group Policy Management Editor under Computer Configuration > Policies > Centrify Settings > DirectControl
Settings > MFA Settings. For more information about adding, enabling, and applying Delinea group policies, see the Group Policy Guide. For more information
about setting configuration parameters, see the Configuration and Tuning Reference Guide.
Configuration Options for Windows Computers
The following sections describe multi-factor authentication configuration options for Server Suite-managed Windows computers. In addition to these
options, you can use group policies to customize basic operations for connecting to the Delinea Platform and multi-factor authentication on Windows
computers. For more information on these group policies, please see the Group Policy Guide.
You can find the group policies for multi-factor authentication and the grace period on Windows computers in the Group Policy Management Editor under
Computer Configuration > Centrify Settings > Windows Settings > MFA Settings.
To set the grace period, use the following group policies:
Configure multi-factor authentication lock screen grace period. This group policy enables the grace period for lock screen.
Configure multi-factor authentication user privilege elevation grace period
This group policy allows the administrator to set the grace period for privilege elevation for users.
Reset Password
Password reset is a very popular self-service capability for Identity and Access Management solutions: It reduces calls to the help-desk and enables users to
become productive quickly. The system allows the user to make a limited number of reset password requests within a specified period.
Note: This feature does not enable the user to unlock their account.
To reset your password (user instructions):
1. On the login screen, click the Forgot Password link.
A prompt appears asking the user name. (If the user already entered their username using the login screen, it appears in this user name field.)
2. Complete the MFA challenges, which are based on the password reset profile.
3. A new prompt asks you to enter a new password and confirm it.
After resetting the password, you can log in using the normal login screen.
Disable Self-Service Password Reset
Configuring this policy setting allows the administrator to force disable the password reset.
You can use this group policy to allow the administrator to force disabling of the password reset feature. There are two settings for this group policy:
Enabled: If this policy is set to Enabled, the self-service password reset feature on the machine is disabled, including the cloud-enabled self-service
password reset.
If this policy is set to Disabled or Not Configured, the self-service password reset feature on the machine follows the cloud policy setting (cloud
policy settings can be found at: Policy Settings > User Security Policies > Self Service > Password Reset). The cloud policy settings are
accessed through the Admin Portal.
Note: The Admin Portal is available after you log in to a Delinea Platform instance.
Configure Offline Multi-factor Authentication and Rescue Users
When a Windows computer that is running a Server Suite Agent is not configured to use multi-factor authentication, you can use a local account to rescue
that system when it cannot connect to the Delinea Platform.
Local users do not require MFA challenge. For non-safe mode in Windows Operating System:
With Privilege Elevation Service (zone mode) a local user can log in without MFA whenever they cannot connect to the Centrify Platform. The
exception is that the local user does not assign roles for either "Window login permit" or "rescue user."
Without the Privilege Elevation Service (zoneless mode) a local user is allowed to log in without MFA.
For safe mode in Windows Operating System, a local user can only log in as a rescue user. To set a rescue user for zone mode, go through the Access Manager
to assign roles. To set a rescue user for zoneless mode, go through Group Policies to configure.
If a computer that is joined to a zone starts in Safe Mode, only users who are assigned a Login role with the system rescue right selected will be able to access
the machine. These users will not be required to use multi-factor authentication.
Users who are required to use multi-factor authentication to log in to their Windows workstations can set up an offline MFA profile to use as a second form of
authentication in the event that their machine cannot connect to the Delinea Platform. These users will see a system notification urging them to set up this
passcode each time they log in to their machine until they configure it.
Users set up their offline MFA profile in following way:
To set up an offline MFA profile:
1. Right click the Delinea notification icon in the system notification area, and select Setup Offline MFA Profile.
2. Click Next to begin the Offline Authentication Wizard.
3. Select one of the following methods to create a authenticator account profile on your mobile device:
Scan barcode
If you select this option, a QR code is displayed for you to scan using your mobile authenticator application. You can use either the Delinea
application or a third-party authenticator application.
Manual entry
If you select this option, you must manually enter the displayed account profile information into your authenticator application.
Program YubiKey
If you select this option, you can use a YubiKey as the second form of authentication. You'll then need to select which slot on the YubiKey to use,
and whether or not to use Yubikey's touch-to-sign feature.
4. Enter the passcode that is generated after you have created your authenticator profile. Click Next.
5. Click Finish to exit the Wizard.
After a user has set up their offline MFA profile, they will be prompted to enter the mobile passcode generated by their authentication application or YubiKey
as the second form of authentication when they attempt to log in to their machine if it cannot connect to the Delinea Platform instance.
Note: If you have already set up your offline MFA profile and want to reconfigure (override) it, you will be prompted for multi-factor authentication. That
profile is set in the MFA Login Policy.
Require Multi-Factor Authentication using Computer Roles
Computer roles can enable you to group and provide access to computers through role assignments. One strategy you might find useful is to use computer
roles to control where multi-factor authentication should apply. For example, you might have several computers with highly sensitive material where you
want to ensure all user access will require multi-factor authentication. To accomplish this goal, you can configure a computer role, then add and remove
computers with sensitive information to control whether multi-factor authentication is required.
To require multi-factor authentication based on a computer role
4. Type the role name and, optionally, a role description, then select <Create group> for the Computer group to create a new Active Directory group for
computers.
For example, to create a new Active Directory security group for the computers with sensitive information, click Browse to select the Active Directory
location for the new group. If you are using the default deployment structure, you would browse to a location similar to acme.sales.org/ACME/Computer
Roles then type a group name such as mfa_required_consols, select a scope, and click O K.
5. Click O K to save the new computer role.
6. Add the computers that require multi-factor authentication for access to the mfa_required_consoles Active Directory security group.
As you add computers to the Active Directory security group, the computers are listed as Members of the computer role.
7. Expand the computer role you created in Step 4, select Role Assignments, right-click, then select Assign Role.
For example, if you created a new computer role with the role name CR_MFA_required, expand that computer role name to select Role Assignments,
right-click, then select Assign Role.
8. Select the predefined require MFA for login role definition, then click O K.
9. Select All Active Directory accounts, then click O K.
Using Multi-Factor Authentication when there are Selective Cross-Forest Trusts
If you have domains in different forests that have a two-way selective trust relationship, any computer or user accounts that are used to log on to the remote
forest must be granted the “Allowed to authenticate” right on the domain controllers in both forests to get role information.
In addition to granting the “Allowed to authenticate” right to users and to computers with the Server Suite Agent for Windows installed, the right must also be
granted to computers that host your Cloud Connectors. <
After you grant these computers and users the “Allowed to authenticate” right for the domains in both forests, users that are assigned a role with a multi-
factor authentication right for login and privilege elevation will be able to authenticate using any of the authentication mechanisms that you have assigned to
them.
If a connector is not allowed to authenticate on the remote domain controller, some multi-factor authentication mechanisms may fail to authenticate users.
Configuring MFA with RADIUS for Privilege Elevation Service for Windows Checklist
This document provides a configuration checklist for 3rd party multi-factor authentication providers such as Duo, Okta, SecurID (or any other vendor that
provides a RADIUS service) to provide identity validation with the Privilege Elevation Service in the Microsoft Windows platform.
If you have an identity service provider (such as Duo, Okta, SecureID, and so forth) that you use for MFA logins, you can integrate authentication and privilege
elevation with your identity provider and the RADIUS protocol to require MFA for privilege elevation tasks, such as Run with Privilege and New Desktop.
Make sure that you work with your RADIUS expert along with your network and directory services lead administrators during the design and configuration
tasks.
The checklist below includes links to documented procedures.
Note: If you use Privileged Access Service, although you can enable MFA with RADIUS, the recommended practice is that you use the native integration.
Step# Notes
Step
RADIUS requirements
Gather the following

settings for your RADIUS
service: IP address or fully
1
qualified domain name
Port Timeout settings
Pre-shared secret
Verify that you can

generate a RADIUS one-
2
time password
successfully.
Verify that identity
Step# Notes
Step
authentication is working
3
correctly with your
RADIUS system.
Have access to someone

who is knowledgeable
about your RADIUS
4 system and can answer
questions or help
troubleshoot issues, if
needed.
Windows and Active

Directory requirements
for RADIUS configuration
A Windows computer to
use as a RADIUS client for
5 initial testing, including:
Client name Client IP
address
Make sure that client

systems can reach the
RADIUS server over the
network (check your
firewall settings). You may
6
need help also from your
network team if your
RADIUS cluster has a
load-balancer in the front
end.

access to the designated
Windows computer so
7
that you can install
software and do
configurations.
You have Active Directory

account access so that
8 you can modify group
policies that apply to the
target computer.
You have access to the

9 Group Policy Management
Console.
Your Active Directory

expert must decide how
the group policy layout
and scope will be designed
10
so that the group policies
Step# Notes
Step
are applied to the clients

based on their RADIUS
service availability.
Authentication and
Privilege Elevation
Services Requirements
for RADIUS configuration

11 is installed on the client For details, see "Run the setup program on a Windows computer" in the Administrator’s Guide for Windows.
computer.
The Agent for Windows is

installed on the client
system, you've configured
12 the system to work with For details, see "Install agents for Windows" in the Administrator’s Guide for Windows.
Privilege Elevation
Service, including joining
the computer to a zone.

access to Access
13
Manager so that you can
manage roles and rights.
The group policy

templates from release
19.6 or later are installed.
For details, see "Install group policy extensions separately from Access Manager" in the Administrator’s Guide for
14 For RADIUS configuration,
Windows.
you need at least the
Centrify Windows settings
group policies.
If you want to capture the

RADIUS events in your
In GPME, go to computer Configuration > Policies > Centrify Audit Trail Settings > Centrify Global Settings > Send
SIEM system, make sure
15 audit trail to log file (this is not configured by default). For details, see "Send audit trail to log file" in the Group Policy
the Audit trail is
Guide. For details, see "Send audit trail to log file" in the Group Policy Guide.
configured to go to the
local log file.
You have a role and user to

test with. Make sure the
role has rights for privilege Make sure that you can elevate privileges successfully for that user and role before you try to configure RADIUS
16
elevation, such as New authentication.
Desktop rights or Run as
Role.
Configure a system to use

RADIUS for privilege
elevation (using group
policies)
Configure the following group policies: Windows > MFA Settings > Specify the authentication source for privilege
Step# Notes
Step
elevation : set this policy to RADIUS Authentication. Windows > MFA Settings > Remote Authentication Dial-In User
Service (RADIUS) Settings > Enable Remote Authentication Dial-In User Service (RADIUS): enable this policy. Specify
Enable and configure the the RADIUS connection timeout: Configure to match your RADIUS timeout setting. Specify the RADIUS server IP
17
RADIUS group policies. address: enter your RADIUS IP address. Specify the RADIUS server port number: enter your RADIUS port number (the
default is 1812). For details, see "Remote Authentication Dial-In User Service (RADIUS) Service Settings" in the Group
Policy Guide. For details, see "Remote Authentication Dial-In User Service (RADIUS) Service Settings" in the Group
Policy Guide. After you update the policies, do a group policy update on the Windows client computer.
Configure the role to

For example: Right-click your test role and choose Properties. The Role Properties dialog box opens. Click the Run As
require re-authentication
18 tab. Select Re-authenticate current user and then select Require multi-factor authentication. Click OK to apply the
using multi-factor
changes.
authentication.
Run dzflush to make sure

that the agent has the
19 For details, see "Using dzflush" in the Administrator’s Guide for Windows.
changes from Access
Manager.
The RADIUS secret is unique to each system and will match the secret that the RADIUS server has. You can set the
pre-shared secret by either of the following methods on the client computer: Run the Set-CdmRadiusSecret cmdlet
Set the RADIUS shared
20 to set the RADIUS shared client secret. For details, see the DirectAuthorize PowerShell cmdlet help. Use the Agent
secret.
Configuration settings dialog box to configure the RADIUS server, including the pre-shared secret. For details, see
"Configuring agent settings for the Identity Services Platform" in the Administrator’s Guide for Windows.
TEST AND VERIFY
Verify that a user can For example, if your role has New Desktop rights: Right-click the System Tray and select New Desktop. In the dialog
elevate privileges by box that appears, select your test role and click OK. If the RADIUS authentication has been configured successfully,
21
entering the RADIUS one- you are prompted to enter a password for RADIUS authentication. Enter the password and click Next to continue. You
time password. can also view the audit trails for the successful authentication in the system's event log.
Verify that a user cannot

elevate privileges after
22 entering an incorrect
RADIUS one-time
password.
Troubleshoot Multi-Factor Authentication
Because multi-factor authentication for Delinea-managed computers relies on the infrastructure of the Privileged Access Service, troubleshooting the
configuration of your environment and potential connectivity issues can be challenging. To help you test and verify the proper configuration of an integrated
environment, Delinea provides several diagnostic tools.
The following Delinea diagnostic tools are available on Windows computers:
Diagnostics Tool. The diagnostics tool is available through the Agent Configuration service, and is described in Viewing Windows diagnostics.
Privilege Elevation Service Diagnostic Information panel (formerly the DirectAuthorize Agent Control Panel) The information panel is
available from the Agent Configuration service, and is described in the Administrator’s Guide for Windows.
The dzdiag command. The command is available from the Windows command prompt, and is described in the Administrator’s Guide for Windows.
The following diagnostic tool is available on UNIX and Linux computers:
The adcdiag program. The program is available from the UNIX or Linux command line, and is described in Viewing UNIX and Linux diagnostics.
Viewing Windows Diagnostics
The Server Suite Agent for Windows provides logging and diagnostic services. If you have administrative access on a local computer, you can generate
diagnostic information about the operation of the agent for Windows and view and save the current content of the log file from the agent configuration panel.
For example, you can generate diagnostic information about user sessions, user roles, desktops, and elevated account access, as well as detailed
information about auditing from the agent configuration panel.
There are three different types of diagnostics information available:
Centrify Audit & Monitoring Service provides the diagnostic information related to the auditing and monitoring service.
Centrify Identity Platform provides the diagnostic information related to Privileged Access Service, such as for MFA. This diagnostics tool runs the
following tests:
Agent Service Connectivity Check: Checks to see if the agent is in service, and if the agent is running in a normal state. Also determines
whether the agent is in a zone, or is configured to use zoneless mode.
Centrify Connector Connectivity Check: Determines whether all connectors in the network can be connected properly.
Centrify Identity Platform Certificate Validation Check: Checks whether the certificates (IWA and cloud) have been installed properly.
Also determines whether the agent can be connected without a trusted certificate problem.
Centrify Identity Platform Connectivity Check: Determines whether a connection to the cloud tenant is functional. Checks for problems
with DNS, the firewall, and proxy server settings.
MFA Configuration Check: Determines whether the local computer has been configured properly. If the computer is in a zone, the test also
checks whether MFA complies with the configuration defined in the zone.
MFA Role and Permission Check: Verifies whether role permissions are set properly in the Privileged Access Service Admin Portal.
Offline MFA Provisioning Check: Determines if the computer has been configured with an offline MFA profile or not.
Centrify Privilege Elevation Service provides the diagnostic information related to privilege management.
You can view these diagnostics tools either from the Windows system tray or from the agent configuration panel.
For more details, see the Administrator’s Guide for Windows.
To view diagnostics from the Windows system tray:

2. In the Windows system tray, right-click the Centrify icon and click Troubleshooting, then select the service for which you want to view diagnostic
information (your options may vary depending on what services are enabled on the computer):
Centrify Audit & Monitoring Service opens a dialog box with a text-based summary of diagnostic auditing and monitoring information.
Centrify Identity Platform runs a series of connectivity tests and lists out the results of each test.
Centrify Privilege Elevation Service opens a dialog box with a text-based summary of diagnostic privilege elevation information.
To generate diagnostics or view the log file from the agent configuration panel:

3. Select the service for which you want to view information:
Centrify Audit & Monitoring Service opens a dialog box with a text-based summary of diagnostic auditing and monitoring information.
Centrify Identity Platform runs a series of connectivity tests and lists out the results of each test.
Centrify Privilege Elevation Service opens a dialog box with a text-based summary of diagnostic privilege elevation information.
4. Click Settings.
6. Click Diagnostics to generate diagnostic information.
7. Select the Diagnostic Information displayed, right-click, then select C o p y to copy and paste the output to a file for further analysis.
8. Click View Log to display the current log file for the local agent.
9. Click Options to see or change the location of the log file or the level of detail recorded in the log file.
View UNIX and Linux Diagnostics
The adcdiag program performs a set of tests to check for access to a Delinea server authentication instance, the availability of one or more connectors,
whether the computer is joined to an Active Directory domain, and whether the connector you are attempting to use is configured to use integrated Windows
authentication.
To perform the set of tests to verify a UNIX or Linux computer can be configured to use multi-factor authentication, run the following command:
/usr/share/centrifydc/bin/adcdiag
By default, the command displays the test results in standard output (stdout) and generates a diagnostic report in the /var/centrify/tmp directory with a
dated time stamp similar to the following:
adcdiagCheckingReport_20160307_151128.log
If any of the tests returned errors or warnings, you can check the diagnostic report for additional information, including suggestions for resolving any issues
found. For details about the command-line options available for the adcdiag command, see the man page for the command.
Address Certificate Errors
Depending on how your Windows environment is set up, you may have to specify a trusted host certificate in order to enable multi-factor authentication. If
you do not do this, you will see an error message during installation and configuration.
In a production environment, it is strongly recommended that you specify an existing trusted host certificate from a known third-party certificate authority,
such as GoDaddy or Verisign. Using a self-signed certificate in a production environment can leave your environment vulnerable to security breaches.
For details about importing a trusted host certificate, see To import the certificate manually to a local Windows computer.
Manage Passwords
Privileged Access Service cannot manage the password for a user if multi-factor authentication is required for the user to log in. You can still add a multi-
factor authentication-required user account to a PAS resource – with “Manage this password” unchecked - to log in from PAS. However, you may see the
status as “Failed” due to system delay. If the operation is successful, then no status will be shown for this user.
Troubleshoot Login Issues
If you have installed the agent and enabled the privilege elevation service and users can't log in for some reason, try to log in to the agent system in either
Windows Safe mode or rescue mode.
We also recommend that you assign some users to the "Rescue - always permit login" role; that way, they can still log in even if the agent providing MFA isn't
working for some reason. For details, see Configuring offline multi-factor authentication and rescue users.
Customize the HTTP Proxy Configuration
Typically, a Unix/Linux system running the Server Suite Agent for *NIX is located on a private network. By default, the agent uses the Cloud Connector as a
HTTP proxy server for connecting to the Cloud Connector to, for example, perform multi-factor authentication.
However, you may prefer to reconfigure the agent to use a different proxy server. The following sections explain how to do that.
Requirements
The configuration described in these sections require the following conditions:
The HTTP proxy server is used only for communication between the agent and the Delinea Platform. It does not provide proxy services for another
purpose.
All of the Agents must use the same proxy server.
You have installed DirectControl on the system.
Also note the following points:
All of the agents use a single proxy server configuration (multiple configurations not supported)
The machine password keytab must contain at least two versions of the key.
This proxy server configuration supports all zone types.
The information in the following sections does not apply to Mac OS X.
Configure the Agent to Use a Custom HTTP Server
To configure the Agent to use a custom HTTP server, use the following command syntax to set the custom HTTP proxy server:
adwebproxyconf --set,-S [--username,-u <username>]

[--password, -p <password>] [--machine,-m]
[--server,-s <servername:port|>]
[--authreq,-r <true|false|>] [--authtype, -t <type>],
'--version,-v','--help,-h' and '--verbose,-V'
For example, enter the following command (replacing the angle brackets and placeholders with actual values):
adwebproxyconf --set --username <username>

--password <password> --server <servername:port>
–-authreq <true> --authtype <type>
Change the value of adclient.cloud.direct.connection to false.
Verify that the new configuration works. Enter:
adwebproxyconf --test --cip <cip url>

--server <servername:port>
For more information, see Command Reference.
HTTP Proxy Credential Local Storage
This section describes how the HTTP proxy credentials are stored locally on the Unix/Linux system that’s running the agent.
The HTTP proxy credentials are be stored only in the local kset file: /var/centrifydc/httpproxy.cred
This httpproxy.cred file is only readable and write-able by root.
For security, remove httpproxy.cred. from the system when you remove the system from the domain.
For security, the proxy user's password is encrypted before being stored in httpproxy.cred.
Password Encryption
The proxy user's password is encrypted using the system's principal key, which is normally stored in /etc/krb5.keytab.
It should use the latest key to do encrypt the password. By default, it uses AES256-CTS-HMAC-SHA1-96 encryption.
If the key for a particular encryption type is not available, the Agent uses the next preferred and available encryption type that has a key in the system’s
keytab file.
When the system password changes, the agent uses it to re-encrypts the proxy server password. The system keytab file keeps the two latest versions of key.
If the Agent on the Unix/Linux system has FIPS Mode enabled, only a FIPS-compliant encryption type is allowed to encrypt the proxy credential password.
If a password is encrypted with non-FIPS-compliant encryption type, even if the machine keytab contains a valid key, the agent will not be able to decrypt it. If
that happens, set the proxy password again so that it is encrypted using a FIPS-compliant encryption type.
Encrypted Password Storage
The encrypted password and relevant information is represented in ASN.1 as shown below and is encoded using ASN.1 Basic Encoding Rule (BER) as defined in
Section 5.1 of the RFC 4511 LDAP Protocol (https://www.ietf.org/rfc/rfc4511.txt):
username STRING,
kvno UInt32,
etype Int32,
cipher OCTET_STRING
}
Int32 ::= INTEGER (-2147483648..2147483647) -- signed values re-presentable in 32 bits
UInt32 ::= INTEGER (0..4294967295) -- unsigned 32 bit values
Where:
username: The proxy user's name.

kvno: The version number of the key under which the data is encrypted
etype: The encryption type used to encrypt the cipher. The encryption type number MUST be a type that is supported by the Kerberos protocol.
cipher: The encrypted password
Local Machine Account Support
In some cases, the current system account’s Kerberos credentials should be configured, the username be S-1-5-18, and the cipher part must contain an octet
string with 0 length.
Command Reference
adwebproxyconf
The adwebproxyconf command configures the HTTP proxy server settings and credentials on the local system. Typical use cases are:
Set up the HTTP proxy credential to be used by agent.

Delete the HTTP proxy credentials.
Get information about the HTTP proxy credentials.
Test the proxy connection using the configured credentials
Test the proxy connection using the supplied credentials
Requirements
Only root can run this command.

To run, the system must have joined a zone.
Synopsis
adwebproxyconf --set,-S [--username,-u \<username\>]

[--password, -p \<password\>] [--machine,-m]
[--server,-s \<servername:port\|""\>]
[--authreq,-r \<true\|false\|""\>]
[--authtype,-t \<basic\|digest\|ntlm\|negotiate\|anyauth\|""\>],
'--version,-v','--help,-h' and '--verbose,-V'
adwebproxyconf --delete,-D
adwebproxyconf --list,-L
adwebproxyconf --test,-T \<--cip,-c \<cip url\> \>
[--server, -s \<servername:port\>]
[--username,-u \<username\>]
[--password, -p \<password\>] [--machine,-m]
Command Options
--set,-S
Set the HTTP proxy server and credentials for the local system. After using adwebproxyconf -S, use adreload to force the agent process (adclient) to reload
its configuration files.
the configuration properties in the /etc/
centrifydc.conf file and in other files in the /etc/
centrifydc directory.
--delete,-D
Delete the HTTP proxy credentials from the local computer and reset the HTTP Proxy configurations in centrifydc.conf:
HTTP Proxy Server

HTTP Proxy authentication type
HTTP Proxy authentication required
--list,-L
List the HTTP proxy username and server from the configuration on the local system.
--test,-T
Test the HTTP proxy credential using configured or supplied settings.
--username,-u <username>
Proxy username. If a username is not supplied but --password is supplied, the username defaults to Administrator'
--password, -p <password>
Proxy user's password, if not provided, will be prompted
--machine,-m
Use local machine account for proxy authentication, and SPNEGO authentication is used.
This option cannot be used with -u, -p, or -t.
--authreq,-r <true|false|"">
Specify if HTTP Proxy authentication is required in centrifydc.conf, Optional.
Can use individually or with other options.
--authtype,-t <basic|digest|ntlm|negotiate|anyauth|"">
Specify if HTTP Proxy authentication authentication type in centrifydc.conf. Optional.
Please refer to above section for valid values.
--server, -s <servername:port|"">
Specify HTTP Proxy Server to use to update to centrifydc.conf. Optional.
Empty string unsets the value in centrifydc.conf.
--version,-v
Specify the version.
--help,-h
Get command line help.
--verbose,-V
Get additional details while the settings are being applied.
--cip,-c <cip url>
Specify the URL of the identity platform.
Must be specified.
--server, -s <servername:port>
Specify HTTP Proxy Server to test.
If not specified, get it from centrifydc.conf
--username,-u <username>
Proxy username.
If not specified, get it from proxy cred file.
-–password,-p <password>
Proxy user's password.
If username is specified, but password is not, prompt for it.
If both username and password are not specified, get it from proxy cred file.
-–machine,-m
Use local machine account for proxy authentication, and SPNEGO auth type is used.
This option cannot be used with -u, -p, or -t.
This test option always use the proxy credential to check the connection to CIP thru the specified HTTP Proxy server.
You can also use the adcdiag command to check HTTP proxy server settings.
Configure RADIUS Silent Authentication
If you have an identity service provider (such as Duo, Okta, SecureID, and so forth) that you use for MFA logins and you've integrated that with Server Suite
and you have a RADIUS server for MFA with your identity provider and also a RADIUS server integrated with Server Suite, you can set up silent authentication
so that your users don't have to enter their passwords or security question answers twice.
You can configure the credential provider to silently send the user's password as the first response to the authentication workflow. This feature prevents
prompting the user for password multiple times when a 3rd party radius is being used as the authentication mechanism.
You can deploy these registry settings as group policies.
To control this new feature we have 3 new registry settings:
SilentAuthPromptDetectionRegex (string)
This is a regular expression that we match against an authentication prompt that RADIUS sends us. If there is a match, we'll try to automatically
respond. For example, if the RADIUS prompt is "Enter your password" we can set this regular expression to
.*password.*
SilentAuthPromptResponseType (uint):
This setting controls the kind of response we provide.
0 - (default) No auto-response: The service prompts the user for the password even if there's a regular expression match.
1 - Silent auto-response: The service responds with the same password that the user just entered as a Windows login credential.
2 - Fixed response: Instead of responding automatically with the password, we respond automatically with a fixed response (a static string, for example
"This is an automatic response"). Use the SilentAuthPromptFixedResponse to store the fixed response text.
SilentAuthPromptFixedResponse (string):
The fixed response if the SilentAuthPromptResponseType is configured as 2. Use this setting to store the fixed response, such as "This is an
automatic response."
When you create these registry entries, put them in HKEY_LOCAL_MACHINE\SOFTWARE\Centrify\DirectAuthorize\Agent.
Certificate Auto-Enrollment Quick Start
If you are an administrator of Server Suite-managed UNIX or Linux computers, you can use this guide to help you set up a Certificate Authority with the
Microsoft Windows certificate auto-enrollment feature to automatically manage certificates for UNIX and Linux computers in your domain. While there are
many ways to deploy certificates, this guide describes how to use Active Directory server roles and Windows Group Policy to set up automatic enrollment.
This area includes the following topics:
Working with a single CA for Unix computers

Preparing a computer to be a CA
Adding a trusted root certificate to the group policy
Enabling auto-enrollment
Assigning the certificate template to the CA
Retrieving certificate revocation lists
Working with a Single Certificate Authority for UNIX Computers
The Server Suite Agent uses the Microsoft Windows public key infrastructure (PKI) to obtain the certificates used by your Server Suite-managed UNIX or
Linux computers that are joined to a domain. By joining to the domain, these computers become eligible for auto-enrollment.
The most basic configuration of the Windows PKI environment utilizes a Windows server as the Certificate Authority (CA) that issues and manages security
credentials and public keys through the exchange of encrypted digital certificates. The Server Suite Agent then uses the Microsoft Windows certificate auto-
enrollment feature of the Certificate Authority to make certificates available to UNIX computers.
This section describes how to set up a basic environment that has a single, enterprise root Certificate Authority (CA). In this scenario, the Certificate
Authority is a Microsoft Enterprise Certificate Server that issues all certificates. In a production environment, you may have more complex requirements that
include multiple CAs configured for a domain. However, setting up this sample environment should give you enough information to extend your PKI
configuration to a more complex environment.
The Server Suite Agent requires a Microsoft Windows Server to be configured as the Certification Authority (CA) for the Active Directory forest. Additionally,
auto-enrollment is not supported for certificates issued by other public or private Certificate Authority services or organizations.
Preparing a Computer to be a Certificate Authority (CA)
The first step in configuring the environment is to identify a computer to be the Certificate Authority server for the Active Directory forest. This computer
must be connected to a network with a server that has Windows Server 2008 (or later) Domain Name Service installed, and it must be joined to the Active
Directory domain. In most cases, the computer designated to be the CA should not be a domain controller in a live production environment. To configure the
computer as a Certificate Authority, you must install Microsoft Internet Information Services (IIS) and Certificate Services.
Microsoft Internet Information Services (IIS) are required to handle Certificate Revocation List (CRL) requests made by the authentication service and to
provide the virtual directories required to issue and manage certificates.
Certificate Services are required to enable the computer to act as a Certificate Authority (CA) and issue certificates to other computers that join the domain.
The Application server role, which installs IIS, and the Certificate Services server role must be on the same computer. Therefore it is recommended that you
install IIS at the same time you install Certificate Services.
What's Required to Install Certificate Services
Before installing Certificate Services, check that you have the following:
Account credentials for an account that is an Enterprise Administrator and a Domain Administrator of the forest root domain of the Active Directory
forest.
A computer with Windows Server 2008 Enterprise Edition or later. Previous versions of Windows Server do not support auto-enrollment within the
certificate templates. In addition, the computer must be running Enterprise Edition because Standard Edition does not support the V2 or V3 certificate
templates that are required for auto-enrollment.
Active Directory services must be installed on the Certificate Services server. If you install the Certificate Services server role on a domain controller,
no further action is required. When you promote a computer to be a domain controller, the Active Directory services are installed automatically.
Note: This guide details how to configure auto-enrollment on a computer running Windows Server 2012 R2. For information on configuring auto-
enrollment for computers running other versions of Windows Server, please visit the Microsoft website.
Adding the Required Server Roles to Make the Computer a Certificate Authority
After you have verified that you have an appropriate account and computer configuration, you can use Server Manager to add the appropriate server roles.
To install IIS and Certificate Services on a Windows Server
1. Open the Server Manager Dashboard and click Add Roles and Features.
Click Next.
2. For Installation Type, select Role-based or feature-based installation, then click Next.
3. Ensure that Select a server from the server pool is selected and highlight the server on which you would like to install roles and features. Click
Next.
4. Select Active Directory Certificate Services, then click Add Required Features in the pop-up window.
Click Next.
5. Click Next to accept the default selections for Select Features.
6. Click Next on the notification that you will be unable to change the domain settings after installing Certificate Services.
7. Select Certification Authority and click Next.
8. Click Install.
After Windows restarts, you will see a new Role in Server Manager called AD CS. In the following procedure, you will configure this role to allow your server to
act as a Certification Authority.
Configuring the Certificate Authority
1. Click the notification icon in the Server Manager command bar to open the Add Roles and Features Wizard.
2. Click the link, Configure Active Directory Certificate Services on the destination server.
3. In the AD CS configuration screen, verify that you are logged on as an administrator and click Next.
4. Select Certification Authority and click Next.
5. Select Enterprise CA and click Next.
Note: You must be a member of both the Enterprise Admins group and the Domain Admins group to configure an Enterprise Certificate Authority.
6. Select Root CA and click Next.
7. Select Create a new private key and click Next.
8. Accept the defaults for the cryptographic provider, key length, and hash algorithm. Click Next.
9. Enter a name for the Certificate Authority or accept the defaults, and click Next..
Note: After the Certificate Authority is configured, you will not be able to change the name.
10. Specify the validity period of the certificate, click Next.
11. Accept the default location for the certificate database and click Next.
12. Review your CA configuration and click Configure.
13. Click Close when the confirmation message appears, and restart the server to retrieve a certificate from the CA.
Adding a Trusted Root Certificate to the Group Policy
You can use the certificate snap-in to make a copy of a certificate to use on another computer, or to create a backup copy.
In order to establish a chain of trust for your PKI environment, you identify the copy of the CA you just created as a trust anchor.
To establish the CA as a trust anchor, add the root certificate for the CA to the Trusted Root Certification Authorities container in the group policy
object that defines the IP Security policies.
To Add a Trusted Root Certificate to the Group Policy Object
1. Open the Certificates (MMC) snap-in.
If the Certificates snap-in is not available, you can run MMC and click File > Add/Remove Snap-in to add it.
2. Select Computer account, and click Next.
3. Select Local computer, then click Next.
4. Click Certificates > Trusted Root Certification Authorities > Certificates.
5. Select the root certificate generated by the CA you created in the previous procedure, then double-click it to see its Properties page.
6. Click the Details tab; then click Copy to file to start the Certificate Export Wizard. In the wizard, make the following selections:
File format: DER encoded binary X.509 (.CER)

File Name: Anywhere on the local server
Include all certificates in the certification path: No
7. Open the Group Policy Object Editor and select the group policy object that defines the IP Security policies.
Click Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root
8. Select Trusted Root Certification Authorities, right click, and select Import to open the Certificate Import Wizard.
9. Click Next on the Welcome screen.
10. Browse to find the root certificate you copied in Step 6, then click to accept the default values on each screen.
11. Click Finish to complete the wizard.
The root certificate is now in the Active Directory Trusted Root Certification Authorities container. Certificates in this container are downloaded to any
computer that joins the domain to establish trust for the root CA.
Enabling Auto-Enrollment
The Server Suite Agent uses the Microsoft Windows certificate auto-enrollment feature to make certificates available to UNIX computers. If auto-enrollment
is enabled, when a UNIX computer joins a domain, the Server Suite Agent requests certificates from the CA based on particular templates, and installs them
on the joined computer.
To enable auto-enrollment, you must do the following:
Enable auto-enrollment for the group policy.

Create a certificate template with auto-enrollment enabled.
Enabling Auto-Enrollment for the Group Policy
To enable auto-enrollment for the group policy:
1. Open the Group Policy Management Editor and select the group policy object that defines IPsec policies.
Click Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services
Client - Auto Enrollment.
2. Double-click Certificate Services Client - Auto-Enrollment, select Enabled, and check the following boxes:
Renew expired certificate, update pending certificates, and remove revoked certificates
Update certificates that use certificate templates
3. Click O K to save the auto-enrollment settings.
Creating a Certificate Template
To configure a template with auto-enrollment:
1. Open the MMC Certificate Template snap-in.
Another way to open the Certificate Template console is to open the Certification Authority console, right-click Certificate Templates, and select
Manage.
2. Select a template, then right-click and select Duplicate Template to create a new template that you can modify.
For example, select the Workstation Authentication template.
3. On the Properties page for the new template, do the following:
1. Select the General tab and enter a name for the template.
2. Select the Security tab and select Domain Computers. Then select Read and Autoenroll permissions.
3. Select the Subject Name tab. For Subject name format, select Fully distinguished name.
4. Select the Extensions tab. Then select Application Policies.
5. Click Edit. Client Authentication should already be shown.
6. Click A d d, then scroll and select Server Authentication.
7. Click O K.
4. Click O K to save the new template.
Assigning the Certificate Template to the CA
You can now assign the newly created template to the Certificate Authority. Whenever a computer joins the domain, the CA issues a certificate based on the
template, and the Server Suite Agent downloads the certificate to the computer.
To assign the template to a CA:
1. Open the Certification Authority console.

2. Click Certification Authority > CA_name > Certificate Templates, where CA_name is the container for the CA you set up earlier in Preparing a
computer to be a Certificate Authority (CA).
3. Right-click and select New > Certificate Template to Issue. Select the template you just created and click O K.
The root CA is now set up to issue certificates based on the template you created.
Retrieving Certificate Revocation Lists (CRLs)
Generating a certificate revocation list (CRL) is the method a Certificate Authority (CA) uses to maintain the validity of the certificates that it issues. A CRL
contains a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked or are no longer valid, and therefore should
not be relied upon. The agent retrieves CRLs from CAs after specific events (such as joining a domain) and at specific intervals to determine which
certificates, if any, have been revoked, and thus whether to request new certificates.
Note: The current version of the Server Suite Agent only supports complete certificate lists, not delta CRLs, which only describe the updates
since the complete list was published.
Generating a Certificate Revocation List (CRL)
A CRL is generated by a CA and contains a list of certificates to revoke from the list of certificates that the CA has issued.
Typically, a CA automatically generates a CRL at a specified interval, anywhere from two hours to one year, at which point the new CRL with the list of revoked
certificates is available for clients to request.
The CRL itself contains the interval period, which allows clients, such as Server Suite Authentication Service, to determine when to request a new CRL. See
Retrieving a certificate revocation list and verifying certificates for information about retrieving CRLs.
In addition to automatic generation of a CRL, an administrator can use specific Active Directory utilities that allow them to manually revoke certificates and
publish a CRL on the CA. In this case, the CRL-publishing interval is reset so the next automatic publishing operation will occur in the appropriate amount of
time.
Retrieving a Certificate Revocation List and Verifying Certificates
At specific times (when the UNIX system joins a domain, the administrator issues the adgpupdate command, or the group policy refresh interval occurs), the
Server Suite Agent performs certain tasks, including determining whether to retrieve a CRL (Certificate Revocation List). Specifically, the agent does the
following:
Identifies the CA that issued certificates for the system.
Looks at the refresh interval in the current CRL to determine whether to retrieve a new CRL.
If the interval has expired, retrieves a new CRL by using the IIS Web Server for the CA.
Verifies the currently issued certificates against the CRL and requests new certificates for certificates that have been revoked.
Note: When you manually revoke a certificate, it is possible that the certificate will appear as valid even after running the adgpupdate command to
trigger an IPsec update. When you revoke a certificate, the Server Suite Agent first looks at the current CRL to determine the validity of the certificates
that have been issued. In this case, the newly revoked certificate still appears as valid. Immediately afterwards, because of the IPsec update, the agent
requests a new CRL. The new CRL shows that the certificate in question is invalid, but the agent will not look at the new CRL until the next scheduled
update, or until you run the adgpupdate command again. Therefore, to be certain to have current information, if you manually revoke certificates, you
can issue the adgpupdate command twice in sequence.
Reports and Events
Reporting Admin Guide
Audit Events Admin Guide
Audit Events Admin Guide
This guide is for individuals who need to extract audit event information from UNIX and Linux syslogs and Windows application event logs. Additionally, this
information is available in the Audit Analyzer. Audit events are organized into categories in the Audit Analyzer and these categories are identified in this
document.
Depending on your environment and role as an administrator or auditor, you may want to read portions of this guide selectively. This guide provides the
following information:
Overview of Centrify Server Suite Audit Events provides an overview of how to read audit events.
Centrify Server Suite Audit Events identifies the different audit event categories. Each audit event includes a sample log with an explanation of how to
read the log as well as a list of the available audit events.
Overview of Delinea Server Suite Audit Events
To familiarize yourself with the elements of audit event logs, read the explanations of Windows and UNIX/Linux audit events, and then review how to read
Server Suite audit event data.
Windows and UNIX/Linux Audit Events

How to Read Audit Event Data
Configuring the Audit Event Log Location
Which Events Only in Centrify Audit & Monitoring Service
Windows and UNIX/Linux Audit Events
Review the following examples to understand the Windows and UNIX/Linux audit event logs, and then review how to read audit event data to understand the
similarities and differences.
Windows Audit Event Log Line Example
The following is an example of a Centrify audit event recorded in the Windows application event log. Standard Windows audit event fields (in black) contain
information about the Centrify event. Centrify augments these standard fields with additional data (in red) to help you to track logon and privilege activity
data.
04/05/2016 02:15:37 PM LogName=Application

SourceName=Centrify AuditTrail V2 EventCode=6003
EventType=4 Type=Information
ComputerName=member.acme.vms User=NOT_TRANSLATED
Sid=S-1-5-21-3789923312-3040275127-1160560412-500
SidType=0 TaskCategory=%1 OpCode=Info RecordNumber=51645
Keywords=Classic Message=Product: Centrify Suite Category:
DirectAuthorize - Windows Event name: Remote login success
Message: User successfully logged on remotely using role
'ROLE_Windows_Local_Accounts/Global'.
Apr 05 14:15:37 member.acme.vms dzagent[1496]: INFO AUDIT_TRAIL|Centrify
Suite|DirectAuthorize - Windows|1.0|3|Remote login success|5|user=
administrator@member.acme.vms userSid=S-1-5-21-
3789923312-3040275127-1160560412-500 sessionId=6 CentrifyEventID=6003
DAInst=AuditingInstallation DASessID=c72252aa-e616-44ff-a5f6-d3f53f09bb67
role=ROLE_Windows_Local_Accounts/Global
desktopguid=a16f50d8-179b-4d47-93ed-14c10ca76d63
Windows Audit Event Log Line Information
The following table provides definitions for each field type and name with their associated field value for the previous example.
Windows Audit Event Log Line Information
Field Type Field Name Sample Field Value
Syslog header fields Timestamp Apr 05, 2016 02:15:37 PM
Host Name member.acme.vms
Process Name dzagent
Process ID 1496
Log Level INFO
Centrify audit event header fields Event Type AUDIT_TRAIL
Product Centrify Suite
Category privilege elevation service - Windows
Product Version 1.0
Event ID 3
Event Name Remote login success
Severity 5
Centrify audit event common fields for Windows user administrator@member.acme.vms
userSid S-1-5-21-3789923312-3040275127-1160560412-500
DAInst AuditingInstallation
DASessID c72252aa-e616-44ff-a5f6-d3f53f09bb67
sessionId 6
CentrifyEventID 6003
Centrify audit event-specific fields role ROLE_Windows_Local_Accounts/Global
desktopguid a16f50d8-179b-4d47-93ed-14c10ca76d63
UNIX/Linux Audit Event Log Line Example
The following is an example of a UNIX/Linux audit event. Centrify audit event information is highlighted in red.
Apr 4 21:04:15 engcen6 adclient[1749]: INFO

AUDIT_TRAIL|Centrify Suite|Centrify sshd|1.0|100|SSHD granted|5|user=
dwirth(type:ad,dwirth@acme.vms) pid=7456 utc=1459784055479
CentrifyEventID=27100DAInst= AuditingInstallation
DASessID=c72252aa-e616-44ff-a5f6 -d3f53f09bb67 status=GRANTED
service=ssh-connection tty=/dev/pts/0 authMechanism=keyboard-interactive client=
192.168.81.11 sshRights=shell command=(none)
UNIX/Linux Audit Event Log Information
The following table provides definitions for each field type and name with their associated field value for the previous example.
UNIX/Linux Audit Event Log Information
Syslog header fields Timestamp Apr 4 21:04:15
Host Name engcen6
Process Name adclient
Process ID 1749
Log Level INFO
Category Centrify sshd
Product Version 1.0
Event ID 100
Event Name SSHD granted
Severity 5
Centrify audit event common fields user dwirth(type:ad,dwirth@acme.vms)
pid 7456
utc 1459784055479
CentrifyEventID 27100
DASessID c72252aa-e616-44ff-a5f
service ssh-connection
Centrify audit event-specific fields tty /dev/pts/0
authMechanism keyboard-interactive
client 192.168.81.11
sshRights shell
command (none)
How to Read Audit Event Data
The following information can help you understand how to read Centrify audit events.
Event ID/CentrifyEventID
Every Windows and UNIX/Linux audit event includes two numeric IDs that describe the event. The Event ID in the header fields identifies the unique ID of the
event within a particular event category, whereas the CentrifyEventID in the common fields identifies the unique ID among all Centrify audit event types.
Windows Example
Centrify audit event header fields Category Privilege Elevation Service - Windows
Product Version 1.0
Event ID 3
Event Name Remote login success 5
Centrify audit event common fields user administrator@member.acme.vms
userSid S-1-5-21-3789923312-3040275127-1160560412-500
DASessID c72252aa-e616-44ff-a5f6-d3f53f09bb67
sessionId 6
Centrify EventID 6003
UNIX/Linux Example
Category Centrify sshd
Product Version 1.0
Event ID 100
Event Name SSHD granted
Severity 5
Centrify audit event common fields user dwirth(type:ad,dwirth@acme.vms)
pid 7456
utc 1459784055479
Centrify EventID 27100
DASessID
c72252aa-e616-44ff-a5f6-d3f53f09bb67
status GRANTED
service ssh-connection
Severity
Severity is defined by an integer from 0 - 10, with 10 being the most important level. Centrify events are typically a Severity 5.
Spacing
A field name is one word (no spaces) in the audit event file. When the file is processed into a readable format, spaces are added to field names. For example, if
you need to search for Management Database Property, you should search on the following term: managementdatabaseproperty.
Case-Insensitive Field Names
Use case-insensitive field names in all search filters.
Configuring the Audit Event Log Location
You can configure audit event logs to go to DirectAudit or your system’s default logging system (Windows event log or UNIX syslog). You configure the log
location either manually for each computer or by way of group policy.
You can also configure a global audit event logging behavior or specify different settings for different feature areas.
Configuring the Audit Event Logging Location by Group Policy
Audit trail group policies are located in category-specific subfolders (such as Audit Analyzer Settings, Audit Manager Settings, and so on.
Additionally, a Centrify Global Settings subfolder contains group policies that you can set at a global level.
Any category-specific audit trail targets that you set (for example, Audit Manager Settings > Send audit trail to log file) override global audit trail
targets (for example, Centrify Global Settings > Send audit trail to log file). Each subfolder in Centrify Audit Trail Settings contains the same
set of group policies.
Note: To send audit trail events to both the database and the local logging facility, enable both of these group policies.
Enable this group policy to specify that audit events for this component Audit Analyzer, Audit Manager, and so on are sent to the active audit store
database.
Send Audit Trail to Log File
Enable this group policy to specify that audit events for this component such as Audit Analyzer, Audit Manager, and so on are sent to the local logging
facility (syslog on UNIX systems, Windows event log on Windows systems).
Set Global Audit Trail Targets
Specify the target for audit trail information.
If you set this group policy to Not configured or Disabled, the destination of audit trail information depends on which version of DirectAudit is installed. If
DirectAudit 3.2 or later is installed, audit trail information is sent to the local logging facility and DirectAudit. If a DirectAudit version earlier than 3.2 is
installed, audit trail information is only sent to the local logging facility.
If you set this group policy to Enabled, you can specify the target for audit trail information. Possible settings are:
0 (Audit information is not sent.)

1 (Audit information is sent to Centrify Audit & Monitoring Service. This capability is supported by DirectAudit version 3.2 and later.)
2 (Audit information is sent to the local logging facility, either syslog on UNIX systems or Windows event log on Windows systems.)
3 (Audit information is sent to both DirectAudit and the local logging facility.)
This group policy modifies the audittrail.targets setting in the agent configuration file.
Which Events are Only in Centrify Audit & Monitoring Service
Audit events may come from Centrify Authentication Service, Centrify Privilege Elevation Service, or Centrify Audit & Monitoring Service. If you are using only
authentication and privilege elevation, the following events will not be available to you as they are from audit and monitoring service:
All the audit events from the following categories:

Audit Analyzer
Audit Manager
Command
Centrify Audit & Monitoring Service - Windows
Centrify Audit & Monitoring Service System Management
Centrify Audit & Monitoring Service UNIX Agent
Centrify Audit & Monitoring Service advanced monitoring
The following audit events from the category Centrify Commands
Auditing enabled (Centrify Event Id 18000)
Auditing not enabled (Centrify Event Id 18001)
Auditing disabled (Centrify Event Id 18100)
Auditing not disabled (Centrify Event Id 18101)
Server Suite Audit Events
Audit Analyzer
Audit Manager
Centrify Commands (UNIX Commands)
Centrify Configuration
Centrify sshd
Command (Audited and Successfully Executed Commands)
Centrify Audit & Monitoring Service Advanced Monitoring
Centrify Audit & Monitoring Service UNIX Agent
Centrify Audit & Monitoring Service - Windows
Centrify Privilege Elevation Service - Windows
Centrify Authentication Service UNIX Agent
dzdo
dzinfo
dzsh
License Management
Kerberos
Multi-factor Authentication
PAM
Trusted Path
Audit Analyzer
The Audit Analyzer console is a graphical user interface that administrators can use to query and review captured user sessions. The Audit Analyzer is
available with the Centrify Audit & Monitoring Service. The Audit Analyzer events focus on session modification.
Audit Analyzer Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 3001. This log sample documents a session being deleted. The change was made by
user=administrator@acme.vms on April 20, 2016 at 05:51:01.

EventType=4 Type=Information ComputerName=
member.acme.vms User=NOT_TRANSLATED Sid=S-1-
5-21-3883016548-1611565816-1967702834-500 SidType=0
TaskCategory=%1 OpCode=Info RecordNumber=60622
Audit Analyzer Event name: Delete session Message: 1 out
of 1 selected sessions are successfully deleted. Apr 20
17:51:00 member.acme.vms mmc[4064]: INFO
AUDIT_TRAIL|Centrify Suite|Audit Analyzer|1.0|1|Delete
session|5|user=administrator@acme.vms
userSid=S-1-5-21-3883016548-1611565816-1967702834-500
sessionId=11 CentrifyEventID=3001 DAInst=
AuditingInstallation DASessID=c72252aa-e616-44ff-a5f6-
d3f53f09bb67 sessions_deleted=1 sessions_selected=1
Audit Analyzer Audit Events
Audit Analyzer Audit Events
Event
Description Parameters
ID
3001 Delete session Sessions_Deleted: Sessions_deleted Sessions_Selected: Sessions_selected
Delete_criteria: Delete session selection criteria Sessions_Deleted: Sessions_deleted Sessions_Selected:

3002 Delete session by criteria
Sessions_selected
Installation: Name of the installation Session Id: Unique identifier of the session Reviewers: List of reviewers of
3003 Set session reviewers succeeded
the session
Installation: Name of the installation Session Id: Unique identifier of the session Reviewers: List of reviewers of
3004 Set session reviewers failed
the session Reason: Error message
Remove session reviewers

3005 Installation: Name of the installation Session Id: Unique identifier of the session
succeeded
3006 Remove session reviewers failed Installation: Name of the installation Session Id: Unique identifier of the session Reason: Error message
Update session review status Installation: Name of the installation Session Id: Unique identifier of the session Review Status: Name of the
3007
succeeded added in release 18.8 review status
Update session review status Installation: Name of the installation Session Id: Unique identifier of the session Review Status: Name of the
3008
failed added in release 18.8 review status Reason: Error message
Replay session succeeded Added Installation: Name of the installation Session Id: Unique identifier of the session User: User of the session
3009
in release 19.6 Machine: Machine of the session
Replay session failed Added in

3010 Installation: Name of the installation Session Id: Unique identifier of the session Reason: Error message
release 19.6
Event
ID
Delete audit trail events

3011 SearchFilter: Search Filter
succeeded Added in release 19.9
Delete audit trail events failed

3012 SearchFilter: Search Filter Reason: Error Message
Added in release 19.9
Delete session succeeded Added Session Id: Unique identifier of the session Username: Name of the user whose session was recorded
3013
in release 2020.1 Machinename: Name of the machine where the session was recorded
Delete session failed Added in Session Id: Unique identifier of the session Username: Name of the user whose session was recorded
3014
release 2020.1 Machinename: Name of the machine where the session was recorded Reason: error message
Audit Manager
Audit Manager is a Microsoft management console (MMC) that you can use to configure and manage the deployment of audit components, such as audit
stores and audit store databases, audit roles, collectors, and agents. Audit Manager is available with Server Suite. Audit events generated by Audit Manager
primarily involve the installation and configuration of auditing components such as management databases, audit stores, and audit store databases, and
changes to audit role and user permissions.
Audit Analyzer Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 3001. This log sample documents a session being deleted. The change was made by
user=administrator@acme.vms on April 20, 2016 at 05:51:01.

EventType=4 Type=Information ComputerName=
member.acme.vms User=NOT_TRANSLATED Sid=S-1-
5-21-3883016548-1611565816-1967702834-500 SidType=0
Audit Analyzer Event name: Delete session Message: 1 out
of 1 selected sessions are successfully deleted. Apr 20
17:51:00 member.acme.vms mmc[4064]: INFO
AUDIT_TRAIL|Centrify Suite|Audit Analyzer|1.0|1|Delete
session|5|user=administrator@acme.vms
userSid=S-1-5-21-3883016548-1611565816-1967702834-500
sessionId=11 CentrifyEventID=3001 DAInst=
AuditingInstallation DASessID=c72252aa-e616-44ff-a5f6-
d3f53f09bb67 sessions_deleted=1 sessions_selected=1
Audit Manager Audit Events
Audit Manager Audit Events
Event
Id
Video capture
12200 installation: audit and monitoring service Installation VideoCaptureStatus: video capture status
status updatedv
Create new
12201 installation installation: Name of the installation
succeededv
Create new
12202 installation: Name of the installation reason: Error message
installation failedv
Installation update installation: Name of the installation Installation Property: Name of the updated installation property Installation Property
12203
succeededv Value: Value of the updated installation property Operation: Type of operation (Set or Add or Remove)
installation: Name of the installation Installation Property: Name of the updated installation property Installation Property
Installation update
12204 Value: Value of the updated installation property Operation: Type of operation (Set or Add or Remove) reason: Error
failedv
message
Installation
installation: Name of the installation User/Group: Name of the user or group Permissions: Permissions assigned to the user
12205 permissions update
or group
succeededv
Installation
installation: Name of the installation User/Group: Name of the user or group Permissions: Permissions assigned to the user
or group reason: Error message
failed
Remove installation
12207 installation: Name of the installation
succeeded
Event
Id
Remove installation
12208 installation: Name of the installation reason: Error message
failed
Audit options installation: audit and monitoring service Installation DisableSelfReview: Disable reviewing own sessions DisableSelfDelete:
12251
updated Disable deleting own sessions
Add Management
12209 Database installation: Name of the installation Management Database: Name of the Management Database
succeeded
Add Management
12210 installation: Name of the installation Management Database: Name of the Management Database reason: Error message
Database failed
Management installation: Name of the installation Management Database: Name of the Management Database Management Database
12211 Database update Property: Name of the updated Management Database property Management Database Property Value: Value of the
succeeded updated Management Database property Operation: Type of operation (Set or Add or Remove)
Management installation: Name of the installation Management Database: Name of the Management Database Management Database
12212 Database update Property: Name of the updated Management Database property Management Database Property Value: Value of the
failed updated Management Database property Operation: Type of operation (Set or Add or Remove) reason: Error message
Management
Database installation: Name of the installation Management Database: Name of the Management Database User/Group: Name of the
12213
permissions update user or group Permissions: Permissions assigned to the user or group
succeeded
Management
Database installation: Name of the installation Management Database: Name of the Management Database User/Group: Name of the
12214
permissions update user or group Permissions: Permissions assigned to the user or group reason: Error message
failed
Remove
Management
12215 installation: Name of the installation Management Database: Name of the Management Database
Database
succeeded
Remove
12216 Management installation: Name of the installation Management Database: Name of the Management Database reason: Error message
Database failed
Add Audit Store

12217 installation: Name of the installation Audit Store: Name of the Audit Store
succeeded
Add Audit Store

12218 installation: Name of the installation Audit Store: Name of the Audit Store reason: Error message
failed
installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Property: Name of the updated Audit
Audit Store update
12219 Store property Audit Store Property Value: Value of the updated Audit Store property Operation: Type of operation (Set or
succeeded
Add or Remove)
installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Property: Name of the updated Audit
Audit Store update
12220 Store property Audit Store Property Value: Value of the updated Audit Store property Operation: Type of operation (Set or
failed
Add or Remove) reason: Error message
Event
Id
Audit Store
installation: Name of the installation Audit Store: Name of the Audit Store User/Group: Name of the user or group
Permissions: Permissions assigned to the user or group
succeeded
Audit Store
installation: Name of the installation Audit Store: Name of the Audit Store User/Group: Name of the user or group
Permissions: Permissions assigned to the user or group reason: Error message
failed
Remove Audit Store

12223 installation: Name of the installation Audit Store: Name of the Audit Store
succeeded
Remove Audit Store

12224 installation: Name of the installation Audit Store: Name of the Audit Store reason: Error message
failed
Add Audit Store

installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the Audit Store
12225 Database
Database
succeeded
Add Audit Store installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the Audit Store
12226
Database failed Database reason: Error message
Attach Audit Store

12227 Database
Database
succeeded
Attach Audit Store installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the Audit Store
12228
Attach audit and

monitoring service installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the audit and
12229
Version 1 Database monitoring service Version 1 Database
succeeded
Attach audit and

monitoring service installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the audit and
12230
Version 1 Database monitoring service Version 1 Database reason: Error message
failed
Set Active Audit

12231 Store Database
Database
succeeded
Set Active Audit

12232 Store Database
Database reason: Error message
failed
Audit Store installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the Audit Store
12233 Database update Database Audit Store Database Property: Name of the updated Audit Store Database property Audit Store Database
succeeded Property Value: Value of the updated Audit Store Database property Operation: Type of operation (Set or Add or Remove)
Audit Store
Database Audit Store Database Property: Name of the updated Audit Store Database property Audit Store Database
12234 Database update
Property Value: Value of the updated Audit Store Database property Operation: Type of operation (Set or Add or Remove)
failed
reason: Error message
Event
Id
Detach Audit Store

12235 Database
Database
succeeded
Detach Audit Store installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the Audit Store
12236
Delete Audit Store

12237 Database
Database
succeeded
Delete Audit Store installation: Name of the installation Audit Store: Name of the Audit Store Audit Store Database: Name of the Audit Store
12238
Add Audit Role

12239 installation: Name of the installation Audit Role: Name of the Audit Role
succeeded
12240 Add Audit Role failed installation: Name of the installation Audit Role: Name of the Audit Role reason: Error message
installation: Name of the installation Audit Role: Name of the Audit Role Audit Role Property: Name of the updated Audit Role
Audit Role update
12241 property Audit Role Property Value: Value of the updated Audit Role property Operation: Type of operation (Set or Add or
succeeded
Remove)
installation: Name of the installation Audit Role: Name of the Audit Role Audit Role Property: Name of the updated Audit Role
Audit Role update
12242 property Audit Role Property Value: Value of the updated Audit Role property Operation: Type of operation (Set or Add or
failed
Remove) reason: Error message
Audit Role
installation: Name of the installation Audit Role: Name of the Audit Role User/Group: Name of the user or group Permissions:
Permissions assigned to the user or group
succeeded
Audit Role
installation: Name of the installation Audit Role: Name of the Audit Role User/Group: Name of the user or group Permissions:
Permissions assigned to the user or group reason: Error message
failed
Audit Role assign

12245 installation: Name of the installation Audit Role: Name of the Audit Role User/Group: Name of the user or group
member succeeded
Audit Role assign installation: Name of the installation Audit Role: Name of the Audit Role User/Group: Name of the user or group reason: Error
12246
member failed message
Audit Role remove

12247 installation: Name of the installation Audit Role: Name of the Audit Role User/Group: Name of the user or group
member succeeded
Audit Role remove installation: Name of the installation Audit Role: Name of the Audit Role User/Group: Name of the user or group reason: Error
12248
member failed message
Delete Audit Role

12249 installation: Name of the installation Audit Role: Name of the Audit Role
succeeded
Delete Audit Role

12250 installation: Name of the installation Audit Role: Name of the Audit Role reason: Error message
failed
Centrify Commands (UNIX Commands)
Audit events in the Centrify Commands category are focused on capturing command line activity. Audit events are recorded when users or administrators run
command line programs to enable or disable auditing, join or leave a domain, query Active Directory for user or group information, change their password
configuration settings or license mode, or perform other operations.
Centrify Command Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 18000. This log sample documents auditing being enabled. The change was made by
user=root on April 5 at 11:37:28.
Apr 5 11:37:28 engcen6 adclient[1749]: INFO AUDIT_

TRAIL|Centrify Suite|Centrify Commands|1.0|0|Auditing
enabled|5|user=root pid=14874 utc=1459836448489
CentrifyEventID=18000 DAInst=AuditingInstallation
DASessID=c72252aa-e616-44ff-a5f6-d3f53f09bb67
status=GRANTED service=NSS
Centrify Commands Audit Events
Centrify Commands Audit Events
Event Id Description Parameters
18000 Auditing enabled service: service
service: service
18001 Auditing not enabled
reason: error message
18100 Auditing disabled service: service
service: service
18101 Auditing not disabled
18200 The user login to the system successfully service: service tty: tty
18300 Desktop auditing enabled Added in Release 2020
18301 Desktop auditing not enabled Added in Release 2020 reason: error message
18400 Desktop auditing disabled Added in Release 2020
18401 Desktop auditing not disabled Added in Release 2020 reason: error message
18500 Session auditing started Added in Release 2020
18501 Session auditing ended Added in Release 2020
parameters: parameters
zone: zone name
20100 Joined domain domain: domain
computer: computer name
runas: username@domain
zone: zone name
domain: domain
20101 Join failed
computer: computer name
runas: username@domain
20200 Left domain parameters: parameters
20201 Leaving domain failed
20300 Query as root was successful parameters: parameters
20301 Query was successful parameters: parameters
20302 Query request failed
20400 Password changed
unixUser: user name
20401 Password change failed unixUser: user name
20500 Configuration settings (Centrify.conf) reloaded parameters: parameters
20501 Configuration settings (Centrify.conf) failed to reload
20600 Local cache flushed parameters: parameters
20601 Cache flush failed
20650 Object refreshed parameters: parameters
20651 Object refresh failed
20800 License modes changed parameters: parameters
20801 License modes change failed
20900 Advanced monitoring enabled service: service
service: service
20901 Advanced monitoring not enabled
20910 Advanced monitoring disabled service: service
service: service
20911 Advanced monitoring not disabled
21100 Changing web proxy configuration succeeded added in release 18.8 parameters: parameters
21101 Changing web proxy configuration failed added in release 18.8
21200 Editing Kerberos keytab file succeeded parameters: parameters
21201 Editing Kerberos keytab file failed
Centrify Configuration
Centrify hierarchical zones are used to enable information about non-Windows computers, user profiles, access rights, and roles to be stored in Active
Directory. Hierarchical zones can be used to segregate and perform privilege management on both UNIX/Linux and Windows systems. These configuration
audit events focus on zones, computers, groups, users, rights, and roles.
Centrify Configuration Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 36101. This log sample documents a user giving zone administrative tasks to another
user. The change was made by user=dwirth@acme.vms on April 19, 2016 at 03:01:04.

SourceName=CentrifyAuditTrail V2 EventCode=36101
EventType=4 Type=Information
ComputerName=member.acme.vms
User=NOT_TRANSLATED Sid=S-1-5-21-3883016548-1611565816-
1967702834-1107 SidType=0 TaskCategory=%1 OpCode=Info RecordNumber=59436
Keywords=Classic Message=Product:
Centrify Suite Category: Centrify Configuration Event
name: Zone administrative tasks delegated Message:
"dwirth@acme.vms" (running as "dwirth@acme")
delegated "acmepankaj" to perform "Change zone
properties" on "acme.vms/acmese/Zones/zone-14".
Apr 19 15:01:04 member mmc[5792]: INFO AUDIT_TRAIL|Centrify
Suite|CentrifyvConfiguration|1.0|101|Zone
tasks delegated|5|user=dwirth@acme.vms userSid=
S-1-5-21-3883016548-1611565816-1967702834-1107 sessionId=3
DASessID=c72252aa-e616-44ff-a5f6-d3f53f09bb67 pid=5792
user=dwirth@acme.vms runas=dwirth@acme type=AD
status=SUCCESS trustee=acmepankaj task=Change zone
properties zone=acme.vms/acmese/Zones/zone-14
Centrify Configuration Audit Events
Centrify Configuration Audit Events
Event
Id
Zone administrative tasks PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36101
delegated trustee: username@domain task: delegation task name zone: zone name
Delegation of zone administrative PID: process id user: username@domain RunAs: username@domain type: user type status: failed trustee:
36102
tasks failed username@domain task: delegation task name zone: zone name reason: failure reason
Computer administrative tasks PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36103
delegated trustee: username@domain task: delegation task name zone: zone name computer: computer name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed trustee:
Delegation of computer
36104 username@domain task: delegation task name zone: zone name computer: computer name reason: error
administrative tasks failed
message
Computer role administrative PID: process id user: username@domain RunAs: username@domain type: user type status: trustee:
36105
tasks delegated username@domain task: delegation task name zone: zone name computerRole: computer role name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed trustee:
Delegation of computer role
36106 username@domain task: delegation task name zone: zone name computerRole: computer role name reason:
administrative tasks failed
error message
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded zone:
36201 Zone created
zone name
Event
Id
PID: process id user: username@domain RunAs: username@domain type: user type status: failed zone: zone
36202 Zone creation failed
name reason: error message
36203 Zone deleted
zone name
status: failed PID: process id user: username@domain RunAs: username@domain type: user type zone: zone
36204 Zone deletion failed
36205 Zone modified
zone name
36206 Zone update failed
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36301 User added to a zone
ZoneUser: unixname zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed ZoneUser:
36302 Add user to a zone failed
unixname zone: zone name reason: error message
36303 User deleted from a zone
36304 Delete user from a zone failed
36305 User profile modified in a zone
36306 Modify user in a zone failed
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded :
36307 User added to a computer
unixname computer: computer hostname zone: zone name
36308 Add user to a computer failed
unixname computer: computer hostname zone: zone name reason: error message
36309 User deleted from computer
ZoneUser: unixname computer: computer hostname zone: zone name
Delete user from a computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed ZoneUser:
36310
failed unixname computer: computer hostname zone: zone name reason: error message
User profile modified on a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36311
computer ZoneUser: unixname computer: computer hostname zone: zone name
36312 Modify user on a computer failed
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded group:
36401 Group added to a zone
group name zone: zone name
Event
Id
PID: process id user: username@domain RunAs: username@domain type: user type status: failed group:
36402 Add group to a zone failed
group name zone: zone name reason: error message
36403 Group deleted from a zone
36404 Delete group from a zone failed
36405 Group profile modified in a zone
36406 Modify group in a zone failed
36407 Group added to a computer
group name computer: computer hostname zone: zone name
36408 Add group to a computer failed
group name computer: computer hostname zone: zone name reason: error message
36409 Group deleted from a computer
Delete group from a computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed group:
36410
failed group name computer: computer hostname zone: zone name reason: error message
Group profile modified on a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded group:
36411
computer group name computer: computer hostname zone: zone name
36412 Modify group for a computer failed
group name computer: computer hostname zone: zone name reason: error message
36501 Computer added
computer: hostname zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed computer:
36502 Add computer failed
hostname zone: zone name reason: error message
36503 Computer deleted
computer: hostname zone: zone name
36504 Delete computer failed
PID: process id user: username@domain RunAs: username@domain type: user type status: computer:
36505 Computer modified
hostname zone: zone name
36506 Modify computer failed
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded pam:
36601 PAM access right added
pam name zone: zone name
Event
Id
PID: process id user: username@domain RunAs: username@domain type: user type status: failed pam: pam
36602 Add PAM right failed
name zone: zone name reason: error message
36603 PAM right deleted
PID: process id user: username@domain RunAS: username@domain type: user type status: failed pam: pam
36604 Delete PAM right failed
36605 PAM right modified
PID: process id user: username@domain RunAs: username@domain type: user type status: failed pam: pam
36606 Modify PAM right failed
37201 Desktop right added
desktop: desktop right name zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed desktop:
37202 Add Desktop Right failed
desktop right name zone: zone name reason: error message
37203 Desktop right deleted
PID: process id user: username@domain RunAS: username@domain type: user type status: failed desktop:
37204 Delete desktop right failed
37205 desktop right modified
PID: process id user: username@domain RunAs: username@domain type: user type status: failed desktop:
37206 Modify desktop right failed
37301 Network right added
network: network right name zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed network:
37302 Add network right failed
network right name zone: zone name reason: error message
37303 network right deleted
PID: process id user: username@domain RunAS: username@domain type: user type status: failed network:
37304 Delete network right failed
37305 Network right modified
PID: process id user: username@domain RunAs: username@domain type: user type status: failed network:
37306 Modify network right failed
37401 Application right added
application: application right name zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed application:
37402 Add application right failed
application right name zone: zone name reason: error message
Event
Id
37403 Application right deleted
PID: process id user: username@domain RunAS: username@domain type: user type status: failed application:
37404 Delete application right failed
37405 Application right modified
PID: process id user: username@domain RunAs: username@domain type: user type status: failed application:
37406 Modify application right failed
36701 UNIX command right added
dzcmd: dzcmd zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed dzcmd:
36702 Add command right failed
dzcmd zone: zone name reason: error message
36703 UNIX command right deleted
36704 Delete command right failed
36705 UNIX command right modified
36706 Modify command right failed
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded role:
36801 Role added
role name zone: zone name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed role: role
36802 Add role failed
36803 Role deleted
36804 Delete role failed
36805 Role modified
36806 Modify role failed
PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded right:
36807 Add right to role was successful
right name role: role name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed right: right
36808 Add right to role failed
name role: role name reason: error message
Event
Id
Delete right from role was PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded right:
36809
successful right name role: role name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed right: right
36810 Delete right from role failed
name role: role name reason: error message
36901 Role assignment added
zone name role: role name trustee: username@domain
36902 Role assignment failed
name role: role name trustee: username@domain reason: error message
36903 Role assignment removed
36904 Delete role assignment failed
36905 Role assignment modified
36906 Modify role assignment failed
Role assignment added to a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36907
computer computer: computer zone: zone name role: role name trustee: username@domain
Add role assignment to computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed computer:
36908
failed computer hostname zone: zone name role: role name trustee: username@domain reason: error message
Role assignment deleted from a PID: process id user: username@domain RunAs: username@domain type: user type status: computer:
36909
computer computer hostname zone: zone name role: role name trustee: username@domain
Delete role assignment from PID: process id user: username@domain RunAs: username@domain type: user type status: failed computer:
36910
computer failed computer hostname zone: zone canonical role: role name trustee: username@domain reason: error message
Role assignment modified for a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36911
computer computer: computer hostname zone: zone canonical role: role name trustee: username@domain
Modify role assignment for a PID: process id user: username@domain RunAs: username@domain type: user type status: failed computer:
36912
computer failed computer hostname zone: zone canonical role: role name trustee: username@domain reason: error message
Role assignment added to a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36913
computer role computerRole: computer role zone: zone name role: role name trustee: username@domain
PID: process id user: username@domain RunAs: username@domain type: user type status: failed
Role assignment for a computer
36914 computerRole: computer role name zone: zone name role: role name trustee: username@domain reason:
role failed
error message
Role assignment deleted from a PID: process id user: username@domain RunAs: username@domain type: user type status: computerRole:
36915
computer role computer role name zone: zone name role: role name trustee: username@domain
Delete role assignment from a
36916 computerRole: computer role name zone: zone canonical role: role name trustee: username@domain reason:
computer role failed
error message
Event
Id
Role assignment modified for a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
36917
computer role computerRole: computer role name zone: zone canonical role: role name trustee: username@domain
Modify role assignment in a
36918 computerRole: computer role name zone: zone canonical role: role name trustee: username@domain reason:
computer role failed
error message
37001 Computer role added
computerRole: computer role name zone: zone name
37002 Add computer role failed
computerRole: computer role name zone: zone name reason: error message
37003 Computer role deleted
37004 Delete computer role failed
computerRole: computer role name zone: zone name reason: error
37005 Computer role modified
37006 Modify computer role failed
computerRole: computer role zone: zone name reason: error message
37101 User added to a group
member: username group: group name
PID: process id user: username@domain RunAs: username@domain type: user type status: failed member:
37102 Add user to a group failed
username group: group name reason: error message
37103 Password reset
account: username
PID: process id user: username@domain RunAs: username@domain type: user type status: failed account:
37104 Reset password failed
username reason: error message
37501 user added to a zone
37502 Add local user to a zone failed
37503 Local user deleted from a zone
Delete local user from a zone PID: process id user: username@domain RunAs: username@domain type: user type status: failed ZoneUser:
37504
failed unixname zone: zone name reason: error message
Local user profile modified in a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
37505
zone ZoneUser: unixname zone: zone name
37506 Modify local user in a zone failed
Event
Id
37511 Local user added to a computer
37512 Add local user to a computer failed
37513 Local user deleted from computer
Delete local user from a computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed ZoneUser:
37514
Local user profile modified on a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded
37515
computer ZoneUser: unixname computer: computer hostname zone: zone name
Modify local user on a computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed ZoneUser:
37516
37521 Local group added to a zone
37522 Add local group to a zone failed
37523 Local group deleted from a zone
Delete local group from a zone PID: process id user: username@domain RunAs: username@domain type: user type status: failed group:
37524
failed group name zone: zone name reason: error message
Local group profile modified in a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded group:
37525
zone group name zone: zone name
37526 Modify local group in a zone failed
37531 Local group added to a computer
Add local group to a computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed group:
37532
Local group deleted from a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded group:
37533
Delete local group from a PID: process id user: username@domain RunAs: username@domain type: user type status: failed group:
37534
computer failed group name computer: computer hostname zone: zone name reason: error message
Local group profile modified on a PID: process id user: username@domain RunAs: username@domain type: user type status: succeeded group:
37535
Modify local group for a computer PID: process id user: username@domain RunAs: username@domain type: user type status: failed group:
37536
Event
Id
Local Windows user added to a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37601
zone added in Release 2020 failed ZoneUser: local Windows user name zone: zone name
Add local Windows user to a zone PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37602
failed added in Release 2020 failed ZoneUser: local Windows user name zone: zone name reason: error message
Local Windows user deleted from PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37603
a zone added in Release 2020 failed ZoneUser: local Windows user name zone: zone name
Delete local Windows user from a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37604
zone failed added in Release 2020 failed ZoneUser: local Windows user name zone: zone name reason: error message
Local Windows user modified in a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37605
zone added in Release 2020 failed ZoneUser: local Windows user name zone: zone name
Modify local Windows user in a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37606
zone failed added in Release 2020 failed ZoneUser: local Windows user name zone: zone name reason: error message
Local Windows user added to a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37611
computer added in Release 2020 failed ZoneUser: local Windows user name computer: computer hostname zone: zone name
Add local Windows user to a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37612 computer failed added in Release failed ZoneUser: local Windows user name computer: computer hostname zone: zone name reason: error
2020 message
Local Windows user deleted from PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37613
Delete local Windows user from a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
2020 message
Local Windows user modified on a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37615
Modify local Windows user on a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
2020 message
Local Windows group added to a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37621
zone added in Release 2020 failed group: group name zone: zone name
Add local Windows group to a zone PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37622
failed added in Release 2020 failed group: group name zone: zone name reason: error message
Local Windows group deleted from PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37623
a zone added in Release 2020 failed group: group name zone: zone name
Local Windows group modified in a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37624
zone added in Release 2020 failed group: group name zone: zone name
Modify local Windows group in a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37626
zone failed added in Release 2020 failed group: group name zone: zone name reason: error message
Event
Id
Local Windows group added to a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37631
computer added in Release 2020 failed group: group name computer: computer hostname zone: zone name
Add local Windows group to a

PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37632 computer failed added in Release
failed group: group name computer: computer hostname zone: zone name reason: error message
2020
Local Windows group deleted from PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37633
a computer added in Release 2020 failed group: group name computer: computer hostname zone: zone name
Delete local Windows group from a

PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37634 computer failed added in Release
failed group: group name computer: computer hostname zone: zone name reason: error message
2020
Local Windows group modified on PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37635
a computer added in Release 2020 failed group: group name computer: computer hostname zone: zone name
Modify local Windows group for a PID: process ID user: username@domain RunAs: username@domain type: user type status: succeeded or
37636
computer failed added in Release failed group: group name computer: computer hostname zone: zone name reason: error message
Centrify sshd
Centrify sshd is Centrify's enhanced version of OpenSSH. This software program uses the secure shell protocol to connect to a remote computer. Centrify
sshd audit events identify DZ SSH rights and SSHD activities.
Centrify sshd Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 27000. This log sample documents the rights granted to the DZ SSH shell client. The
change was made by user=dwirth(type:ad,dwirth@acme.vms) on April 4 at 01:04:15.
Apr 4 21:04:15 engcen6 adclient[1749]: INFO

AUDIT_TRAIL|Centrify Suite|Centrify sshd|1.0|0|DZ SSH right
granted|5|user=dwirth(type:ad,dwirth@acme.vms) pid=7461
utc=1459784055474 CentrifyEventID=27000
DAInst=AuditingInstallation DASessID=c72252aa-e616-
44ff-a5f6-d3f53f09bb67 status=GRANTED
service=dzssh-shell client=192.168.81.11
Centrify sshd Audit Events
Centrify sshd Audit Events
27000 DZ SSH right granted service: service client: client
27001 DZ SSH right denied service: service client: client reason: error message
SSHD granted This event has been deprecated.

27100- service: service tty: tty authMechanism: authentication type client: client sshRights: ssh
Use Centrify Event Id 27104 introduced in release
Deprecated rights command: command
2017.3 instead.
SSHD denied This event has been deprecated.

27101- service: service tty: tty authMechanism: authentication type client: client reason: error
Use Centrify Event Id 27105 introduced in release
Deprecated message
2017.3 instead.
service: service tty: tty authMechanism: authentication type client: client reason: error
27102 SSHD connection close successfully
message
service: service tty: tty authMechanism: authentication type client: client sshRights: ssh
27104 SSHD granted added in release 2017.3 rights command: command MfaRequired: whether user was required to do MFA
EntityName: Entity Name
service: service tty: tty authMechanism: authentication type client: client reason: error
27105 SSHD denied added in release 2017.3
message MfaRequired: whether user was required to do MFA EntityName: Entity Name
dataFlowType: send a file/directory to remote machine or receive a file/directory from

27200 SCP succeeded added in release 18.8 remote machine fileType: file or directory pathname: the full path name of file or
directory
dataFlowType: send a file/directory to remote machine or receive a file/directory from

27201 SCP failed added in release 18.8 remote machine fileType: file or directory pathname: the full path name of file or
directory reason: Error message
SFTP command execution succeeded added in

27300 operation: SFTP command arguments: the arguments of SFTP command
release 18.8
SFTP command execution failed added in release

27301
18.8
) [tags]: # (server suite) [priority]: # (12)
Command (Audited and Successfully Executed Commands)
Command audit events are recorded when Centrify UNIX command-line programs are used on Centrify-managed computers. Centrify UNIX command audit
events focus on the execution success or failure of the audited command.
Command Audit Event Log Sample
Nov 26 00:32:01 Eason adclient[31118]: INFO

AUDIT_TRAIL|Centrify Suite|Command|1.0|100
|Audited command is executed|5|user=
pid=31937 utc=1416979921469 CentrifyEventID=48100
DAInst=AuditingInstallation DASessID=c72252aa-e616
-44ff-a5f6-d3f53f09bb67 status=SUCCESS
command=/bin/ls -l data.txt
Command Audit Events
Event Source Category: Command
48100 Audited command is executed command: command
48101 Audited command fails to be executed command: command reason: error message
Centrify Audit & Monitoring Service Advanced Monitoring
If you have enabled Centrify Audit & Monitoring Service for advanced monitoring, you can generate data for three additional auditing reports, as follows:
Monitored execution report: This report shows the monitored commands being executed on the audited machines—including information on commands
that are run individually or as part of scripts.
Detailed execution report: This report shows all of the commands being executed on the audited machines—including commands that are run as part of
scripts or other commands.
File monitor report: This report shows the sensitive files being modified by users on the audited machines.
Advanced Monitoring Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 57300. This log sample documents a session where a user attempted to modify a
monitored file. The change was made by root@al_rhel6_2.altest.acme.com on November 2, 2016 at 06:09:01.
Nov 2 06:09:01 al_rhel6_2 adclient[27002]: INFO

AUDIT_TRAIL|Centrify Suite|DirectAudit Advanced
Monitoring|1.0|300|Monitored file modification
attempted|5|user=<no_login_user> pid=32393
DAInst=AuditingInstallation DASessID=c72252aa-
e616-44ff-a5f6-d3f53f09bb67 status=SUCCESS
syscall=unlink status=0 timestamp=1478092141.432000
auid=<no_login_user> uid=root@al_rhel6_2.altest.
acme.com processid=32393 ppid=32392 gid=root
euid=root@al_rhel6_2.altest.acme.com cwd=/ accessType=2
command=/usr/bin/python argc=-1 args=/etc/pki/nssdb/
/etc/pki/nssdb/cert9.db-journal
Centrify Audit & Monitoring Service Advanced Monitoring Audit Events
Audit and Monitoring Service Advanced Monitoring Audit Events
Event
ID
Monitored syscall: system call exitcode: exit code timestamp: timestamp auid: login user uid: user procid: process id ppid: parent
57200 program is process id gid: group euid: effective user cwd: current working directory cmd: command argc: no of arguments args:
executed arguments
Monitored syscall: system call exitcode: exit code timestamp: timestamp auid: login user uid: user procid: process id ppid: parent
57201 program failed to process id gid: group euid: effective user cwd: current working directory cmd: command argc: no of arguments args:
execute arguments
Monitored file syscall: system call exitcode: exit code timestamp: timestamp auid: login user uid: user procid: process id ppid: parent
57300 modification process id gid: group euid: effective user cwd: current working directory accType: access Type cmd: command argc: no of
attempted arguments args: arguments
Monitored file syscall: system call exitcode: exit code timestamp: timestamp auid: login user uid: user procid: process id ppid: parent
57301 modification process id gid: group euid: effective user cwd: current working directory accType: access Type cmd: command argc: no of
attempt failed arguments args: arguments
Command
syscall: syscall exitcode: exit code timestamp: timestamp auid: auid uid: uid pid: pid ppid: ppid gid: gid euid: euid cwd: current
57400 execution is
working directory command: command argc: no of arguments args: arguments
started
Command
syscall: syscall exitcode: exit code timestamp: timestamp auid: auid uid: uid pid: pid ppid: ppid gid: gid euid: euid cwd: current
57401 execution fails to
working directory command: command argc: no of arguments args: arguments
start
The auditing module’s detailed, real-time auditing of privileged user sessions on Windows, UNIX, and Linux systems provides a full accounting of user activity
and system access. Centrify Audit & Monitoring Service System Management is available with Centrify Audit & Monitoring Service. The audit and monitoring
service audit events focus on collector service, collector settings, and agent settings.
Centrify Audit & Monitoring Service System Management audit event log sample
The following is a sample of an audit event log for Centrify Audit Event ID 42251. This log sample documents the successful start of the collector service on
computer ‘MEMBER’. The change was made by user=system@nt authority on April 05, 2016 at 14:59:56.
04/05/2016 03:00:01 PM LogName=Application SourceName=

Centrify AuditTrail V2 EventCode=42251 EventType=4
Type=Information ComputerName=member.acme.vms
User=NOT_TRANSLATED Sid=S-1-5-18 SidType=0
DirectAudit System Management Event name: Start collector
service succeeded Message: Collector service was started
successfully on computer 'MEMBER'. Apr 05 14:59:56
member.acme.vms collector[1344]: INFO AUDIT_TRAIL|
Centrify Suite|DirectAudit System Management|1.0|251|Start
collector service succeeded|5|user=system@nt authority
userSid=S-1-5-18 sessionId=0 centrifyEventID=42251
44ff-a5f6-d3f53f09bb67 installation=DefaultInstallation
collector=MEMBER
Centrify Audit & Monitoring Service System Management audit events
Audit and Monitoring Service System Management Audit Events
Centrify
Event Id
Start collector service

42251 installation: Name of the installation Collector: Name of the collector computer
succeeded
42252 Start collector service failed installation: Name of the installation Collector: Name of the collector computer reason: Error message
Stop collector service

42253 installation: Name of the installation Collector: Name of the collector computer
succeeded
42254 Stop collector service failed installation: Name of the installation Collector: Name of the collector computer reason: Error message
Collector settings update installation: Name of the installation Collector: Name of the collector computer Collector setting: Name of
42255
succeeded the updated collector setting Collector setting value: Value of the updated collector setting
installation: Name of the installation Collector: Name of the collector computer Collector setting: Name of
42256 Collector settings update failed the updated collector setting Collector setting value: Value of the updated collector setting reason: Error
message
42257 Start agent service succeeded installation: Name of the installation Audited system: Name of the audited system
42258 Start agent service failed installation: Name of the installation Audited System: Name of the audited system reason: Error message
42259 Stop agent service succeeded installation: Name of the installation Audited system: Name of the audited system
42260 Stop agent service failed installation: Name of the installation Audited system: Name of the audited system reason: Error message
Agent settings update installation: Name of the installation Audited system: Name of the audited system Agent setting: Name of
42261
succeeded the updated agent setting Agent setting value: Value of the updated agent setting
Centrify
Event Id
installation: Name of the installation Audited system: Name of the audited system Agent setting: Name of
42262 Agent settings update failed
the updated agent setting Agent setting value: Value of the updated agent setting reason: Error message
Start audit management service

42263 installation: Name of the installation Audit Management: Name of the audit management computer
succeeded added in release 18.11
Start audit management service installation: Name of the installation Audit Management: Name of the audit management computer reason:
42264
failed added in release 18.11 Error message
Stop audit management service

42265 installation: Name of the installation Audit Management: Name of the audit management computer
Stop audit management service installation: Name of the installation Audit Management: Name of the audit management computer reason:
42266
failed added in release 18.11 Error message
Started the collector service

42267 installation: Name of the installation Collector: Name of the collector computer User: User name
added in release 18.11
Failed to start the collector installation: Name of the installation Collector: Name of the collector computer User: User name reason:
42268
service added in release 18.11 Error message
Stopped the collector service

Failed to stop the collector installation: Name of the installation Collector: Name of the collector computer User: User name reason:
42270
Restarted the collector service

Failed to restart the collector installation: Name of the installation Collector: Name of the collector computer User: User name reason:
42272
Started the audit management installation: Name of the installation Audit Management: Name of the audit management computer User:
42273
service added in release 18.11 User name
Failed to start the audit

installation: Name of the installation Audit Management: Name of the audit management computer User:
42274 management service added in
User name reason: Error message
release 18.11
Stopped the audit management installation: Name of the installation Audit Management: Name of the audit management computer User:
42275
service added in release 18.11 User name
Failed to stop the audit

User name reason: Error message
release 18.11
Restarted the audit

User name
release 18.11
Failed to restart the audit

42278 installation: Name of the installation Audit Management: Name of the audit management computer User:
management service added in
Good User name reason: Error message
release 18.11
The Centrify Authentication Service UNIX Agent audit events are focused on the success or failure of starting and stopping the Centrify Agent: adclient.
Centrify Authentication Service UNIX Agent Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 17000. This log sample documents the successful start of the Centrify Agent:
adclient. The change was made by user=root on April 05 at 06:46:43.
Apr 5 06:46:43 newcentos adclient[1837]: INFO AUDIT_

TRAIL|Centrify Suite|DirectControl UNIX Agent|1.0|2000
Centrify Agent (adclient) started|5|user=root pid=1837
e616-44ff-a5f6-d3f53f09bb67 status=SUCCESS service=adclient
Centrify Authentication Service UNIX Agent Audit Events
Authentication Service UNIX Agent Audit Events
17000 Centrify Agent (adclient) started
17001 Centrify Agent (adclient) failed to start reason: error message
17002 Centrify Agent (adclient) stopped
17003 Centrify Agent (adclient) failed to stop reason: error message
Centrify Audit & Monitoring Service – Windows
Centrify Audit & Monitoring Service collects login success audit data from Windows computers. The Centrify Audit & Monitoring Service audit event focuses
on login success.
Centrify Audit & Monitoring Service – Windows Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 9001. This log sample documents a successful login. The change was made by
user=administrator@acme.test on January 06 at 15:53:10.
Jan 06 15:53:10 s2k8r2p1v1.acme.test wdad[1128]:

INFO AUDIT_TRAIL|Centrify Suite|DirectAudit -
Windows|1.0|1|login success|5|user=administrator
@acme.test userSid=S-1-5-21-1986235188-3370598863-
2160698129-500 sessionId=1 CentrifyEventID=9001
e616-44ff-a5f6-d3f53f09bb67
Centrify Audit & Monitoring Service - Windows Audit Events
Audit and Monitoring Service - Windows Audit Events
Event
Id
9001 login success
9002 logoff success
Enable Centrify Auditing and Monitoring Service succeeded added in release

9003 InstallationName: Installation Name
2017.3
Disable Centrify Auditing and Monitoring Service succeeded added in release

9004 InstallationName: Installation Name
2017.3
InstallationName: Installation Name Reason: Reason for

9005 Enable Centrify Auditing and Monitoring Service failed added in release 2017.3
failure
InstallationName: Installation Name Reason: Reason for

9006 Disable Centrify Auditing and Monitoring Service failed added in release 2017.3
failure
9007 Session auditing started added in Release 2020
9008 Session auditing ended added in Release 2020
Centrify Privilege Elevation Service – Windows
Centrify Privilege Elevation Service for Windows provides role-based access control for Windows desktops and applications, and to remote Windows servers.
Centrify Privilege Elevation Service for Windows audit events focus on successful and failed local console and remote log in attempts, administrative activity
using desktop or application privileges, network access to remote servers, changes to the zone information for Windows computers and changes to role
information for Windows users.
Centrify Privilege Elevation Service Windows Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 6029. This log sample documents a user with local and network role privileges
launching a .msc file.
Log Name: Application

Source: Centrify AuditTrail V2
Date: 9/19/2019 2:05:17 PM
Event ID: 6029
Task Category: None
Level: Information
Keywords: Classic
User: bob@acme.vms
Computer: member.acme.vms
Description:
Product: Centrify Suite
Category: DirectAuthorize - Windows
Event name: Run with privilege success
Message: User launched 'C:Program FilesCentrifyAccess
ManagerCentrifyDC.msc' on
desktop 'Default' using local role 'ROLE_SYSTEM_Archt/Global'
and network roles 'ROLE_SYSTEM_Archt/Global'.
Sep 19 14:05:17 member.acme.vms dzagent[1348]:
INFO AUDIT_TRAIL|Centrify Suite|DirectAuthorize - Windows|1.0|29|Run with
privilege
success|5|bob@acme.vms
userSid=S-1-5-21-569763308-1211465464-1224152175-3219
sessionId=3 CentrifyEventID=6029
DAInst=AuditingInstallation DASessID=c72252aa-e616-44ff-a5f6-d3f53f09bb67
role=ROLE_SYSTEM_Archt/Global
effectivesid=S-1-5-21-569763308-1211465464-1224152175-3219
effectivegroupsids=S-1-5-32-544
logonguid=ad7b6538-e2a4-4304-ab6e-86c5b0dabfaf
desktopguid=1e09a3dd-276f-4629-bb27-e215dfe0a0c8
command=C:Program FilesCentrifyAccessManagerCentrifyDC.msc
passwordprompted=False desktopname=Default
networkroles=ROLE_SYSTEM_Archt/Global
entityname=acme.vms mfarequired=False
Centrify Privilege Elevation Service - Windows Audit Events
Privilege elevation service - Windows Audit Events
Event ID Description Parameters
Console login success This

event has been deprecated.
6001-
Use Centrify Event Id 6031 Role: role DesktopGuid: desktop GUID
Deprecated
introduced in release 2017.2
instead.
Console login failure This

6002-
Use Centrify Event Id 6032
Deprecated
instead.
Remote login success This

6003-
Use Centrify Event Id 6033 Role: role DesktopGuid: desktop GUID
Deprecated
instead.
Remote login failure This

6004-
Use Centrify Event Id 6034
Deprecated
instead.
Run with privilege success

This event has been
6005- Role: local role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon
deprecated. Use Centrify
Deprecated GUID DesktopGuid: desktop GUID Command: command
Event Id 6029 introduced in
release 2017.2 instead.
Run with privilege failure

This event has been
6006-
deprecated. Use Centrify Role: local role DesktopGuid: desktop GUID Command: command
Deprecated
Create desktop success

This event has been
6007- Role: local role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon
Deprecated GUID DesktopGuid: desktop GUID
Create desktop failure This

6008-
Use Centrify Event Id 6036 Role: local role
Deprecated
instead.
Network access success

This event has been
6009-
deprecated. Use Centrify Role: role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon GUID
Deprecated
Console logon failure This

6010-
Use Centrify Event Id 6032 Reason: reason
Deprecated
instead.
Remote login failure This

6011-
Use Centrify Event Id 6034 Reason: reason
Deprecated
instead.
Run with privilege success

This event has been Role: local role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon
6012-
deprecated. Use Centrify GUID DesktopGuid: desktop GUID Command: command PasswordPrompted: whether user was required to re-
Deprecated
Event Id 6029 introduced in enter their password DesktopName: desktop name NetworkRoles: network roles

This event has been
6013- Role: local role DesktopGuid: desktop GUID Command: command Reason: reason DesktopName: desktop
Deprecated name NetworkRoles: network roles
Create desktop success

This event has been Role: local role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon
6014-
deprecated. Use Centrify GUID DesktopGuid: desktop GUID PasswordPrompted: whether user was required to re-enter their password
Deprecated
Event Id 6035 introduced in DesktopName: desktop name NetworkRoles: network roles

This event has been
6018- Role: local role DesktopGuid: desktop GUID Command: command Reason: reason DesktopName: desktop
Deprecated name NetworkRoles: network roles PasswordPrompted: whether user was required to re-enter their password
zone: zone name ZoneDomainName: zone domain name ComputerName: computer name
6023 Leave from zone success ComputerDomainName: computer domain name LogonUser: logon user LogonUserSid: logon user SID
AlternateUser: whether alternate user is used to perform the operation
zone: zone name ZoneDomainName: zone domain name RoleName: role name Assignee: assignee LogonUser:
Add role assignment
6027 logon user LogonUserSid: logon user SID AlternateUser: whether alternate user is used to perform the
success
operation
zone: zone name ZoneDomainName: zone domain name RoleName: role name Assignee: assignee Reason:
6028 Add role assignment failure reason LogonUser: logon user LogonUserSid: logon user SID AlternateUser: whether alternate user is used to
perform the operation
Role: local role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon
GUID DesktopGuid: desktop GUID Command: command PasswordPrompted: whether user was required to re-
6029 Run with privilege success
enter their password DesktopName: desktop name NetworkRoles: network roles EntityName: Entity Name
MFARequired: whether user was required to do MFA
Role: local role DesktopGuid: desktop GUID Command: command Reason: reason DesktopName: desktop
6030 Run with privilege failure name NetworkRoles: network roles PasswordPrompted: whether user was required to re-enter their password
EntityName: Entity Name MFARequired: whether user was required to do MFA
Role: role DesktopGuid: desktop GUID EntityName: Entity Name MFARequired: whether user was required to do
6031 Console login success
MFA
6032 Console logon failure Reason: reason EntityName: Entity Name MFARequired: whether user was required to do MFA
Role: role DesktopGuid: desktop GUID EntityName: Entity Name MFARequired: whether user was required to do
6033 Remote login success
MFA
6034 Remote login failure Reason: reason EntityName: Entity Name MFARequired: whether user was required to do MFA
GUID DesktopGuid: desktop GUID PasswordPrompted: whether user was required to re-enter their password
6035 Create desktop success
DesktopName: desktop name NetworkRoles: network roles EntityName: Entity Name MFARequired: whether
user was required to do MFA
Role: local role Reason: reason NetworkRoles: network roles PasswordPrompted: whether user was required to
6036 Create desktop failure
re-enter their password EntityName: Entity Name MFARequired: whether user was required to do MFA
DesktopName: desktop name DesktopGuid: desktop GUID PasswordPrompted: whether user was required to
6037 Switch desktop success re-enter their password Role: local role NetworkRoles: network roles EntityName: Entity Name MFARequired:
whether user was required to do MFA
DesktopName: desktop name Reason: reason PasswordPrompted: whether user was required to re-enter their
6038 Switch desktop failure
password EntityName: Entity Name MFARequired: whether user was required to do MFA
Role: role EffectiveSid: effective user SID EffectiveGroupSids: effective group SID's LogonGuid: logon GUID
6039 Network access success
EntityName: Entity Name MFARequired: whether user was required to do MFA
Self-service password reset

6040 success added in release Username: username
2017.3
Self-service password reset

6041 failure added in release Username: username Reason: failure reason
2017.3
Self-service account unlock

6042 success added in release Username: username
2017.3
Self-service account unlock

6043 failure added in release Username: username Reason: failure reason
2017.3
Enable Centrify Identity

Services Platform
6044 PlatformInstance: Platform Instance
succeeded added in release
2017.3
Disable Centrify Identity

Services Platform
6045 PlatformInstance: Platform Instance
succeeded added in release
2017.3
Enable Centrify Identity

6046 Services Platform failed PlatformInstance: Platform Instance Reason: Reason for failure
Disable Centrify Identity

6047 Services Platform failed PlatformInstance: Platform Instance Reason: Reason for failure
PowerShell remote
6048 connection success added User: user Role: role
in release 18.8
PowerShell remote
6049 connection failure added in User: user Reason: reason
release 18.8
Trouble ticket entered

6050 ticket: ticket reason: reason for privilege elevation comment: additional comment
Run with privilege as an GUID DesktopGuid: desktop GUID Command: command PasswordPrompted: whether user was required to re-
6051 alternate user success enter their password DesktopName: desktop name NetworkRoles: network roles EntityName: Entity Name
added in release 18.11 MfaRequired: whether user was required to do MFA AlternateUsername: An alternate username
AlternateUserSid: An alternate user's SID
Role: local role DesktopGuid: desktop GUID Command: command Reason: reason DesktopName: desktop
Run with privilege as an
name NetworkRoles: network roles PasswordPrompted: whether user was required to re-enter their password
6052 alternate user failure added
EntityName: Entity Name MfaRequired: whether user was required to do MFA AlternateUsername: An alternate
in release 18.11
username AlternateUserSid: An alternate user's SID
Windows authentication is
6053 skipped added in release service: service reason: Reason message for skip
18.11
Run with alternate account

Command: command AlternateUsername: alternate username tenant: tenant URL PasswordPrompted:
6054 success added in Release
whether user was required to re-enter their password
2020
Run with alternate account

Command: command AlternateUsername: alternate username tenant: tenant URL Reason: reason
6055 failure added in Release
PasswordPrompted: whether user was required to re-enter their password
2020
Add roles and features

6300 success added in release PID: process id user: username@domain status: succeeded feature: feature name computer: computer name
2018
Add roles and features PID: process id user: username@domain status: failed feature: feature name computer: computer name
6301
failure added in release 2018 reason: reason for failure
Remove roles and features

6302 success added in release PID: process id user: username@domain status: succeeded feature: feature name computer: computer name
2018
Remove roles and features PID: process id user: username@domain status: failed feature: feature name computer: computer name
6303
Uninstall program success

6350 PID: process id user: username@domain status: program: program name computer: computer name
added in release 2018
Uninstall program failure PID: process id user: username@domain status: failed program: program name computer: computer name
6351
added in release 2018 reason: reason for failure
Change program success

6352 PID: process id user: username@domain status: program: program name computer: computer name
Change program failure PID: process id user: username@domain status: failed program: program name computer: computer name
6353
Repair program success PID: process id user: username@domain status: succeeded program: program name computer: computer
6354
added in release 2018 name
Repair program failure PID: process id user: username@domain status: program: program name computer: computer name reason:
6355
added in release 2018 reason for failure
Enable network adapter

6400 success added in release PID: process id user: username@domain status: succeeded adapter: adapter name computer: computer name
2018
Enable network adapter PID: process id user: username@domain status: failed adapter: adapter name computer: computer name
6401
Disable network adapter

2018
Disable network adapter PID: process id user: username@domain status: failed adapter: adapter name computer: computer name
6403
Rename network adapter

2018
Rename network adapter PID: process id user: username@status: failed adapter: adapter name computer: computer name reason:
6405
failure added in release 2018 reason for failure
Update IPv4 settings

2018
Update IPv4 settings failure PID: process id user: username@domain status: failed adapter: adapter name computer: computer name
6407
Update IPv6 settings

2018
Update IPv6 settings failure PID: process id user: username@domain status: failed adapter: adapter name computer: computer name
6409
Auto-enroll as corporate
6500 owned device success computer: computer name tenant: tenant URL
Auto-enroll as corporate
6501 owned device failure added computer: computer name tenant: tenant URL reason: reason for failure
in release 2018
Unenroll device success

6502 user: user name computer: computer name
Unenroll device failure

6503 user: user name computer: computer name reason: reason for failure
Enroll as corporate owned

6504 device success added in user: user name computer: computer name tenant: tenant URL
release 2018
Enroll as corporate owned

6505 device failure added in user: user name computer: computer name tenant: tenant URL reason: reason for failure
release 2018
Enroll device success added

6506 user: user name computer: computer name tenant: tenant URL
in release 2018
Enroll device failure added in

6507 user: user name computer: computer name tenant: tenant URL reason: reason for failure
release 2018
Auto-unenroll success
6508 computer: computer name
Auto-unenroll failure added

6509 computer: computer name reason: reason for failure
in release 18.8
PowerShell remote
userSid: User SID userName: User name authMechanism: Authentication mechanism url: HTTP URL of inbound
6510 command execution added
request command: PowerShell remote command isScript: Command is a remote script
in release 2020.1
The Centrify Authentication Service UNIX Agent audit events are focused on the success or failure of starting and stopping the Centrify Agent: adclient.
Centrify Authentication Service UNIX Agent Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 17000. This log sample documents the successful start of the Centrify Agent:
adclient. The change was made by user=root on April 05 at 06:46:43.
Apr 5 06:46:43 newcentos adclient[1837]: INFO AUDIT_

TRAIL|Centrify Suite|DirectControl UNIX Agent|1.0|2000
Centrify Agent (adclient) started|5|user=root pid=1837
e616-44ff-a5f6-d3f53f09bb67 status=SUCCESS service=adclient
Centrify Authentication Service UNIX Agent Audit Events
Authentication Service UNIX Agent Audit Events
17000 Centrify Agent (adclient) started
17001 Centrify Agent (adclient) failed to start reason: error message
17002 Centrify Agent (adclient) stopped
17003 Centrify Agent (adclient) failed to stop reason: error message
dzdo
For Linux and UNIX computers, Server Suite includes authorization services that enable users to run with elevated privileges using the dzdo command line
program. The dzdo program is similar to sudo except that, instead of using a sudoers configuration file, the program uses the role-based access rights for
zones stored in Active Directory.
dzdo Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 30004. This log sample documents that the dzdo service has been granted
authorization.The change was made by user=dwirth(type:ad,dwirth@acme.vms) on April 7 at 01:20:12.

TRAIL|Centrify Suite|dzdo|1.0|0|dzdo
granted|5|user=dwirth(type:ad,dwirth@acme.vms)
pid=32224 utc=1460010012602 Centrify EventID=30004
-44ff-a5f6-d3f53f09bb67 status=GRANTED
service=dzdo command=/bin/vi runas=root role=ROLE_SYSTEM_
Archt/Global env=(none)
dzdo Audit Events
dzdo Audit Events
30000- dzdo granted This event has been deprecated. Use Centrify Event Id 30004 introduced command: command runas: username@domain
Deprecated in release 2017.3 instead. role: role name env: environment variables
dzdo denied This event has been deprecated. Use Centrify Event Id 30005 introduced
30001- in release 2017.3 instead. If the command is valid and requires authentication, Centrify command: command runas: username@domain
Deprecated Event Id 30005 is generated in release 2017.3 (and later versions) to show whether MFA reason: error message
is required or not.
30002 Trouble ticket entered ticket: ticket
command: command runas: username@domain

role: role name env: environment variables
30004 dzdo granted added in release 2017.3
MfaRequired: whether user was required to do MFA

30005 dzdo denied added in release 2017.3 reason: error message MfaRequired: whether user
was required to do MFA EntityName: Entity Name

role: role name env: environment variables
30100 dzdo command execution starts added in release 18.11
MfaRequired: whether user was required to do MFA
30101 dzdo command execution ends added in release 18.11
dzinfo
The dzinfo command displays rights, roles, and role assignments events. The dzinfo audit events focus on the success and failure of the dzinfo command.
dzinfo Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 42001. This log sample documents that a user failed run dzinfo to view another
user’s settings; only the user=root can view other user’s settings. The change was made by user=eugene.user(type:ad,eugene.user@CENTSPLUNK.COM)
on April 28 at 10:35:47.
Apr 28 10:35:47 sspl1-n2 adclient[1835]: INFO AUDIT_

TRAIL|Centrify Suite|dzinfo|1.0|3001|Dzinfo failed|5|user
=eugene.user(type:ad,eugene.user@CENTSPLUNK.COM)
pid=59947 utc=1461864947244 CentrifyEventID=42001
44ff-a5f6-d3f53f09bb67 status=FAILURE service=dzinfo
parameters=-c aaron.admin reason=Only root may view
other user's settings
dzinfo Audit Events
dzinfo Audit Events
42000 dzinfo successful parameters: parameters
42001 dzinfo failed parameters: parameters reason: error message
dzsh
For Linux and UNIX computers, Server Suite includes authorization services that enable users to run with elevated privileges in a restricted shell environment
using the dzsh program.
dzsh Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 33001. This log sample documents a user being denied dzsh command
execution.The change was made by user=dwirth(type:ad,dwirth@acme.vms) on April 7 at 01:20:12.
Apr 28 10:26:41 sspl1-n2 adclient[1835]: INFO AUDIT_

TRAIL|Centrify Suite|dzsh|1.0|1|dzsh command execution
denied|5|user=root pid=59860 utc=1461864401103 CentrifyEventID=33001
DAInst=AuditingInstallation
status=DENIED service=dzsh command=/usr/share/
Centrifydc/bin/dzinfo reason=sam checking returned false,
user is not allowed to use this command or runas
dzsh Audit Events
dzsh Audit Events
dzsh command execution granted This event has been

33000- command: command runas: username@domain role: role name env:
deprecated. Use Centrify Event Id 33002 instead, which was
Deprecated environment variables
introduced in release 2017.3.
dzsh command execution denied This event has been

33001-
deprecated. Use Centrify Event Id 33003 instead, which was command: command reason: error message
Deprecated
introduced in release 2017.3.
command: command runas: username@domain role: role name env:

33002 dzsh command execution granted added in release 2017.3 environment variables MfaRequired: whether user was required to do MFA
command: command reason: error message MfaRequired: whether user

33003 dzsh command execution denied added in release 2017.3
was required to do MFA EntityName: Entity Name
34000 dzsh role change granted fromRole: fromRole toRole: toRole
34001 dzsh role change denied
License Management
Auditing licenses are issued for each computer that will be connected to an auditing collector, and are managed by the Centrify Licensing Service. You can
use the Licensing Service control panel as described in the License Management Administrator’s Guide to add and remove licenses, monitor license usage,
and configure license usage notification.
License Management Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 20101. This log sample documents a user being denied an adjoin command execution
due to missing license information. The change was made by user=root on October 27 at 17:24:25.
Oct 27 17:24:25 Eason5 adjoin[9886]: INFO AUDIT_

TRAIL|Centrify Suite|Centrify Commands|1.0|2101|Join
failed|5|user=root pid=9886 utc=1477560265956
status=FAILURE service=adjoin parameters=-z developer
-p * eason.test zone=developer domain=eason.test
computer=eason5 runas=Administrator reason=Valid
Centrify license information was not found.
License Management Audit Events
License Management Audit Events
Event
ID
authentication service license key PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60100
added container: license container
Add authentication service license PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60101
key failed container: license container reason: Error message
authentication service license key PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60102
removed container: license container
Remove authentication service PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60103
license key failed container: license container reason: Error message
authentication service license PID: process id user: username@domain RunAs: username@domain type: user type container: license
60104
container added container
Add authentication service license PID: process id user: username@domain RunAs: username@domain type: user type container: license
60105
container failed container reason: Error message
authentication service license PID: process id user: username@domain RunAs: username@domain type: user type container: license
60106
container removed container
Remove authentication service PID: process id user: username@domain RunAs: username@domain type: user type container: license
60107
license container failed container reason: Error message
Add audit and monitoring service PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60200
license key failed installation: installation reason: Error
audit and monitoring service license PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60202
key removed installation: installation
Remove audit and monitoring service PID: process id user: username@domain RunAs: username@domain type: user type key: license key
60203
license key failed installation: installation reason: Error message
Kerberos
Audit events in the Kerberos category are focused on the success or failure of kerberos credential access. Audit events are recorded when programs access
the KCM (Kerberos Cache Manager) credential cache.
Kerberos Audit Event Log Sample
Sep 29 11:27:22 AbelRedhat5 adclient[8002]: INFO

AUDIT_TRAIL|Centrify Suite|Kerberos|1.0|200|Initializing
KCM credential cache succeeded|5|user=root pid=8584
utc=1538191642025 CentrifyEventID=63200 DASessID=N/A
DAInst=N/A status=SUCCESS service=kcm process=adclient
pid=8002 ccache=1001 principal=user1@ABEL.TEST
Kerberos Audit Events
Kerberos Audit Events
Event
ID
Generating new KCM credential cache name succeeded

63100 process: process name pid: process id ccache: Kerberos credential cache name
63101 Generating new KCM credential cache name failed process: process name pid: process id reason: error message
Initializing KCM credential cache succeeded added in process: process name pid: process id ccache: Kerberos credential cache name
63200
release 18.11 principal: principal name
Initializing KCM credential cache failed added in release process: process name pid: process id ccache: Kerberos credential cache name
63201
18.11 principal: principal name reason: error message
Destroying KCM credential cache succeeded added in

release 18.11
Destroying KCM credential cache failed added in release process: process name pid: process id ccache: Kerberos credential cache name
63301
18.11 reason: error message
Updating KCM credential cache succeeded added in process: process name pid: process id ccache: Kerberos credential cache name
63400
release 18.11 principal: user principal services: service principal
Updating KCM credential cache failed added in release process: process name pid: process id ccache: Kerberos credential cache name
63401
18.11 reason: error message
Retrieving credential in the given KCM credential cache

63500 process: process name pid: process id ccache: ccache name
Retrieving credential in the given KCM credential cache process: process name pid: process id ccache: Kerberos credential cache name
63501
failed added in release 18.11 reason: error message
Reading principal in the given KCM credential cache process: process name pid: process id ccache: Kerberos credential cache name
63600
succeeded added in release 18.11 principal: principal name
Reading principal in the given KCM credential cache failed process: process name pid: process id ccache: Kerberos credential cache name
63601
added in release 18.11 reason: error message
Iterating credentials in the given KCM credential cache

Event
ID
Iterating credentials in the given KCM credential cache process: process name pid: process id ccache: Kerberos credential cache name
63701
Reading credentials in the given KCM credential cache

Reading credentials in the given KCM credential cache process: process name pid: process id ccache: Kerberos credential cache name
63801
Removing credentials from KCM credential cache process: process name pid: process id ccache: Kerberos credential cache name
63900
succeeded added in release 18.11 principal: user principal services: service principal
Removing credentials from KCM credential cache failed process: process name pid: process id ccache: Kerberos credential cache name
63901
Iterating KCM credential caches succeeded added in

64000 process: process name pid: process id
release 18.11
64100 Reading KCM credential caches succeeded process: process name pid: process id
Reading KCM credential caches failed added in release

64101 process: process name pid: process id reason: error message
18.11
Changing the ownership for the given credential cache process: process name pid: process id ccache: Kerberos credential cache name uid:
64200
succeeded added in release 18.11 uid gid: gid
Changing the ownership for the given credential cache process: process name pid: process id ccache: Kerberos credential cache name
64201
Reading status for the given KCM credential cache

Reading status for the given KCM credential cache failed process: process name pid: process id ccache: Kerberos credential cache name
64301
Centrify administrators use the Local Account Management feature to create, manage, lock, and delete local UNIX and Linux user and group accounts. The
Local Account Management audit events focus on local users, groups, and accounts.
Local Account Management Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 51300. This log sample documents the removal of a local user from a local password
file. The change was made by user=root on November 25 at 16:51:20.
Nov 25 16:51:20 rhed57x64v3 adclient[4423]: INFO

AUDIT_TRAIL|Centrify Suite|Local Account
Management|1.0|300|Removing local user from local passwd
file|5|user=root pid=4423 utc=1448441900487 CentrifyEventID=51300
DAInst=AuditingInstallation
status=SUCCESS removedUser=locud01
Local Account Management Audit Events
Event Source Category: Local Account Management
51100 Adding enabled local user to local passwd file enabledUser: enabled local user
51200 Adding disabled local user to local passwd file disabledUser: disabled local user
51300 Removing local user from local passwd file removedUser: removed local user
51400 Local user is marked as disabled localUser: local user
51500 Local user is marked as enabled localUser: local user
51101 Local passwd file update failed reason: error message
51600 Invoking notification cli succeeded parameters: parameters
51601 Invoking notification cli failed reason: error message
52000 Adding enabled local group to local group file enabledGroup: enabled local group
52100 Removing local group from local group file removedGroup: removed local group
52001 Local group file update failed reason: error message
53000 Managing local accounts succeeded parameters: parameters
53001 Managing local accounts failed parameters: parameters reason: error message
53100 Added enabled local user added in Release 2020 localuser: user name
53101 Added disabled local user added in Release 2020 localuser: user name
53102 Failed to add local user added in Release 2020 localuser: user name reason: error message
53103 Removed local user added in Release 2020 localuser: user name
53104 Failed to remove local user added in Release 2020 localuser: name reason: error message
53105 Enabled local user added in Release 2020 localuser: user name
53106 Failed to enable local user added in Release 2020 localuser: user name reason: error message
53107 Disabled local user added in Release 2020 localuser: user name
53108 Failed to disable local user added in Release 2020 localuser: user name reason: error message
53109 Modified local user added in Release 2020 localuser: user name
53110 Failed to modify local user added in Release 2020 localuser: user name reason: error message
53111 Added local group added in Release 2020 localgroup: group name
53112 Failed to add local group added in Release 2020 localgroup: group name reason: error message
53113 Removed local group added in Release 2020 localgroup: group name
53114 Failed to remove local group added in Release 2020 localgroup: group name reason: error message
53115 Modified local group added in Release 2020 localgroup: group name
53116 Failed to modify local group added in Release 2020 localgroup: group name reason: error message
53117 Managed local users and groups added in Release 2020
53118 Failed to manage local users and groups added in Release 2020 reason: Reason for failure
53119 Invoked notification command added in Release 2020 command: notification command
53120 Failed to invoke notification command added in Release 2020 reason: Reason for failure
Multi-Factor Authentication
Multi-factor authentication (MFA) strengthens security by requiring users to provide more than one form of identification to authenticate their identity when
they attempt to access servers or applications. Multi-factor authentication challenges might require users to type a password, respond to an email message
or phone call, enter a passcode, or answer a security question. Audit events in the MFA category focus on the success and failure of MFA challenges.
Multi-Factor Authentication Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 54100. This log sample documents the success of an MFA challenge. The change
was made by user=laniu1(type:ad,laniu1@SINGLE01.CDC) on April 20 at 14:51:18.
Apr 20 14:51:18 sol112x64v3 adclient[5640]: [ID 702911

auth.info] INFO AUDIT_TRAIL|Centrify Suite|MFA|1.0
|100|MFA challenge succeeded|5|user=laniu1(type:ad,
laniu1@SINGLE01.CDC) pid=6160 utc=1461135078139
CentryifyEventID=54100 DAInst=AuditingInstallation
status=SUCCEED service=sshd tty=ssh client=::1
challenge=EMAIL
Multi-Factor Audit Events
MFA Audit Events
MFA challenge succeeded This event

54100- has been deprecated. Use Centrify
service: service tty: tty client: client challenge: challenge
Deprecated Event Id 54102 introduced in release
2017.3 instead.
MFA challenge failed This event has

54101- been deprecated. Use Centrify Event
service: service tty: tty client: client challenge: challenge reason: error message
Deprecated Id 54103 introduced in release 2017.3
instead.
service: service tty: tty authmethod: Reserved. factorcount: Number of MFA challenges factors: MFA
MFA challenge succeeded added in challenges used. mfaresult: MFA challenge status. sourcehost: Remote host username: Username
54102
release 2017.3 entityname: local system name devicetype: host operating system type initiatortype: MFA event type
entitytype: event type description rolename: DirectAuthorize role used command: command used
service: service tty: tty authmethod: Reserved. factorcount: Number of MFA challenges factors: MFA
challenges used. mfaresult: MFA challenge status. sourcehost: Remote host username: Username
MFA challenge failed added in
54103 entityname: local system name devicetype: host operating system type initiatortype: MFA event type
release 2017.3
entitytype: event type description rolename: DirectAuthorize role used command: command used
54200 MFA challenge succeeded service: service challenge: challenge
54201 MFA challenge failed service: service challenge: challenge reason: error message
54202 MFA is offline service: service reason: error message
54203 MFA is skipped service: service reason: message
MFA challenge succeeded added in

release 2017.3 This event has been service: service authmethod: authmethod factorcount: factorcount factors: factors mfaresult:
54204 deprecated. Use Centrify Event ID mfaresult sourcehost: sourcehost username: username entityname: entityname entitytype:
54206 instead, which was introduced entitytype devicetype: devicetype rolename: rolename command: command
in release 2018.

release 2017.3 This event has been service: service reason: error message authmethod: authmethod factorcount: factorcount factors:
54205 deprecated. Use Centrify Event ID factors mfaresult: mfaresult sourcehost: sourcehost username: username entityname: entityname
54207 instead, which was introduced entitytype: entitytype devicetype: devicetype rolename: rolename command: command
in release 2018.
service: service authmethod: authmethod factorcount: factorcount factors: factors mfaresult:

MFA challenge succeeded Added in mfaresult sourcehost: sourcehost username: username entityname: entityname entitytype:
54206
release 2018 entitytype initiatortype: initiatortype devicetype: devicetype rolename: rolename command:
command
service: service reason: error message authmethod: authmethod factorcount: factorcount factors:
MFA challenge failed Added in factors mfaresult: mfaresult sourcehost: sourcehost username: username entityname: entityname
54207
release 2018 entitytype: entitytype initiatortype: initiatortype devicetype: devicetype rolename: rolename
command: command
Setup MFA offline profile succeeded Username: The name of user configurationType: The MFA offline confguration type deviceType: The
54208
added in release 18.11 MFA offline device type
Setup MFA offline profile failed Reason: The reason why it is failed Username: The name of user configurationType: The MFA offline
54209
added in release 18.11 confguration type deviceType: The MFA offline device type
MFA challenge succeeded added in

54210 service: service authentication: authentication challenge: challenge
release 19.6

54211
release 19.6
PAM
A pluggable authentication module (PAM) is a mechanism to integrate multiple low-level authentication schemes into a high-level application programming
interface (API). The PAM audit events include authorization, credentials, account management, password changes, open session, and multi-factor
authentication.
PAM Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 24100. This log sample documents PAM authentication being granted. The change
was made by user=dwirth(type:ad,dwirth@acme.vms) on April 4 at 21:04:14.

TRAIL|Centrify Suite|PAM|1.0|100|PAM authentication
granted|5|user=dwirth(type:ad,dwirth@acme.vms) pid=7458
-44ff-a5f6-d3f53f09bb67 status=GRANTED
service=sshd tty=ssh client=dc.acme.vms
PAM Audit Events
PAM Audit Events
24100- PAM authentication granted This event has been deprecated. Use
service: service tty: tty client: client
Deprecated Centrify Event Id 24102 introduced in release 2017.3 instead.
24101- PAM authentication denied This event has been deprecated. Use
service: service tty: tty client: client reason: error message
Deprecated Centrify Event Id 24103 introduced in release 2017.3 instead.
service: service tty: tty client: client MfaRequired: whether user was
24102 PAM authentication granted added in release 2017.3
required to do MFA EntityName: Entity Name
service: service tty: tty client: client reason: error message

24103 PAM authentication denied added in release 2017.3 MfaRequired: whether user was required to do MFA EntityName: Entity
Name
24200 PAM set credentials granted service: service tty: tty client: client
24201 PAM set credentials denied service: service tty: tty client: client reason: error message
24300 PAM account management granted service: service tty: tty client: client
24301 PAM account management denied service: service tty: tty client: client reason: error message
24400 PAM change password granted service: service tty: tty client: client
24401 PAM change password denied service: service tty: tty client: client reason: error message
24500 PAM open session granted service: service tty: tty client: client
24501 PAM open session denied service: service tty: tty client: client reason: error message
24600 PAM close session granted service: service tty: tty client: client
24601 PAM close session denied service: service tty: tty client: client reason: error message
The user logins to the system in rescue mode added in release

24700 service: service tty: tty client: client
18.11
Trusted Path
The trusted path configuration parameter (audittrail.Centrify_Suite.Trusted_Path.machinecred.skipda) specifies whether trusted path audit trail events
are sent to the audit installation database in situations where the user is using a computer credential. The audit events identify a granted and denied Trusted
Path.
Trusted Path Audit Event Log Sample
The following is a sample of an audit event log for Centrify Audit Event ID 23700. This log sample documents a Trusted Path being granted. The change was
made by user=newcentos$@acme.vms on April 04 at 21:02:09.
Apr 4 21:02:09 newcentos adclient[1395]: INFO AUDIT

_TRAIL|Centrify Suite|Trusted Path|1.0|2700|Trusted path
granted|5|user=newcentos$@acme.vms pid=1395
utc=1459783929161 CentrifyEventID=23700 DAInst=AuditingInstallation
status=GRANTED server=ldap/dc.acme.vms@acme.vms
Note: The Trusted path audit event log sample identifies a server field type instead of the usual service field type found in UNIX/Linux audit
events.
Trusted Path Audit Events
Trusted Path Audit Events
23700 Trusted path granted server: server
23701 Trusted path denied server: server reason: error message
What Report Services Provides
Report services provides reports on your Active Directory environment and the data is stored in a database that’s optimized for reporting. You can
synchronize your Active Directory information to your reporting database, and then allow your users access to the reporting data.
You can choose to use SQL Server or PostgreSQL for your report database. If you use PostgreSQL, you must provide your own report software to create and
view reports.
If you're using SQL Server, the following diagram illustrates the main report services architecture components:
If you're using PostgreSQL, the following diagram illustrates the main report services architecture components:
Report services takes data from Active Directory at a particular point in time. The data collected at that point is sometimes referred to as a snapshot. The
Active Directory data synchronization service puts the Active Directory data into tables in the reporting database, and then runs some algorithms on those
tables. Some data is pulled over directly from Active Directory as it is, and some data is calculated.
For example, the effective role assignment for each computer and user is calculated rather than stored. Delinea does store the effective role assignment
information at the levels of role, computer, and zone. This information is then stored in the database views, and those database views provide the information
that you see in the reports.
The reporting service populates database views based on the data in those tables, and those views are what are used to populate reports.
Database views provide an easier and more secure way to share the reporting data without having to expose the database tables directly. Each view is
essentially a database query. Some columns refer to columns in other views, and these relationships are noted.
Each default report is based on one or more of those database views, and you can build custom reports based on the information stored in one or more of
those views.
For SQL Server databases, Delinea report services uses Microsoft SQL Server Reporting Services as the reporting engine for deploying and customizing
reports. You can use any reporting service to generate reports by connecting to the reporting database.
Reporting Data Based on Domains or Zones
Here are some key points to be aware of if you’re thinking of using report data based on zones:
For zone-based reporting, each synchronization includes all Active Directory data from the specified zones. In comparison, for domain-based reporting,
synchronizations after the first one include just the changes to Active Directory data.
For zone-based reporting, the service account needs just read permission to Active Directory. In comparison, for domain-based reporting, the service
account needs permission to replicate directory changes.
For zone-based reporting, report services does not synchronize license information nor auto-zone computer information.
For zone-based reporting, you can include zones from other trusted forests. For domain-based reporting, you can add trusted forest domains.
gMSA Accounts
Report services treats gMSA accounts (group Managed Service Accounts) as Active Directory users.
Information not included in the reporting database
There are few limitations on the kinds of data that can be stored in the reporting database. The following is not included:
NIS maps
UNIX import information
Report Services and Report Center
Report services provides more reports and features than the previous Report Center in Server Suite. Report Center has been deprecated and removed.
Report Services Tools Overview
Here’s an overview of the tools specific to Delinea report services. You’ll use some to all of these tools, depending on whether you’re completing your initial
installation or changing some configuration settings later on.
Tool or
component What you use this tool for
name
Report
Services Use this shortcut to open Delinea report services in Internet Explorer.
shortcut
Use the configuration wizard to do the initial setup of your database and reports. Re-run the configuration wizard only if you need to change
Configuration
some report services configuration settings or change whether you gather report data from Active Directory based on zones or domains.
wizard
For instructions, see Configuring Report Services and Deploying Your Reports .
Upgrade &
Use the Upgrade & Deployment wizard to upgrade your report database and deploy updated reports.
Deployment
For instructions, see Upgrading your report services.
wizard
Report Use the control panel to view the synchronization status of domains or zones, refresh report data, configure the synchronization schedule,
Services add or remove domains or zones, change the user account that runs the report service, and view error logs.
Control Panel For more details, see Administering Delinea Report Services with the Report Control Panel.
Server Suite Use the installer to either install or upgrade the report services and other Server Suite components.
installer For instructions, see Installing Delinea Report Rervices .
Overview of How to Set Up Reporting
If you’re installing an evaluation version of Delinea report services, you can take a few shortcuts, such as using virtual machines. This section includes
recommendations for both evaluation and production deployments.
The diagram below outlines the overall process for installation or upgrade.
Evaluation Deployment Overview
For evaluation purposes, you can just install the SQL Server Express version that’s packaged with the Server Suite software.
How to set up an evaluation version of Delinea report services:
1. Prepare your environment:

Users and groups with required permissions
1. service account - the user account that runs the reporting service (in the background)
2. installer/administrator - the user account that installs and configures the Delinea reporting service.
3. Report administrator - user(s) who can run reports, edit reports, build new reports
4. Report reader - user(s) who can view reports but not edit them nor create new ones.
An existing database instance, if you’re planning to use an existing instance.
The correct operating system that supports what you need. For evaluation purposes only, you can install all the software on one computer. Be sure
to check that your operating system is supported for Delinea software, SQL Server, and Microsoft SQL Server Reporting Services (SSRS).
You’ve configured Internet Explorer to allow access to the reporting web site. For details, see Adding Your Report Services Web Site to your
Internet Explorer Trusted Sites.
2. Run the Delinea installer. Install the report services on ONE computer in your domain.
Do not install Delinea report services on a domain controller.
If you’re upgrading from a prior version of Server Suite or Server Suite, the Access Manager reports are still there and they are installed anywhere
you install Access Manager. In contrast, the new reporting service installs into one place in your forest. Plus, the database is optimized for
reporting and retrieval.
3. Do the reporting configurations:
Run the Report Services Configuration wizard to configure the reporting service as needed, including starting the service.
Set up the report security for report administrators by assigning users and groups to SSRS roles. By default, all authenticated users have access to
view reports.
Configure Internet Explorer.
4. View and share the reports.
5. For custom report building, make sure that you’ve installed Report Builder for your version of SQL Server, if you don’t have it installed already. You may
need to download this separately.
Production Deployment Overview
For production deployments:
Delinea recommends that you use a production-capable version of SQL Server and not SQL Server Express.
SQL Server Express has a limit of 10Gb of data, does not provide the ability to schedule tasks
Delinea recommends that you do not use virtual machines.
Use at least 4 GB memory and 2 cores. leave enough memory for the operating system and allocate the rest to SQL server. For more details, see Memory
Requirements.
Delinea recommends that you use a new database instance; do not use an existing instance of SQL server. The reason for this is because uninstalling
SSRS leaves some files behind and can cause problems with re-installation, if you’re reusing the database instance. For more information, see Impact of
Using a New or Existing SQL Server instance.
If you're using a PostgreSQL database, Delinea recommends using a new PostgreSQL installation.
Do not install Delinea report services on a domain controller.
How to Set up a Production Version of Delinea Report Services
1. Prepare your environment:
Users and groups with required permissions. For details, see Before Installing - Prerequisites.
1. service account - the user account that runs the reporting service (in the background)
2. installer/administrator - the user account that installs and configures the Delinea reporting service.
3. Report administrator - user(s) who can run reports, edit reports, build new reports
4. Report reader - user(s) who can view reports but not edit them nor create new ones.
The correct operating system that supports what you need. The operating system needs to be supported for Delinea software, SQL Server, and
SQL Server Reporting Services (SSRS).
Don’t install SSRS on the domain controller.
IMPORTANT: Use an existing database instance with a real version of SQL Server, not the Express version. Express isn’t designed to handle the
performance needs of a production environment.
2. Run the Server Suite installer. Install the report services in ONE place in your forest.
If you’re upgrading from a prior version of Server Suite, the Access Manager reports are still there and they are installed anywhere you install
Access Manager. In contrast, the new reporting service installs into one place in your forest. Plus, the database is optimized for reporting and
retrieval.
3. Do the reporting configurations:
Configure the reporting service as needed, including starting the service.

Set up the report security: assign users and groups to SSRS roles and configure Internet Explorer.
4. View and share the reports.
5. For custom report building, make sure that you’ve installed Report Builder for your version of SQL Server, if you don’t have it installed already. You may
need to download this separately.
Upgrade Overview
How to upgrade Delinea Report Services:
1. If you’re upgrading from a version of Server Suite before version 2016, you need to install the report services components after you upgrade the other
components.
For details, see Upgrading from a Prior Version.
2. Run the installer program to upgrade your report services components.
For details, see Upgrading from a Prior Version and the Upgrade and Compatibility Guide.
3. Upgrade the report database and, if you’re ready to do so, redeploy your reports.
For details, see Upgrading your Report Services Database.
4. (Optional) If you want to switch from domain-based reporting to zone-based reporting, or the other way around, run the Configuration wizard to switch
modes.
This step is optional and you can do switch modes at any time, not just during upgrade.
For details, see Configuring Report Services and Deploying Your Reports.
Using this Guide
What Report Services Provides provides an overview of the report services features and tools, including deployment overviews for production and
evaluation deployments.
Installing and Configuring Delinea Report Services provides detailed instructions for installing, upgrading, and configuring report services.
Viewing Default Reports covers how to open a report, and provides some basic information on each of the default reports.
Building Custom Reports provides some information about how to build your own, custom reports.
Views to Use in Custom Reports lists the database views that you can use to populate your custom reports.
Configuring Report Services for Large Active Directory Environments provides helpful information unique to large deployments.
Troubleshooting Reports provides some helpful tips with common installation or configuration issues.
Synchronized Active Directory attributes for Reports lists the object attributes that report services synchronizes from Active Directory.
Installing and Configuring Report Services
Before Installing - Prerequisites
Installing Delinea Report Services
Configuring Report Services and Deploying Your Reports
Doing a Silent Install and Configuration
Upgrading from a Prior Version
Administering Delinea Report Services with the Report Control Panel
Configuring SQL Server Reporting Services (SSRS)
Re-deploying SQL Server Reports To SSRS
Note: If you are deploying into a large Active Directory environment, be sure to also read Memory Recommendations and Requirements for large
Active Directory environments.
Before Install: Prerequisites
Note: For the full set of platform requirements, please visit this web page in the Delinea Technical Support area:
https://www.centrify.com/support/whats-new/infrastructure-services/
Supported Versions of SQL Server and SSRS
To use Delinea report services, you need to use a SQL Server that is one of the following versions:
SQL Server 2008 R2

SQL Server 2012
SQL Server 2012 R2
SQL Server 2014
SQL Server 2016
For Microsoft SSRS, use the version that correlates with your SQL Server version. For example, if you’re using SQL Server 2012 R2, then use Microsoft SSRS
version 2012 R2.
Note: If you choose to use a version of SQL Server that requires .NET version 3.5 SP1, be sure to install .NET before configuring report services.
Note: If you run Report Services with Microsoft SQL Server 2012 Service Pack 2 and Visual Studio 2010 on the same system, please update Visual
Studio 2010 to Service Pack 1. (Ref: CS-38553a)
Supported Versions of PostgreSQL
Delinea Report Services works with PostgreSQL databases that are version 11 or later.
Supported Browser Versions
Use the web browser versions that Microsoft supports for use with SQL Server Reporting Services, as mentioned in this page:
https://msdn.microsoft.com/en-us/library/ms156511.aspx
For Internet Explorer, the version of SQL Server and SQL Server Reporting Services (SSRS) that you use also determines which version of Internet Explorer is
compatible with your deployment. Please consult the Delinea Knowledge Base article KB-6671 for details about which version of Internet Explorer you should
use.
Required User Permissions for Report Services
Before you install Delinea report services, be sure you have the appropriate software and user accounts, which includes the following:
Users with required permissions. Before installation, you must have users to run the Delinea installer.
Report service account
SQL Server service account (this is needed if you’re installing using an existing instance)
User accounts that can run the Report Configuration Wizard and the Reporting Control Panel. There are a few user accounts that you need to set up for
use with Delinea report services. Here is a summary of the user accounts that you need to create and the permissions you need to explicitly grant.
Report Services Account Permissions
Required security
policy
Required Active Directory Required SSRS Required SQL Server or
User type permissions(group
permissions permissions PostgreSQL permissions
policy, or local
policy)
For domain-based reporting:

Replicating directory changes
Required security
policy
Required Active Directory Required SSRS Required SQL Server or
User type permissions(group
permissions permissions PostgreSQL permissions
policy, or local
policy)
at the domain level (ADUC) and

report service account to run
replicate directory changes in Log on as a service
the Reporting Service
ADSI
For zone-based reporting: Read
permission
SQL Server service account to member of the securityadmin

n/a Log on as a service
run SQL Server role
the account must have

permission to connect to
PostgreSQL service account
PostgreSQL and create a
database
report admin to run the Report member of the securityadmin

Configuration wizard or the role (At the very least, the
needs to be a member of the Folder Settings > Content
Upgrade & Deployment wizard and n/a user needs permission to
domain Manager role
deploy reports to an existing SQL connect to SQL Server and
Server instance create a database.)
Read permission to the domain

root object of the selected
report admin to modify the
domain. Read permission to all n/a
Reports Control Panel
computer objects in the
selected domain.
Site settings > System user

role Folder settings >
Report viewer to view reports
browser (assign SSRS roles
from SSRS/Internet Explorer
to Active Directory group or
users)
Site settings > System user

Report writer read, write, edit
role Folder settings >
access for reports, in addition to
Content Manager role
the permissions needed to view
(assign SSRS roles to Active
reports
Directory group or users)
Note: Delinea Report Services requires administrator permission to install and upgrade. That also means that only an administrator can uninstall
and repair Delinea Report Services. (Ref: CS-40808a)
Grant the Report Service Account Permissions
For your convenience, below are reminders for how to grant the two sets of required permissions for the report service account.
Grant the Permission to Replicate Directory Changes in ADUC
To grant the permission to replicate directory changes at the domain level (read only):
2. From the View menu, select Advanced Features.
3. Right-click the domain object and select Properties.
5. Select the desired user account (add the account if it’s not listed there already).
6. In the Permissions area, next to Replicating Directory Changes, click Allow.
7. Click OK to save your changes.
For more information about setting this permission, see https://support.microsoft.com/en-us/kb/303972.
Grant the Permission To Replicate Directory Changes In ADSI
In addition to granting the replicate directory changes permission in Active Directory Users and Computers (ADUC), you also need to grant the same
permission in the ADSI Edit (Active Directory Services Interfaces Editor) console.
To grant the permission to replicate directory changes in ADSI (read only):
1. Open the ADSI Edit console.
2. From the Action menu, select Connect to.
The Connection Settings dialog box opens.
3. For the Connection Point, go to the "Select a well known Naming Context" drop-down menu and select Schema.
4. Click O K to close the dialog box.
The schema for the current domain displays in the ADSI Edit console.
5. Expand the schema listing so that you can see the first node of the schema, and right-click that node and select Properties.
The Attribute Editor dialog box opens.
7. Select the desired user account (add the account if it’s not listed there already).
8. In the Permissions area, next to Replicating Directory Changes, click Allow.
9. Click OK to save your changes.
Grant the Permission to Log on as a Service
To grant the log on as a service permission:
1. In the Group Policy Management Editor, apply the following policy to your desired user or group of users:
Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a
Service.
For more details about granting the log on as a service policy, see https://technet.microsoft.com/en-us/library/dn221981(v=ws.11).aspx.
SQL Server permissions that are set by the Configuration Wizard
Here are the SQL server permissions that report services grants to each user type, for your information. The Report Services Configuration wizard sets these
permissions automatically.
Sql Server Permissions Set by the Report Services Configuration Wizard (table)
report
services
account to run
Snapshot Service (predefined role)
the SQL Server
Reporting
Service
If you deploy to an existing SQL Server instance, the configuration wizard makes no changes to the SQL Server service account. If you
deploy to a new SQL Server instance: --If the operating system is Windows 2008 and you’re using a SQL Server version later than 2012,
SQL Server
virtual accounts are used for various SQL Server components, as follows: SQL Server engine: NT SERVICE\MSSQL$<InstanceName>
service
SQL Server Agent: NT SERVICE\SQLAgent$<InstanceName> Full text search: NT SERVICE\MSSQLFDLauncher$<InstanceName> SSRS:
account to run
NT SERVICE\ReportServer$<InstanceName> --Otherwise, the SQL Server service accounts are configured as follows: SQL Server
SQL Server
engine: NT Authority\Network Service SQL Server Agent: NT Authority\Network Service Full text search: NT Authority\Local Service
SSRS: NT Authority\Local Service
report admin
to run the
Report
Configuration
Connect SQL (cannot be revoked after setup) Create Database, Create any database, or Alter any database member of securityadmin
Wizard and
role, or Alter any login permission
deploy reports
to an existing
SQL Server
instance
report admin
to modify the
SnapshotAdmin (predefined role)
Reports Control
Panel
Report viewer
to view reports
from Login permission SnapshotViewer (predefined role)
SSRS/Internet
Explorer
Report writer
read, write, edit
access for
reports, in
Login permission SnapshotViewer (predefined role)
addition to the
permissions
needed to view
reports
Note: Microsoft SQL Server Reporting System (SSRS) affords only role-based security in their reports. Be sure to grant appropriate access to
reports. For example, if a user has access to only some data in the specified domain but all reports, they will be able to view all reports on all data
PostgreSQL Permissions that are Set by the Configuration Wizard
When you create the PostgreSQL database with the Configuration wizard, the wizard grants the administrator user one permission for Create Database.
Memory Requirements
Be sure that your computers running the following components meet or exceed the RAM requirements listed below.
Domain Controller Memory Requirements
The minimum amount of RAM that you should have available for your domain controller is the sum of the following:
Active Directory database size (for example, C:\Windows\NTDS\)

Total SYSVOL size (for example, C:\Windows\SYSVOL)
Recommended amount of RAM for your operating system
Vendor recommended amount of RAM for your various background software agents, such as anti-virus, monitoring, backup, and so forth.
Additional RAM to accommodate growth over the lifetime of the server.
For more information, see Microsoft recommendations here: http://social.technet.microsoft.com/wiki/contents/articles/14355.capacity-planning-for-

active-directory-domain-services.aspx.
Windows Memory Requirements
Here are the minimum and recommended memory requirements for report services and the report database:
Delinea report services: minimum 2 GB RAM, recommended 4 GB or above
SQL Server report database: minimum 4 GB RAM, recommended 32 GB or above
PostgreSQL report database: minimum 4 GB RAM, recommended 32 GB or above
SQL Server Recovery Model Requirement
In order for report services to function efficiently, it’s recommended that you configure your SQL Server database to use the Simple recovery model. The
recovery model configuration determines how SQL Server logs transactions, whether a database backs up the transaction log, and what kinds of restore
options are available.
For more information about recovery models, please visit https://msdn.microsoft.com/en-us/library/ms189275.aspx.
To configure the SQL Server database recovery model:
1. In SQL Server Management Studio, navigate to the database that you use for report services.
2. Right-click the database and select Properties.
3. In the Select a Page area, click Options.
4. For the Recovery Model option, select Simple.
5. Click O K to save the changes.
Impact of Using a New or Existing SQL Server Instance
When you set up your installation of Delinea report services, you have the option of either using an existing SQL Server instance or installing a new instance.
Delinea recommends that you use a new SQL Server instance, if possible.
If you choose to install a new instance from the Delinea Management Services installer program, the program installs an instance of SQL Server Express 2008
R2 with Advanced Services.
If you have an existing installation of SQL Server, you can create a new instance there first on your own, using your own installation media. When you install or
configure Delinea report services, you then configure report services to use your existing instance that you created. That way your SQL Server instances use
the same edition and version.
Tip: {/b}Please see the information at the following link for details about installing multiple versions and instances of SQL Server:
https://msdn.microsoft.com/en-us/library/ms143694(v=sql.130).aspx
Here are some issues to be aware of if you’re going to use a new SQL Server instance:
With a new SQL Server instance, you can avoid any potential problematic issues with SSRS, particularly if you need to reinstall SSRS.
SSRS won’t slow down the regular database operations on other instances.
To prevent the SQL Server instance from consuming too much memory, it’s recommended to use the max server memory to control each SQL Server
instance’s memory usage. The total allowance is not more than the total physical memory on the machine. If user is not running all of the instances,
none of the running instances will be able to utilize the remaining free memory.
Here are some issues to be aware of if you’re going to use an existing SQL Server instance:
There can be issues with SSRS and existing instances. If you have to uninstall and reinstall SSRS, it leaves files behind with the existing instance.
Using an existing SQL server instance can use all the free memory with a larger limit of the max server memory setting.
If you choose to deploy report services using an existing instance of SQL Server, your database administrator may need to know what changes that report
services needs to make to the database. (KB-8042)
The only modification that report services makes to an existing database instance is to add two Windows integrated logins, as follows:
Login Granted database role for the Report Service database
<The specified service account> SnapshotService
[NT Authority\Authenticated Users] SnapshotViewer
Note: If these logins already exist, report services does not re-create them.
Deploy in Multi-Forest Environments
If you’re deploying report services across multiple forests, there are a few tips to be aware of.
It is best to install report services once in a forest, and then monitor domains or zones in other trusted forests.
If you use domain-based mode, you need to install report services once in the domain. Make sure that any users who run report services and the service
account have access to the domains for which you want to run reports.
Note: If you need to grant access to a user account across a forest with a one-way selective trust, you enable selective authentication for
that user.
Enable Selective Authentication Across a Forest with a One-Way Selective Trust
The instructions below are provided as a courtesy; for more information on selective authentication, see the following article:
https://technet.microsoft.com/en-us/library/cc794747(v=ws.10).aspx
How to enable selective authentication for a user across an Active Directory forest that has a one-way selective trust:
1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain node for the forest root domain, and then click Properties.
3. On the Trusts tab, under either Domains trusted by this domain (outgoing trusts) or Domains that trust this domain (incoming trusts), click
the forest trust that you want to administer, and then click Properties.
4. On the Authentication tab, click Selective authentication, and then click O K.
6. Navigate to the Domain Controller the Report Services will use, right-click the computer object, and then click Properties.
7. On the Security tab add the desired user and grant Allow for the Allowed to authenticate permission.
See also the Delinea knowledge base article KB-8071.
Virtual Machines and Report Services
For production deployments, it is recommended to avoid using virtual machines for use with report services. (KB-7038)
In general, report services works well in virtual machines, including the case of installing SQL Server in a virtual machine.
However, in a large enterprise environment (such as where more than 100,000 users are enabled for authentication service), the SQL queries used for
generating reports may have significant CPU, memory and I/O requirements. In these situations, Delinea recommends the use of physical machines for SQL
Server to allow for better tuning of SQL Server without impacting other systems.
Alternatively, you can install SQL Server in a virtual machine. In such cases, Delinea recommends that you follow the guidelines provided by the virtualization
vendors:
https://www.vmware.com/files/pdf/solutions/SQL_Server_on_VMware-Best_Practices_Guide.pdf
http://download.microsoft.com/download/6/1/d/61dde9b6-ab46-48ca-8380-
d7714c9cb1ab/best_practices_for_virtualizing_and_managing_sql_server_2012.pdf
Installing Report Services
You use the same installer to install report services that you use to install other Server Suite components.
To install Delinea Report services:
1. Run the Delinea Management Services installer program that’s appropriate for your Windows system (64-bit only).
2. In the Getting Started screen, click Access.
3. In the Welcome screen, click Next to continue.
4. Review the license agreement, and click the option that indicates that you agree to the terms.
Click Next to continue.
5. In the User Registration screen, enter your name and company name.
6. Select the Centrify Report Services item.
![alt](images/installer.png "Installer")
You can install other Server Suite components at this time, or install the other components later.
Click __Next__ to continue.
7. In the Choose Destination Folder screen, specify the folder you want to install the software.
If you’re also installing Access Manager, you can select the options to automatically install desktop shortcuts.
In the Confirm Installation Settings screen, review the list of components that will be installed. If the list is correct, click Next to continue.
The program installs the files.
8. In the completion screen, select Configure Report Services and click Finish. Proceed to the next section, Configuring report services and
deploying your reports .
9. If you don’t want to configure report services right now, deselect the Configure Report Services option and click Finish. You can run the
configuration wizard later, if desired.
Configuring Report Services and Deploying Your Reports
You use the configuration wizard to both set up a new report services deployment or reconfigure an existing one.
If you want to just redeploy your reports, see Re-deploying SQL Server reports to SSRS.
Configuring a SQL Server Report Services Deployment
Follow these instructions if you're creating a new report services deployment using SQL Server or reconfiguring an existing SQL Server report services
deployment.
To configure report services with a SQL Server database:
1. If you need to start the Delinea Report Services configuration wizard, go to the Start menu > All Programs > Centrify Server Suite 2021.1 >
Report Services, and choose Configuration Wizard.
If you’re continuing from the Delinea Management Services installer, the installer started the configuration wizard for you.
2. On the Welcome screen, click Next to continue.
3. If you have already set up report services, the Reconfiguring Report Services screen displays. Select Reconfigure and click Next to continue.
4. On the Database Type screen, select SQL Server and click Next to continue.
5. Configure the SQL Server database connection:
1. Specify the SQL Server instance name.
Either specify a new SQL Server instance name, or select an existing SQL Server instance name. (The default instance name is CENTRIFYSUITE.)
The SQL Server instance name must be 16 characters or less, the name cannot begin with an underscore (_) or dollar sign ($), and the instance
name cannot contain any of the following special characters: a blank space, backslash (\), comma (,), colon (:), semi-colon (;), single quotation
mark ('), ampersand (&), hyphen (-), number sign (#), or at sign (@).
If you select an existing SQL Server instance, be aware that the SQL Server browser service must be running if SQL Server is a named instance or
using dynamic ports. If for some reason the SQL Server service can’t be started, you need to provide the SQL Server instance name and port
number in order to connect to the database successfully. For additional details, see https://technet.microsoft.com/en-
us/library/ms181087(v=sql.105).aspx.
Delinea recommends that you use a new SQL Server instance, if possible. For more information, see Impact of using a new or existing SQL Server
instance.
2. The default database name is Report. You can change this, if desired.
The SQL Server database name must be 16 characters or less, the name cannot contain any of the following special characters: backslash (\),
forward slash (/), colon (:), asterisk (*), question mark (?), double quotes (“), less-than sign (<), greater-than sign (>), pipe (|), comma (,) or
single quotation mark (').
3. Click Next to continue.
4. If you selected to install a new SQL Server instance, click Browse to navigate to and specify the location of the SQL server installation executable
(*.exe file).
The installer program installs SQL Server 2008 R2 Express with Advanced Services.
You can download the SQL Server Express with Advanced Services package directly from Delinea, for your convenience. Or, download the
package from Microsoft.
Please ensure to download the file name SQLEXPRADV_x64_ENU.exe (1,008.6 MB in size) as this is the one containing the 64-bit edition of SQL
2008 R2 with the necessary additional components to support Delinea Reporting Services.
6. Deploy the reports:
1. In the SQL Server Reporting Services screen, specify whether to deploy the Server Suite reports (or not).
If you plan to use a reporting solution other than Microsoft SQL Server Reporting Services, do not deploy the reports.
This screen also lists the URLs for the Reporting Web Service and Report Manager. You’ll use these URLs later to access to the reports.
If you’re using a production server of SQL Server and SSRS, you can configure them to use HTTPS. For details, see Microsoft SQL Server and SSRS
documentation, such as https://msdn.microsoft.com/en-us/library/ms345223.aspx.
The configuration wizard populates the report URLs automatically. If you had specified to use an existing SQL Server instance, the configuration
wizard retrieves the existing web service URL and report manager URL for your SQL Server instance.
For an existing SQL Server instance, you can open the Microsoft Reporting Services Configuration Manager to view the Web Service and Report
Manager URLs.
7. Choose domain or zone reporting:
Specify whether you want to choose data for reporting based on domains or zones. The default is domain-based reporting.
Click Next to continue. If you selected domain-based reporting, proceed to the next step. For zone-based reporting, go to Step 8.
8. If you selected domain-based reporting:
1. In the Monitored Domain(s) screen, you can review and edit the list of domains that will be included for reporting. Add or remove domains as
desired.
For each domain, the configuration wizard lists the domain name and the domain controller name.
9. If you selected zone-based reporting and you use hierarchical zones:
1. If you want data from all zones, select Monitor all hierarchical zones from forest(s). You can add or edit forests by clicking Edit and then
adding or removing forests.
2. Or, if you want to report data from specific zones, select Monitor only specific hierarchical zones.
3. Click Edit.
The Specify Forest for zone selection dialog box opens.
4. Enter the forest name where the desired zones are and click O K.
The Edit Monitored Hierarchical Zones dialog box opens.
5. Enter the hierarchical zones by name, or expand the list of zones to locate the desired zones manually.
6. If desired, specify to select the parent or child zones automatically.
7. Select the zone by putting a checkmark in the box next to the zone name.
8. When you’re done specifying which hierarchical zones to monitor, click O K to close the dialog box and return to the Configuration wizard.
Each zone that you’ve selected is listed in the Hierarchical Zones screen.
10. If you selected zone-based reporting and you use classic zones:
1. If you want data from all zones, select Monitor all classic zones from forest(s). You can add or edit forests by clicking Edit and then adding
or removing forests.
2. Or, if you want to report data from specific zones, select Monitor only specific classic zones.
3. Click Edit.
The Edit Monitored Classic Zones dialog box opens.
5. Select the classic zones to include in your reports. Select the zone by putting a checkmark in the box next to the zone name.
You can filter the list of zones by entering a portion of the name and clicking Filter.
6. When you’re done specifying which classic zones to monitor, click O K to close the dialog box and return to the wizard. Click Next to continue.
11. For zone-based reporting, you can also specify which domain controller(s) that the report service connects to.
If you don’t specify which domain controller(s) to use, report services will use the default domain controller.
1. Click A d d.
The Add Domain Controller dialog box opens.
2. Enter the domain name and then select the domain controller from the list.
3. Click O K to return to the Configuration wizard.
The domain controllers that you selected are listed in the wizard screen.
12. In the Synchronization schedule screen, specify how often you want the reporting service to pull data from Active Directory.
You can specify that the service synchronizes weekly, daily, every certain number of days, or every certain number of hours. The limit is 32,767 days or
weeks.
13. Configure the user account that runs the service:
1. In the Report Services options screen, specify the user account that will be used to run the service that synchronizes data from Active Directory
and the reporting database.
You can select a network service account, a managed service account, or another user account in Active Directory.
You must specify a user account that has the required permissions. The configuration wizard verifies that the user has the correct level of access.
3. The configuration wizard verifies that the specified user account has the required permission. An error displays if the permissions are inadequate.
4. If the permission verification is successful, click Close to close the Verify permission window.
14. Review and complete the installation:
1. In the Summary screen, review the installation details. If the installation settings are correct, click Next to continue.
If you’re installing a new database, it may take a few minutes.
2. (Optional) In the completion screen, if the installation is successful, you can select the option to synchronize Active Directory data with the report
database immediately. Depending on the Active Directory configuration and domain size, this operation can take awhile to complete.
Or, alternatively, you can run the synchronization at a more convenient time, using the Report Services Control Panel.
If the configuration was not successful, the configuration wizard provides some notes as to why the configuration failed. The notes may or may
not include knowledge base articles that are available at the Delinea Technical Support web site.
Configuring a PostgreSQL Report Services Deployment
Follow these instructions if you're creating a new report services deployment using PostgreSQL or reconfiguring an existing PostgreSQL report services
deployment.
To configure report services with a PostgreSQL database:
3. If you have already set up report services, the Reconfiguring Report Services screen displays. Select Reconfigure and click Next to continue.
4. On the Database Type screen, select PostgreSQL and click Next to continue.
5. On the PostgreSQL screen, specify to create a new PostgreSQL installation or use an existing one.
Because PostgreSQL doesn't have instances the way other databases do, Delinea recommends that you use an existing PostgreSQL database, if you
already have one set up.
For existing PostgreSQL installations, go to Step 8. Otherwise, for new installations, continue to Step 6.
6. To install a new PostgreSQL server, specify the PostgreSQL installer file location. You must specify a PostgreSQL installer version 11 or later. You can
find the installer file in Common\PostgreSQL.
7. Specify the location of the PostgreSQL ODBC driver installer file. Delinea includes this file with the report services installer in Common\PostgreSQL.
If you already have the official PostgreSQL ODBC drivers installed, this screen doesn't display.
8. Specify the PostgreSQL database settings:
ODBC Driver: For the PostgreSQL version that comes with report services, keep the default setting of PostgreSQL Unicode. This field can't be
changed for new installations.
Server: If you're using an existing PostgreSQL server, enter the server name. For example, localhost or servername.acme.com.
P o r t: If you don't enter a port number, report services uses the default port 5432.
Database: This is the database name. The name can be up to 63 characters long, and the name cannot begin with an underscore (_) or dollar
sign ($), and the instance name cannot contain any of the following special characters: a blank space, backslash (\), comma (,), colon (:), semi-
colon (;), single quotation mark ('), ampersand (&), hyphen (-), number sign (#), or at sign (@).
Database User: This is your PostgreSQL administrator user. If you're using an existing PostgreSQL installation, the user must have the Create
Database permission.
Password: This is the password for your PostgreSQL administrator user. If you're using an existing PostgreSQL installation, this is the password
for the user with the Create Database permission.
Confirm Password: If you're creating a new installation, enter your password again to ensure the password is correct.
Additional Parameters: Enter as needed. If you need to enter multiple characters, separate them with a colon (:).
Note: The Configuration wizard verifies these settings after you've continued through all the configuration screens. Also, if you haven't
installed the PostgreSQL ODBC driver, the Configuration wizard cannot verify these database settings.
desired.
3. Click Edit.
3. Click Edit.
1. Click A d d.
13. In the Synchronization schedule screen, specify how often you want the reporting service to pull data from Active Directory.
You can specify that the service synchronizes weekly, daily, every certain number of days, or every certain number of hours. The limit is 32,767 days or
weeks.
Note: Delinea Report Services does not include a reporting solution for use with PostgreSQL.
Changing the Monitoring Mode for an Existing Report Services Deployment
You can easily switch from gathering report data based on domains or zones.
To change the monitoring mode for an existing report services deployment:
1. If you need to start the Delinea Report Services configuration wizard, go to the Start menu > All Programs > Centrify Server Suite2021.1 >
3. On the Reconfiguring Report Services screen, select Switch the monitor mode if you want to change whether report services uses domains or
zones to synchronize Active Directory data. Click Next to continue.
4. On the Switch Monitor Mode screen, review the current and new mode settings. Click Next to continue.
To switch to domain-based reporting, go to Step 5.

To switch to zone-based reporting for hierarchical zones, go to Step 6.
To switch to zone-based reporting for classic zones, go to Step 7.
desired.
3. Click Edit.
3. Click Edit.
1. Click A d d.
Doing a Silent Install and Configuration
You can do what's called a silent install and configuration of Report Services, where you don't have to interact with a user interface and you plug in some
configuration values ahead of time.
Doing a Silent Install of Report Services
Follow this procedure if you're installing Report Services components newly or upgrading to the latest version.
To silently install Report Services
1. Open a command window and run it as administrator.
2. Navigate to the Report Services folder in the installer package:
Centrify-Server-Suite-version-mgmt-win64\DirectManage\Report Services
where version refers to the Server Suite release version.
3. Run the following command to install the Report Services files:
Centrify_RptServices-version-win64.msi /quiet
where version refers to component version.
The program installs the Report Services files into the default installation folder. You'll know that the install worked if you see newer files in that folder.
You're now ready to configure Report Services. For new installations, see the next procedure. For upgrades, see Upgrading the reporting database
silently.
Configuring a New Report Services Deployment Silently
There are a few main factors that drive which parameters to use in configuring Report Services silently (automatically without interaction):
Are you creating a new database instance or publishing to an existing instance?

Are you using PostreSQL or Microsoft SQL Server?
Are you using Report Services in zone mode or domain mode?
When doing a silent configuration of report services, you create a file named config.json with the configuration parameters that you need for your
deployment. For a list of the available parameters, see Report Services silent configuration parameters
Before you run the configuration program, be sure that you have the parameters set in the configuration file (config.json) and that you have the following
ready to enter at the command line:
ServiceAccount and ServiceAccountPassword

PgSQLUser and PgSQLUserPassword (if using PostgreSQL)
The installer also supplies some sample configuration files (in the Report Services installation folder) that you can use as a guideline, depending on your
deployment:
Database type Domain mode Zone mode
Microsoft SQL Server config_sql_server_domain_mode_sample.json config_sql_server_zone_mode_sample.json
PostgreSQL config_postgresql_domain_mode_sample.json config_postgresql_zone_mode_sample.json
To silently configure Report Services
1. Prepare the configuration file according to the settings you need.
2. Open a command line window as an administrator and run the report services configuration command according to the following usage:
Centrify.Report.Configuration.CLI.exe --ConfigFile "C:\\config.json" --ServiceAccount "Local System" --ServiceAccountPassword --PgSQLUser --PgSQLUserPassword
Parameter Description
--ConfigFile The configuration json file, including the path. You can name this file as desired, as long as it's a .json file.
--
IsGroupManagedServiceAccount Use this option to specify that the service account is a group managed service account (gmsa).
--ServiceAccount The service account to use to configure report services.
The service account password. If you're using a built-in account such as "Local System", you don't have to specify the
--ServiceAccountPassword
password.
--PgSQLUser If you use PostrgreSQL as your database, specify the PostreSQL user name
--PgSQLUserPassword The PostgreSQL password
The command does the configuration. If there is an issue or error, the command displays a message in red text. When the configuration succeeds, there's a
message in green text indicating that the configuration is done.
Report Services Silent Configuration Parameters
Use the following parameters in the Report Services configuration file (config.json). You don't need to use all of them; it depends on which kind of database
you use and whether you're configuring Report Services in domain mode or zone mode. These parameters match what you would enter in the installer
interface.
The installer also supplies some sample configuration files (in the Report Services installation folder) that you can use as a guideline, depending on your
deployment:
Database type Domain mode Zone mode
Microsoft SQL Server config_sql_server_domain_mode_sample.json config_sql_server_zone_mode_sample.json
PostgreSQL config_postgresql_domain_mode_sample.json config_postgresql_zone_mode_sample.json
Parameter
Parameter name Description Example
type
(PostgreSQL only) Use this parameter if you have

AdditionalParam string any additional PostgreSQL parameters that you
need to specify.
If you're creating a new database instance, this

"DBInstallerPath":
DBInstallerPath string parameter specifies the location of the database
"D:\\Common\\SQLEXPR\\SQLEXPRADV_x64_ENU.exe"
installer file.
If you're creating a new database instance, this

parameter specifies where to install the new "DBInstallationPath": "C:\\Program Files\\Microsoft SQL
DBInstallationPath string
database instance. For directories or path Server\\130"
separators, use \\ instead of \.
If you're creating a new database instance, the

DBName string "DBName": "Report"
name of the new database.
(Zone mode only) -- key = domain, value = domain

DomainControllers dictionary {"test.com": "dc.test.com"}
controller
(Domain mode only) Use this parameter to specify
Parameter
type
domain mode. Inside of this parameter you specify "DomainMode": { "MonitoredDomains": { "test.com":
DomainMode
the domains to synchronize to the reporting "dc.test.com", "us.test.com": "dc.us.test.com" } }
database.
list of string (Zone mode only) The forest that contains the
ForestsForClassicZones
values classic zones
list of string (Zone mode only) The forest that contains the
ForestsForHierarchicalZones ["companyA.com", "companyB.com"]
values hierarchical zones
(SQL Server only) If you're creating a new database

instance, the name of the new database instance.
InstanceName string "InstanceName": "REPORTS"
For directories or path separators, use \\ instead of
\.
true or (SQL Server only) Specifies whether or not to

IsDeployReport "IsDeployReport": true
false deploy reports.
Specifies the amount of detail that the installer

includes in the log file.
LogLevel string The format of the parameter is as follows: "LogLevel": "verbose"
Log level
(Off\|Critical\|Error\|Warning\|Information\|Verbose\|Trace)
(Zone mode only) If you use classic zones, use this

list of string ["test.com/Program Data/Zones/ZoneC",
MonitoredClassicZones (list) parameter to specify the list of zones to
values "test.com/Program Data/Zones/ZoneD"]
synchronize with report services.
list of string (Zone mode only) The list and location of ["test.com/Program Data/Zones/hZoneA",
MonitoredHierarchicalZones
values hierarchical zones "test.com/Program Data/Zones/hZoneB"]
true or Specifies whether to create a new database

NewDB "NewDB": true
false instance or not
(PostgreSQL only) The name of the ODBC driver to

OdbcName string "OdbcName": "PostgreSQL Unicode"
use to connect with the PostgreSQL database.
(PostgreSQL only) The path and filename of the

OdbcInstaller string
PostgreSQL installer file.
(PostgreSQL only) The port for the PostgeSQL

Port integer database. If you don't specify this parameter, the "Port": "5432"
default port of 5432 is used.
(SQL Server only) Specifies the report manager

"ReportManagerUrl":
ReportManagerUrl string URL. You use this URL to edit, publish, and
"http://MYCOMPUTER/Reports_REPORTS"
administer reports.
(SQL Server only) Specifies the web service URL

"ReportWebServiceUrl":
ReportWebServiceUrl string for deploying reports. You use the web service URL
"http://MYCOMPUTER/ReportServer_REPORTS"
to read reports.
You use this parameter in conjunction with the

ScheduleRule setting. With this parameter, you
specify the number of hours, days, or weeks to
configure how often the report synchronization will "ScheduleRule": "interval", "ScheduleFrequency": 2, The
Parameter
type
ScheduleFrequency integer happen. For example, if you set ScheduleRule to above example specifies that the report synchronization
weekly and you specify ScheduleFrequency to 1, will happen every 2 hours.
the synchronization will happen every week. If you
change the ScheduleFrequency to 3, the
synchronization will happen every 3 weeks.
You use this parameter in conjunction with the

ScheduleFrequency setting. With this parameter,
you specify what sets of time to count when "ScheduleRule": "weekly", "ScheduleFrequency": 2, The
ScheduleRule string scheduling the frequency of report services above example specifies that the report synchronization
synchronization. The options that you can specify will happen every 2 weeks.
are "daily", "interval", or "weekly". Interval specifies
an hourly interval.
Specifies the time of day to start the report

ScheduleStartTime (string) string services synchronization, in the 24 hour format of "ScheduleStartTime": "14:00:00",
hh:mm:ss.
Specifies on which days of the week the report

services synchronization will happen. You can
list of string specify "all" for a daily synchronization or "none" to
ScheduleWeekDays (list) "ScheduleWeekDays": ["mon", "wed", "fri"]
values just do it manually as needed. Otherwise, you can
specify one or more of the following for days of the
week: "mon", "tue", "wed", "thu", "fri", "sat", "sun"
(PostgreSQL only) The name of the PostgreSQL

Server string "Server":"localhost"
server.
SqlCmdTimeout int SqlCommand timeout (second) "SqlCmdTimeout": 3300
ZoneMode": { "MonitoredClassicZones": [],

(Zone mode only) Use this parameter to specify
"MonitoredHierarchicalZones": [ "test.com/Program
zone mode. Inside of this parameter you specify the
Data/Zones/hZoneA" ], "ForestsForClassicZones": [
ZoneMode MonitoredClassicZones and the
"test.com" ], "ForestsForHierarchicalZones": [],
MonitoredHierarchicalZones parameters and their
"DomainControllers": { "test.com": "dc.test.com",
respective settings.
"us.test.com": "dc.us.test.com" } }
Upgrading from a Prior Version
You can install or upgrade the report services components using the Delinea Management Services installer and then use either the Report Services
Configuration wizard or the Database Upgrade and Deployment wizard to get your database and reports set up. This table highlights which tools you can use,
depending on whether you have a previous version of report services installed or not.
Do you have a previous version Run the Server Suite

Then do this to get your database and reports set up
of report services installed? installer to do this
Install the report Run the Configuration wizard to configure report services and deploy reports.
No
services components For details, see Configuring Report Services and Deploying your Reports
Upgrade your report Run the Database Upgrade and Deployment wizard to upgrade your report database and
Yes
services components. deploy reports. For details, see Upgrading your report services database.
If you’re upgrading from a version of Server Suite prior to 2016 or you don’t currently have report services installed, you’ll need to specifically indicate during
the installation when you want to install the report services components - they aren’t installed by default during an upgrade.
Note: The Access Manager reports are still available, wherever you’ve installed Access Manager. Report services are in addition to the standard
Access Manager reports.
Upgrading Your Report Services Database
If you’re upgrading from a previous release of report services, you need to make sure that your report database is up to date. You’ll also need to deploy your
reports again so that they are based on the updated database.
The following SQL Server permissions are required in order to upgrade the report database with the Upgrade and Deployment wizard:
Execute stored procedure permission on report database

Create schema permission on report database
Create table permission on report database
Create view permission on report database
Create stored procedure permission on report database
Create type permission on report database
Alter any schema permission on report database
Insert, Delete, Update, Select and Execute permissions on the schema "Dbo", "RawData", "ReportData", "ReportView" and "ConfigData" on report
database
In order to deploy reports, you must have the Microsoft SQL Server Reporting Services role of Content Manager. For details for how to grant SSRS roles, see
Granting access in SSRS to reports.
To upgrade your report database:
1. From the Start menu, locate and run the Delinea Report Services Upgrade and Deployment wizard.
2. In the initial screen, click Next to continue.
3. The wizard upgrades the database automatically.
The database upgrade changes are saved to the database after you exit the wizard later.
4. If you have deployed reports before, configure where to back up the existing reports and where the new reports will be deployed.
If you haven’t deployed reports before, you’re prompted to specify where to deploy reports.
If desired, you can select the option to not backup nor deploy reports.
5. In the Summary screen, review the settings and if they’re correct, click Next to continue.
The wizard upgrades your report database.
6. In the completion screen, click Finish to exit the wizard.
(If the upgrade failed for any reason, the Summary screen displays some details about why the upgrade failed.)
Your report database is updated and your reports are deployed, if you specified the option to do so.
Note: After upgrade, you should perform a full synchronization before an incremental update is allowed. (Ref: CS-40029a)
Upgrading from Versions Before 2016
As of Server Suite 2016 the report services feature provides reports. If you’re upgrading from a version prior to release 2016 and you’re accustomed to the
Access Manager reports, this section covers the differences between the reports.
If you want to know which Delinea report services reports correspond to the Access Manager reports, below is a list. The reports are listed according to the
Access Manager report so that you can easily determine which new report you want to use instead.
Classic Zone Access Manager Reports
These Classic Zone reports correspond to the report services reports as follows:
Delinea report services report

Access Manager report name Includes this information by default
name
Classic Zone - Authorization Report for Lists each computer in the zone and indicates which users are allowed to
Authorization Report
Computers access each computer.
Classic Zone - Authorization Report for Lists each user account in the zone and indicates which computers each
Users user can access.
Classic Zone - User Privileged Command Lists the privileged commands that each user has permission to run and Classic Zone - User Privileged
Rights Grouped by Zone the scope to which the user’s rights apply. Command Rights Report
Classic Zone - User Role Assignments Classic Zone - User Role

Lists the role assignments for each user in each zone.
Grouped by Zone Assignment Report
Classic Zone - Users Report Lists information from the UNIX profile for each user in each classic zone.
Lists the roles that are defined for each classic zone and the rights
Classic Zone - Zone Role Privileges Zone Role Privileges Report
granted by each of these roles.
Hierarchical Zone Access Manager Reports
These Hierarchical Zone reports correspond to the report services reports as follows:
Delinea report services

report name
Hierarchical Zone - Computer Hierarchical Zone - Effective

Lists the audit level in effect for computers in each zone.
Effective Audit Level Audit Level

Lists the privileges granted on each computer.
Effective Rights Rights Report
Hierarchical Zone - UNIX User Lists the effective rights for each UNIX user on each computer. The report shows
Effective Rights the name of the right, it’s type, and where it is defined.
Hierarchical Zone - Windows User Lists the effective rights for each Windows user on each computer. The report
Delinea report services
report name
Effective Rights shows the name of the right, it’s type, and where it is defined.

Lists the roles assigned on each computer.
Effective Roles Role Report
Hierarchical Zone - Computer Role Lists the computer roles that are defined for each zone. The report includes the Hierarchical Zone - Computer
Assignments users and groups and their associated roles. Role Assignments Report
Hierarchical Zone - Computer Role Lists the computer roles that are defined for each computer and the zone to Hierarchical Zone - Computer
Membership which they belong. role Membership Report
Hierarchical Zone - Computer Role Lists the computer roles that are defined for each computer grouped by the zone
Membership Grouped by Zone to which they belong.
All Zone Access Manager Reports
These reports correspond to report services reports as follows:
Delinea
Access
report
Manager
Includes this information by default services
report
report
name
name
Computer Computers
Summary Lists computer account information for each computer in each zone. Summary
Report Report
Computers
Lists computer account information for each computer in each zone.
Report
Groups Groups
Lists group information for each group in each zone.
Report Report
Stale Stale
Computers Lists the stale computers. Computers
Report Report
User Lists account details for the users that have UNIX profiles in each zone. The report includes the Active Directory display name, User
Accounts the Active Directory login name, the Active Directory domain for the account, and details about the account status, such as Accounts
Report whether the account is configured to expire, locked out, or disabled and the date and time of the account’s last login. Report
Lists the zone properties for each zone. The report includes the zone name, list of available shells, the default shell, the default
Zones
home directory path, the default primary group, the next available UID, reserved UIDs, the next available GID, and reserved Zones Report
Report
GIDs.
Reports that are New to Access Manager Report Users
In addition to converting the content of the Access Manager reports into the report services reports, there are also the following new reports:
Hierarchical Zone - Computer Role Effective Assignments Report (one for UNIX, one for Windows)
Hierarchical Zone - Zone Effective Assignments Report (one for UNIX, one for Windows)
Attestation reports for SOX and PCI compliance
Upgrading the Reporting Database Silently
If desired, you can upgrade your report services database without any user interaction, after you install the latest version of the Report Services components.
You supply any of the parameters in the table below when you run the command line program. These parameters match the settings in the Upgrade and
Deployment wizard.
Parameter
type
Specifies whether or not to redeploy reports after you upgrade the database. If you
ReDeployReport switch include this parameter, the service will redeploy reports. If you don't include this --ReDeployReport
parameter, the service doesn't redeploy reports.
Specifies the path and folder location to backup existing reports before upgrading.
ReportBackupFolder string This option only applies if you specify ReDeployReport to yes. If you don't specify a
value for this property, the service uses the default value of "Backup reports".
Specifies the web service URL for deploying reports. You use the web service URL to "ReportWebServiceUrl":
WebServiceURL string
read reports. If you don't specify this value, the service uses the current setting. "http://server1/ReportServer_REPORTS"
Specifies the report manager URL. You use this URL to edit, publish, and administer "ReportManagerUrl":
ReportManagerURL string
reports. If you don't specify this value, the service uses the current setting. "http://server1/Reports_REPORTS"
To silently upgrade Report Services:
1. Install the latest version of the Report Services components. For details, see Silently installing Report Services.
2. At the command line (be sure to run as administrator), run the following command with the desired upgrade parameters, as listed in the table above.
None of the parameters are mandatory.
Centrify.Report.Upgrade.Cli.exe --ReDeployReport --ReportBackupFolder "previous-reports"
The upgrade program lists out each upgrade task that it performs as it progresses. When the program finishes, there's a message that says the upgrade is finished.
Administering Report Services with the Report Control Panel
You can use the Delinea Report Services Control Panel for the following tasks:
General Tab
View the status of data synchronization from Active Directory to the report database
View the domains or zones that are included for reporting
Start, stop, or restart the reporting service.
Monitored Zones Tab
Note: This tab appears only if you’ve configured reporting based on specific zones instead of domains.
Edit the Hierarchical or Classic zones that you want to include in your reports. You can add or remove zones, as desired, and you can select zones from
other trusted forests.
Settings Tab
Configure when the reporting service synchronizes data from Active Directory to the reporting database
Change the user account that runs the reporting service.
Add, edit, or remove domain controllers (in zone-based monitor mode) or domains (in domain-based monitor mode).
If you're using a PostgreSQL database, you can test the connection to the database.
Troubleshooting Tab
View the log files and set the level of detail that are collected in the log files.
Export diagnostics data for use by Delinea Technical Support (if technical support requests that you do so).
Rebuild or refresh the reports data
Validate that the reporting service has the correct permissions to read data from the monitored domains and replicate the data.
Configuring SQL Server Reporting Services (SSRS)
Adding your report services web site to your Internet Explorer trusted sites
Granting access in SSRS to reports
Providing reports to your users or auditors
Sharing reports by email or file sharing with report subscriptions
Adding Your Report Services Web Site to Your Internet Explorer Trusted Sites
Chrome, Firefox, and Safari are NOT supported for SSRS. This is a Microsoft limitation.
In order to view the reports in Internet Explorer, you also have to add the report server as a trusted site. (If you’re running an evaluation version, you can also
choose to disable the Internet Enhanced Security configuration, but it’s not recommended to do so.)
Please consult Microsoft documentation for the most current instructions for Internet Explorer configuration. However, for your convenience, here’s a quick
reminder of how to add a trusted site.
To configure Internet Explorer to trust the report services deployment site in the local intranet zone:
1. In Internet Explorer, go to Tools > Internet Options.
2. Click Security.
3. In the Zones area, click Trusted Sites.
4. Click Sites.
5. In the Trusted Sites dialog box, enter the web site address for your report services deployment, and click A d d.
For example, enter a URL that looks something like this: http://computername/reportinstancename.
6. Click Close, and then click O K to save the changes.
Granting Access in SSRS to Reports
Before you provide reports to your users, you need to give them the appropriate access within the Microsoft SQL Server Reporting Services application. You
use the SSRS role-based security to assign Active Directory users and groups to SSRS roles for both the site and folders.
Anyone reading reports will also need to configure their Internet Explorer installation, as mentioned in Adding your report services web site to your Internet
Explorer trusted sites.
Please consult Microsoft documentation for the most current instructions for security configuration and granting access in SSRS. For example, some
information can be found at this link:
https://docs.microsoft.com/en-us/sql/reporting-services/report-server/configure-a-native-mode-report-server-for-local-administration-ssrs?view=sql-
server-2016
However, for your convenience, a couple procedures are below.
To grant report administrator access in SSRS (SQL Server Reporting Services):
1. Run Internet Explorer as Administrator.
2. In Internet Explorer, go to your Report Manager URL.
You can open the Microsoft Reporting Services Configuration Manager to view the Report Manager URL.
Internet Explorer opens SQL Server Reporting Servies to your Report Manager URL.
3. Click Site Settings, and create a new role assignment so that you can assign the desired Active Directory group to the “System Administrator” role in
SSRS.
To create a new role assignment, click Security, then New Role Assignment.
4. Enter the group or user name (in the domain\username formet), select System Administrator, and click O K.
5. Click Home, and then click Folder settings. From there, create a new role assignment so that you can grant access to the “Content Manager” role.
6. To grant access so that the user can edit or build reports, you can give them additional permissions in SSRS, such as the Report Builder permission to
the Home folder.
To grant report read access in SSRS (an overview):
1. In SSRS, go to Site Settings, and create a new role assignment so that you can assign the desired Active Directory group to the “System user” role in
SSRS.
By default, all authenticated users are assigned to the System User role.
2. In SSRS, go to the Home folder, and then click Folder settings. From there, create a new role assignment so that you can grant access to at least the
“Browser” role.
3. To grant access so that the user can edit or build reports, you can give them additional permissions in SSRS, such as the Report Builder permission to
the Home folder.
Providing Reports to Your Users or Auditors
After you’ve made sure that your users have the appropriate read access to reports within SSRS, you provide the report URL to your users and instruct them to
access that URL within your domain and using the Internet Explorer browser. They may also need to add the report URLs to their trusted domains list; for
details, see Adding your report services web site to your Internet Explorer trusted sites.
Sharing Reports by Email or File Sharing with Report Subscriptions
You can also create report subscriptions so that you can easily share reports by way of email or a file share. These are features of Microsoft SSRS, and the
Microsoft documentation has the latest information.
In order to share reports by email, you first need to configure your report server for email delivery. For details, see https://msdn.microsoft.com/en-
us/library/ms345234(v=sql.110).aspx.
For details for how to share reports by email or file sharing, see https://msdn.microsoft.com/en-us/library/ms189680(v=sql.110).aspx.
Re-Deploying the SQL Server Reports to SSRS
You can re-deploy your reports without needing to go through the entire Delinea Report Services configuration wizard. You can only re-deploy reports if you
use SQL Server for your report database.
To configure Delinea report services using the configuration wizard:
3. On the Reconfiguring Report Services screen, select Deploy reports only and click Next to continue.
4. Deploy the reports:
1. In the SQL Server Reporting Services screen, specify whether to deploy the Server Suite reports (or not).
If you plan to use a reporting solution other than Microsoft SQL Server Reporting Services, do not deploy the reports.
This screen also lists the URLs for the Reporting Web Service and Report Manager. You’ll use these URLs later to access to the reports.
If you’re using a production server of SQL Server and SSRS, you can configure them to use HTTPS. For details, see Microsoft SQL Server and SSRS
documentation, such as https://msdn.microsoft.com/en-us/library/ms345223.aspx.
The configuration wizard populates the report URLs automatically. If you had specified to use an existing SQL Server instance, the configuration
wizard retrieves the existing web service URL and report manager URL for your SQL Server instance.
For an existing SQL Server instance, you can open the Microsoft Reporting Services Configuration Manager to view the Web Service and Report
Manager URLs.
Review and complete the installation:
Viewing Default Reports
This section covers how to open a report, and provides some basic information on each of the default reports.
Opening a Report
You open a report by going to the report folder URL in Internet Explorer. Click a report to open it.
In general, you and your users access the reports from a URL. The URL has a format like this:
"http://hostname/Reports_reportDBname"
Filtering Report Data by Zone
When you view a report, you can filter the report data by zone. In the zone drop-down filter, report services lists each zone by its full zone hierarchy, so that
you can choose based on parent or child zones. For example, if you have a child zone named California as part of a parent zone West which is part of the
parent zone United States, the zone appears in the list as "United States/West/California.
Zones are listed in the zone drop-down filter in alphabetical order, and the first zone in the list is the default zone. When you first open a report, report
services initially generates the report data based on the default zone.
Default Access Manager Reports
Report Services Reports: Not Specific to Classic or Hierarchical Zones
Report
Report description Filter the results with these fields
Name
Access Level Computer domain

Authorization This report lists each computer or user account, and which users are allowed to access each
Computer Name User domain User
report computer.
name User Type Zone Zone domain
Computers
Computer domain Computer name
Summary Lists computer account information for each computer in each zone.
Platform Zone Zone domain Zone type
report
Delegation Task Target Target Domain

Delegation Lists which users, groups, computers, group managed service accounts (gMSA), managed service
Target Name Trustee Trustee Domain
report accounts (MSA), and which well-known SIDs have which delegation tasks.
Trustee Type Zone
Active Directory User Domain Active

Effective
Lists which Active Directory users, Active Directory groups, group managed service accounts Directory User Name Delegation Task
delegation
(gMSA), and managed service accounts (MSA) have which delegation tasks. Target Target Domain Target Name
report
Zone
Lists group information for each group in each zone, including the Active Directory group name, Active Directory Group name Active
Groups the UNIX group name, the UNIX group identifier (GID), and whether the group is an orphan. If the Directory Group domain Group Type Is
report group is for local users, the local group status indicates whether the group is enabled or disabled Orphan Local Group Status UNIX Group
for local access. Name Zone Zone Domain Zone Type
Stale
Lists the stale computers. Stale computers are those where the password hasn’t changed for 90 or Computer Domain Computer Name
Computers
more days. Zone Zone domain
report
Lists account details for Active Directory users who are related to each zone. The report includes
User
the Active Directory display name, the Active Directory login name, the Active Directory domain for Active Directory user name Domain
Accounts
the account, and details about the account status, such as whether the account is configured to Enabled
Report
expire, locked out, or disabled and the date and time of the account’s last login.
Report
Report description Filter the results with these fields
Name
Active Directory user Active Directory

Lists user information for each user in each zone. If the user is a local user, the local user status user domain UNIX name Enabled Is
Users Report
indicates whether the user is enabled or disabled for local access. Orphan Local User Status User Type
Zone Zone domain Zone type
Zone Role
Lists the roles that are defined for each hierarchical zone and the rights granted by each of these Right name Right type Role name Zone
Privileges
roles. Zone domain Zone type
Report
Lists the administrative tasks and properties for each zone and the users or groups have been
Zones Report delegated to perform each task. This report indicates which users or groups have permission to Zone Zone domain
perform specific tasks, such as add groups, join computers to a zone, or change zone properties.
Delinea Report Services Reports: Classic Zone Reports
New default Filter the results

New report description
report with these fields
Classic Zone -
Classic zone Privileged
User Privileged Lists the privileged commands that each user has permission to run and the scope to which the user’s rights
command name User
Command Rights apply.
name Zone domain
Report
Classic Zone - Lists information from the UNIX profile for each user in each classic zone. Lists the role assignments for each Classic zone Role User
User Role user in each zone. The report includes the domain name, user profile name, the list of roles the user is domain User name
Assignment Report assigned to in each zone, and the scope to which the user’s role assignment applies. Zone domain
Delinea Report Services Reports: Hierarchical Zone Reports
New default report New report description Filter the results with these fields
Hierarchical zone -
Lists the computer roles that are defined for each zone. The report
Computer Role Role name Computer Role name Zone Zone domain
includes the users and groups and their associated roles.
Assignments Report
Hierarchical zone -
Computer Role Lists the roles assigned on each computer. There are separate reports Computer role Right Right type Role User Domain User
Effective for UNIX and Windows computers. Name Zone Zone Domain
Assignments Report
Hierarchical Zone -
Lists the computer roles that are defined for each computer and the Computer Domain Computer Name Computer Role in
Computer Role
zone to which they belong. Zone Computer Role Name Join To Zone Domain
Membership Report
Hierarchical Zone -
computer domain computer name User domain user
Effective Audit Level Lists the audit level in effect for computers in each zone.
name zone zone domain
Report
Hierarchical Zone -
Lists the privileges granted on each computer and the effective rights computer domain computer name Right Right type Role
Effective Rights
for each Windows and UNIX user on each computer. User domain user name zone zone domain
Report
New default report New report description Filter the results with these fields
Hierarchical Zone - computer domain computer name Role User domain user
Lists the role assignment on each computer in the zone.
Effective Role Report name zone zone domain
Lists the users and the computers to which they have access in the Active Directory user Active Directory user domain
Hierarchical Zone -
zone. If the user is a local user, the local user status indicates whether Computer Computer domain Is orphan Is secondary Local
Users Report
the user is enabled or disabled for local access. User Status UNIX name User type Zone Zone domain
Hierarchical Zone - Lists the roles that are defined for each hierarchical zone and the
Right Right type Role User domain user name zone zone
Zone Effective rights granted by each of these roles, including where each right is
domain
Assignments Report defined. There are separate reports for UNIX and Windows users.
Default SOX Attestation Reports
To help your department comply with Sarbanes-Oxley audit requirements, Delinea provides some default SOX reports. These reports show you who has
access to computers, what roles and rights users have, and similar data that’s needed to show SOX compliance.
SOX reports provide the following kinds of information:
Computers: Who has access to these computers, what are the roles, rights, and groups that they belong to
Groups: Which users are in which groups, what are the roles, rights, and what computers can these users access
Users: What their role assignments are, what rights the users have, which groups they belong to, and which computers they have access to
Roles: Which computers the rules have access to, what rights are assigned to the group, and which groups are assigned to which roles
You can find the SOX reports in SSRS by going to the Centrify Report Services > Attestation > SOX reports folder.
Note: In larger environments, you can save processing time when running an attestation report (PCI or SOX report) by choosing to exclude the
chart from the report. When you open the report, select True for the Exclude chart for faster report generation option.
For a description of how report services calculates the data for the charts in the SOX reports, see How objects are counted for the PCI and SOX report charts.
Here is a list of the SOX reports, along with a brief description and how you can filter the results.
Report name Report description Filter the results with these fields
SOX - Login For each computer, this report displays the users who can log in. For each
Computer Computer group Computer role Zone Zone
Report - By user who can log in, the report shows the role, assignment location, and
Domain Zone Type
Computer assignee.
SOX - Login
For each Active Directory group, this report lists the computers and role
Report - By Active Directory group Zone Zone Domain Zone Type
assignment information.
Group
SOX - Login
For each role, this report lists the computers assigned to that role. Role Zone Zone Domain Zone Type
Report - By Role
SOX - Login
For each user, this report lists the computers that the user can access as
Report - By User Zone Zone Domain Zone Type
well as the role assignment information.
User
SOX - Login
Computer Computer group Computer role Local User Status
Summary This report provides a summary of who can log in to which computer.
User User group User type Zone domain Zone type Zone
Report
SOX - Rights
For each computer, this report lists the users who have which login and Computer Computer Group Computer role Right type Zone
Report - By
other privileges and what the role assignments are. Zone Domain Zone Type
Computer
SOX - Rights
For each Active Directory group, this report lists the computers have Active Directory group Right type Zone Zone Domain Zone
Report - By
which login and other privileges and what the role assignments are. Type
Group
SOX - Rights For each role, this report lists the computer and rights available on that
Role Zone Zone Domain Zone Type
Report - By Role computer.
SOX - Rights
For each user, this report lists the Active Directory group, computers, and
Report - By Right type User Zone Zone Domain Zone Type
role assignment.
User
SOX - Rights Computer Computer group Computer role Local User Status
This report provides a summary of which rights are granted to which users
Summary Right type User group User User type Zone Zone Domain
on which computers.
Report Zone type
Note: When you view the collection of reports in Internet Explorer, you may also see some sub-reports listed. These are not actual reports but
views that support the actual reports; due to a limitation with Microsoft SSRS, these sub-reports may display even though they’re not meant to be
used. Please do not click any reports that have names that begin with SubReport.
Note: In these reports, Computer Role and Computer Group filters return records assigned to those roles or groups but not where the role
assignment is defined. For example, if you filter records for Zone1_CompRoleA, the report lists all computers that are in the computer role named
Zone1_CompRoleA.
Note: The charts in the PCI & SOX reports do not consider role assignments that are granted to “All Active Directory Users,” and the reports only
consider role assignments that are granted to specific users and groups when counting computer access and privileges. On the other hand, the
detailed report shows all the login and privilege information from all role assignments (including those that are granted to “All Active Directory
Users”).
Default PCI Attestation Reports
To help your department comply with PCI audit requirements, Delinea provides some default PCI attestation reports. These reports show you who has access
to computers, what roles and rights users have, and similar data that’s needed to show PCI compliance.
PCI reports provide the following kinds of information:
Computers: Which users have access to these computers, what are their roles and rights
Groups: Which users are in which groups, what are their roles and rights, and which computers do they have access to
Users: What role is the user assigned to, what rights does the user have, and which computers does the user have access to
Roles: What computers do these roles have access to and what rights do they have
You can find the PCI reports in SSRS by going to the Centrify Report Services > Attestation > PCI reports folder.
Note: In larger environments, you can save processing time when running an attestation report (PCI or SOX report) by choosing to exclude the
chart from the report. When you open the report, select True for the Exclude chart for faster report generation option.
For a description of how report services calculates the data for the charts in the PCI reports, see How objects are counted for the PCI and SOX report charts.
Here is a list of the PCI reports, along with a brief description and how you can filter the results.
PCI - Login For each computer, this report displays the users who can log in. For each
Computer Computer group Computer role Zone Zone Domain
Report - By user who can log in, the report shows the role, assignment location, and
Zone Type
Computer assignee.
PCI - Login
For each Active Directory group, this report lists the computers and role
Report - By Active Directory group Zone Zone Domain Zone Type
assignment information.
Group
PCI - Login
Report - By For each role, this report lists the computers assigned to that role. Role Zone Zone Domain Zone Type
Role
PCI - Login
For each user, this report lists the computers that the user can access as
Report - By User Zone Zone Domain Zone Type
well as the role assignment information.
User
PCI - Login
Computer Computer group Computer role Local User Status
Summary This report provides a summary of who can log in to which computer.
User User group User type Zone domain Zone type Zone
Report
PCI- Rights
For each computer, this report lists the users who have which login and Computer Computer Group Computer role Right type Zone
Report - By
other privileges and what the role assignments are. Zone Domain Zone Type
Computer
PCI- Rights
For each Active Directory group, this report lists the computers have which Active Directory group Right type Zone Zone Domain Zone
Report - By
login and other privileges and what the role assignments are. Type
Group
PCI- Rights
For each role, this report lists the computer and rights available on that
Report - By Role Zone Zone Domain Zone Type
computer.
Role
PCI- Rights
For each user, this report lists the Active Directory group, computers, and
Report - By Right type User Zone Zone Domain Zone Type
role assignment.
User
PCI - Rights Computer Computer group Computer role Local User Status
This report provides a summary of which rights are granted to which users
Summary Right type User group User User type Zone Zone Domain
on which computers.
Report Zone type
Note: When you view the collection of reports in Internet Explorer, you may also see some sub-reports listed. These are not actual reports but
views that support the actual reports; due to a limitation with Microsoft SSRS, these sub-reports may display even though they’re not meant to be
used. Please do not click any reports that have names that begin with SubReport.
Note: In these reports, Computer Role and Computer Group filters return records assigned to those roles or groups but not where the role
assignment is defined. For example, if you filter records for Zone1_CompRoleA, the report lists all computers that are in the computer role named
Zone1_CompRoleA.
Note: The charts in the PCI & SOX reports do not consider role assignments that are granted to “All Active Directory Users,” and the reports only
consider role assignments that are granted to specific users and groups when counting computer access and privileges. On the other hand, the
detailed report shows all the login and privilege information from all role assignments (including those that are granted to “All Active Directory
Users”).
How Objects are Counted for the PCI and SOX Report Charts
This section describes how objects are counted for the charts that you see in the PCI & SOX reports.
Login Report Charts
In login reports, we count how many computers each user can log in to, how many users can log in to each computer, and how many roles are granted with
login rights.
In hierarchical zones, a role is considered to be granted with a login right if one or more of the following rights are granted to the role:
Console login is allowed
Remote login is allowed
Password login and non-password login are allowed
Non password login is allowed
In classic zones, a role is considered to be granted with a login right if at least one PAM right is granted to the role.
In the graphs that report the number of users who can log in to a computer, or the number of computers that a user is logged in to; the graphs only consider
effective users. An effective user is one who has a complete user profile in a classic zone. In hierarchical zones, an effective user must also have been
granted the login right through any role that is assigned to users/groups. Note that a “login right” obtained from a role that is assigned to “All AD users” is not
considered in the graphs.
A local user is counted as an effective user in hierarchical zones if the user is granted the “User is visible” right from any effective role assignment.
Login Report – By Computer charts
Computers with Most Access chart
This chart ranks the computers by the number of effective users and shows the top 10 computers.
User Roles Count for Computers with Most Access chart
This chart ranks the computers by the number of roles that assign login rights to users or groups on the computer.
Users with Most Access chart
This chart ranks the users by the number of computers that each one can log in to, and shows the top 10 users.
Login Report – By Group charts
Roles with Most Access chart (by Group)
This chart ranks all the roles that are assigned to any group by the number of computers that the role grants login access to (regardless of how many groups
are assigned to each role), and shows the top 10 roles.
Groups with Most Members chart
This chart shows the top 10 groups that have most members, including those from nested groups.
Login Report – By Role charts
Roles with Most Access chart (by Role)
This chart ranks all the roles that are assigned by the number of computers that the role grants login access to, and shows the top 10 roles.
Roles with Most Users chart
This chart ranks the number of users for which each role is effective (regardless of the role assignment scope), and shows the top 10 roles.
Roles with Most Rights chart
This chart ranks the assigned roles (regardless of the role assignment scope) with login rights by the number of granted privilege access rights.
Login Report – By User charts
Users with Most Access On Computers chart
This chart ranks the users by the number of computers that each one can log into, and shows the top 10 users.
Login Roles Count for Users with Most Access On Computers chart
This chart ranks the users by the number of effective roles that grant login access to any computer, and shows the top 10 users.
Login Summary Report charts
Computers With Most Access chart
This chart ranks the computers by the number of effective users and shows the top 10 computers. Both Active Directory and local effective users are
considered.
Users With Most Access chart
This chart ranks all effective users by the number of computers that each user can log into, and shows the top 10 users.
Rights Report Charts
In each rights report, the privileged access right enables the user to create additional working environments or to run specified applications with different
privileges. The following five privileged access rights are included in rights reports.
Network Access right

Desktop right
Application right
Commands
Use restricted environment
Each privileged access right is counted in the reports only when the role with one of these rights is assigned to users and/or groups. However, the privileged
right granted using ‘All AD user’ is not counted.
Rights Report – By Computer Charts
Computers with Most Privileged Access chart
This chart ranks the computer by the number of distinct privileged access rights that are effective on each computer, and shows the top 10 computers. A
privileged access right is counted as one regardless of the number of users or roles that is granted or assigned the right in the computer.
Computer Roles with Most Privileged Access Chart
This chart ranks all the computer roles by the number of distinct privileged access rights assigned to each computer role, and shows the top 10 computer
roles.
Privileged Access with Most Computers Chart
This chart ranks all privileged access rights by the number of computers that each right is effective on, and shows the top 10 rights.
Rights Report – By Group Charts
Groups with Most Privileged Access Chart
This chart ranks the group by the number of distinct privilege access rights granted to each group, and shows the top 10 groups. The privilege access rights
are evaluated based on all roles that are assigned to groups, regardless of the scope of the assignments.
Rights Report – By Role Charts
Computer Roles with Most Privileged Access Chart
This chart ranks all the computer roles by the number of distinct privileged access rights assigned to each computer role, and shows the top 10 computer
roles.
User Roles with Most Privileged Access Chart
This chart ranks the assigned roles (regardless of the role assignment scope) with login rights by the number of granted privileged access rights.
Rights Report – By User Charts
Users with Most Privileged Access Chart
This chart ranks all users by the number of distinct privileged access rights granted (regardless of the number of computers) and shows the top 10 users.
Computer Role Count for Users with Most Privileged Access Chart
This chart ranks all users by the number of distinct privilege access rights granted. For the top 10 users, it shows the number of computer roles where the user
is assigned to any role in that computer role.
Rights Summary Report Charts
Computers with Most Privileged Access Chart
This chart ranks the computer by the number of distinct privileged access rights that are effective on each computer, and shows the top 10 computers. A
privileged access right is counted as one regardless of the number of users or roles that is granted or assigned the right in the computer.
Users with Most Privileged Access Chart
This chart ranks all effective users by the number of distinct privileged access rights granted (regardless of the number of computers) and shows the top 10
users.
Most Dominant Privileges on Computers chart
This chart ranks all privileged access rights by the number of computers that each right is effective on and shows the top 10 rights. The number of users
where the right is effective in each computer is not considered in the ranking.
Building Custom Reports
You can build your own reports with data from the Delinea report services database by using your own reporting tool or Microsoft SQL Server Reporting
Services.
Requirements and Recommendations
In order to build your own reports or customize existing reports, you also need to have the SSRS Report Builder installed where you have SSRS installed.
Known Limitations and Recommendations
Use the same domain where Microsoft SSRS is installed. If you try to use SSRS in a domain that is different from the domain where SSRS is installed, you
may have some difficulty accessing reports. For example, if your computer runs in the acme.com domain and you have SSRS installed in a test domain
of wiley.coyote.com, you may run into issues accessing the reports.
If you’re accessing SSRS from a different domain, make sure that you enter your credentials and save them.
When you log in to SSRS, make sure that the user you’re logging in as has at least the system user role, and at least read access to the folder (according
to the folder settings in SSRS).
An Overview of Report Building Tasks
Microsoft documentation contains specific instructions for how to create custom reports using SSRS Report Builder. Included here is the overall process;
please consult Microsoft SSRS Report Builder documentation for details.
For example, here’s a link to Microsoft information on using SQL Server Reporting Services 2012: https://technet.microsoft.com/en-
us/library/hh338693.aspx.
An overview of how to build custom reports using SSRS and Delinea report services data:
1. Open Internet Explorer to the deployed reports URL.
Make sure that you have the correct access permissions in SSRS for building reports. For details, see Granting Access in SSRS to Reports.
It’s recommended that you log in to the deployed reports URL as a user with Report Building permissions, but not database administrator
permissions. If you log in as a user with access to all tables in the reporting database, you may see tables that you cannot use in custom reports.
Delinea exposes the views for you to use in your custom reports.
2. Open Microsoft SQL Server Report Builder, and create the dataset that connects you to the reporting data source.
(The dataset is the set of data retrieved from the database, and the data source is the connection information for the database.)
3. Create a new report that’s based on the data set that you just created.
4. Design a query using the provided views.
5. Run the report to make sure that you get data in the report.
6. Edit the report as desired.
7. Save the report.
Microsoft SSRS saves the report as a .RDL file.
8. Publish the report by publishing the RDL file.
Migrating Custom Reports from SQL Server Express
If you create custom reports using the included version of SQL Server 2008 R2 Express edition, you can migrate those custom reports over to a production
SQL Server. You’ll need to download each custom report and then re-upload them into the production system.
To download your custom reports from SQL Server Express:
1. Create a temporary folder on your local computer.
You’ll use this folder to store your downloaded custom reports temporarily.
2. Open Delinea Report Services in Internet Explorer.
3. Navigate to the Custom Reports folder.
4. Select a report and select Download from the report’s action menu.
5. Save the downloaded report in the temporary folder that you already created.
Repeat this process for each report.
6. Close Internet Explorer.
To upload your custom reports to your production instance of SQL Server:
1. Run the Delinea Report Services Configuration wizard.

2. In the configuration wizard, choose the production SQL Server instance where you want to deploy the reports, then close the wizard.
3. Open Delinea Report Services in Internet Explorer.
4. Navigate to the Custom Reports folder.
5. For each report:
1. Click Upload File and select the custom report that you downloaded from your other instance.
2. After the report is uploaded, select the report and click Manage.
3. Click the Data Sources tab.
4. Select A shared data source and click Browse.
5. In the folder listing, expand the Centrify Report Services folder.
6. Select ReportDataSource and click O K.
7. In the Data Sources page, click Apply.
You can now open the custom report successfully using data in your production SQL Server instance.
Views to Use in Custom Reports
Database views provide an easier and more secure way to share the reporting data without having to expose the database tables directly. Each view is
essentially a database query. Some columns refer to columns in other views, and these relationships are noted.
Understanding the Differences Between Views
There are many views that are very similar to each other but provide different levels of details related to role assignments and so forth. This section briefly
covers the differences between views so that you can decide which view to use, based on your needs.
When choosing which view to use, keep in mind that a view that provides less detail results in a faster query response time.
What is Included in a View Which Views You Can Use
EffectiveAuthorizedUsers_Computer (Including computers in classic and hierarchical zones)

A list of who can log in to which computers EffectiveAuthorizedUsers_Computer_Classic (Only computers in classic zones)
EffectiveAuthorizedUsers_Computer_Hierarchical (Only computers in hierarchical zones
A list of who can log in to which computer and what EffectiveLoginUserPrivileges_Computer EffectiveAuthorizedUserPrivileges_Computer (Same as
privileges are granted to these users EffectiveLoginUserPrivileges_Computer, just to consist the naming as the other views)
A list of Active Directory users' effective role EffectiveRoleAssignment (Both hierarchical & classic zones) EffectiveRoleAssignment_Classic
assignments (Classic zones only) EffectiveRoleAssignment_Hierarchical (Hierarchical zones only)
A list of the Active Directory users' effective

privileges at the computer level (The Active
EffectiveRolePrivileges_Computer
Directory users list in the view may not have the
access right to the computer)
A list of the Active Directory users' effective system

rights at the computer level (The Active Directory
EffectiveSysRights
users list in the view might not have the access right
to the computer)
A list of the authorized users’ privileges The list

indicates if a role or right supports its accessibility EffectiveUserPrivileges_Computer
to the computer
EffectiveUserPrivileges_ComputerRole_Unix (Assuming all computers managed by the Computer

A list of the Active Directory users' privileges at the
Role are UNIX) EffectiveUserPrivileges_ComputerRole_ Windows (Assuming all computers
computer role level
managed by the Computer Role are Windows)
A list of the Active Directory users' privileges at the EffectiveUserPrivileges_Zone_Unix (Assuming all computers managed by the Zone are UNIX)
Zone level EffectiveUserPrivileges_Zone_Windows (Assuming all computers managed by the Zone are UNIX)
EffectiveAuthorizedLocalUsers_Computer (A local users' version to the

EffectiveAuthorizedUsers_Computer) EffectiveAuthorizedLocalUserPrivileges_Computer (A Local
Local users
users' version to the EffectiveLoginUserPrivileges_Computer) EffectiveLocalUsersRoleAssignment
(A Local users' version to the EffectiveRoleAssignment)
ADComputers View
The ADComputers view lists all Active Directory computers for each monitored domain.
Column name Description Refers to
ADComputer_-Account-Enabled 1 – Active Directory computer’s account is enabled, 0 – account is disabled
Column name Description Refers to
ADComputer_AccountEnabled_Desc The display value for ADComputer_Role (Yes/No)
ADComputer_-Canonical-Name Active Directory computer’s canonical name
ADComputer_CnName The Active Directory computer’s common name.
ADComputer_-Description The description to the Active Directory computer
ADComputer_-Dns-Host-Name Active Directory computer’s dnsHostName
ADComputer_DomainId The identification number of the computer’s domain. Domains.Id
ADComputer_Domain-Name The name of the domain that the Active Directory computer belongs to.
ADComputer_-GUID The object GUID of the Active Directory computer
ADComputer_Location The Active Directory computer’s location.
ADComputer_ManagerGUID The hosting Active Directory computer’s GUID for the user or group.
ADComputer_ManagerObjectName The Active Directory computer’s manager object name.
ADComputer_ManagerType The type of computer manager. 1=user, 2=group.
ADComputer_ManagerType_Desc The description of the Active Directory manager type.
ADComputer_ObjectName The object name of the computer, in the format of <computer CN>.<computer domain>.
ADComputer_-OS Active Directory computer’s operating system
ADComputer_-Os-Version Active Directory computer’s operating system version
ADComputer_OU The OU of the Active Directory computer. It will be null if the computer is not under an OU
The last changed time for Active Directory computer’s password (UTC time). This is an approximation
ADComputer_PwdLastChangedTime
only.
Whether the computer is running as a domain controller or not 1 - workstation role, 2 - domain
ADComputer_Role
controller role
ADComputer_Role_Desc The display value for ADComputer_Role (Workstation/Domain Controller)
ADComputer_-Sam-Account-Name Active Directory computer’s samAccountName
ADComputer_-Time-Created The creation time of the Active Directory computer (UTC time)
ADComputer_TrustedDelegate Allows services to act on behalf of another user.
Adcomputers Columns Used in Other Views
Column name Referred from other view
ADComputer_- ADGroupComputerMembers.ADComputer_GUID ComputerRoleMembership.ADComputer_GUID

GUID ZoneComputers.ZoneComputer_ADComputerId
ADComputers_Stale View
The ADComputers_Stale view lists all stale Active Directory computers for each domain. Computers are considered as stale if the passwords for them
haven’t changed for 90 or more days.
Column Name Description Refers to
ADComputer_AccountEnabled 1 – Active Directory computer’s account is enabled, 0 – account is disabled
ADComputer_AccountEnabled_Desc The display value for ADComputer_Role (Yes/No)
ADComputer_-Canonical-Name Active Directory computer’s canonical name
ADComputer_-Description The description about the Active Directory computer
ADComputer_DnsHostName Active Directory computer’s dnsHostName
ADComputer_DomainId The ID of the computer’s domain Domains.Id
ADComputer_DomainName The name of the domain which the Active Directory computer belongs to
ADComputer_GUID The object GUID of the Active Directory computer
ADComputer_ObjectName The object name of the computer, in the format of <computer CN>.<computer domain>.
ADComputer_OS Operating system of Active Directory computer
ADComputer_OsVersion The operating system version number of the Active Directory computer.
ADComputer_OU The OU of the Active Directory computer. It will be null if the computer is not under an OU
The last changed time for Active Directory computer’s password (UTC time). This is an approximation
ADComputer_PwdLastChangedTime
only.
Whether the computer is running as a domain controller or not 1 - workstation role, 2 - domain
ADComputer_-Role
controller role
ADComputer_Role_Desc The display value for ADComputer_Role (Workstation/Domain Controller)
ADComputer_SamAccountName Active Directory computer’s samAccountName
ADComputer_-Time-Created The creation time of the Active Directory computer (UTC time)
ADGroupComputerMembers View
The ADGroupComputerMembers lists all computers that are members for each Active Directory group. Nested members are included.
ADComputer_CanonicalName The canonical name of the Active Directory computer
ADComputer_DnsHostName The DNS host name of the Active Directory computer
ADComputer_GUID The GUID of the Active Directory computer ADComputers.ADComputer_GUID
The object name of the computer, in the format of <computer CN>.<computer

ADComputer_ObjectName
domain>.
ADComputer_Os The operating system name of the Active Directory computer
ADComputer_OsVersion The OS version of the Active Directory computer
ADComputer_SamAccountName The samAccountName of the Active Directory computer
ADGroup_CanonicalName The canonical name of the Active Directory group
ADGroup_GUID The GUID of the Active Directory group ADGroups.GUID
ADGroup_Name The name of the Active Directory group
The display name for the Active Directory group, formatted as <group
ADGroup_ObjectName
samAccountName>@<domain name>.
ADGroups View
The ADGroups view lists all Active Directory groups for each domain.
ADGroup_ManagerGUID The hosting Active Directory computer’s GUID for the user or group.
ADGroup_ManagerObjectName The object name for the user or group who manages this group.
ADGroup_ManagerType The type of object that is the manager for this group. 1=user, 2=group.
ADGroup_ManagerType_Desc The description of the Active Directory manager type.
CanonicalName Active Directory group’s canonical name
Description Active Directory group’s description
DomainId The identification for the domain which the Active Directory group belongs to Domains.Id
Email Active Directory group’s email
GroupName Active Directory group’s name
GUID The object GUID of the Active Directory group.
IsBuiltIn 1 – is built in group, 0 – is not built in group
NTLogonName The NT logon name (samAccountName) of the Active Directory group
The display name for the Active Directory group, formatted as <group samAccountName>@<domain
ObjectName
name>.
OU The OU of the Active Directory group. It is null if the group is not under an OU
TimeCreated The creation time of the Active Directory group (UTC time)
Type The scope of the Active Directory group 1 - domain local, 2 - global, 3 - universal
ADGroups columns used in other views
ADGroupComputerMembers.ADGroup_GUID ADGroupUserMembers.ADGroup_GUID EffectiveZoneGroups.ZoneGroup_ADGroup_GUID

ADGroups.GUID ZoneGroups.ZoneGroup_ADGroup_GUID EffectiveUserPrivileges_Computer.Trustee_Id
EffectiveUserPrivileges_ComputerRole.Trustee_Id EffectiveUserPrivileges_Zone.Trustee_Id
ADGroupSubGroups View
Lists the Active Directory group and the nested groups, including children groups and grand-children groups.
ParentGroup_CanonicalName The canonical name of the parent group
ParentGroup_DomainId The domainID of the parent group Domains.Id
ParentGroup_DomainName The domain name of the parent group
ParentGroup_GroupType The group type of the parent group 1-Domain local, 2-Global, 3-Universal
ParentGroup_GroupTypeDesc The display value for ParentGroup_GroupType (Domain local/Global/Universal)
ParentGroup_NTLogonName The NTLogonName of the parent group
The object name of the parent group. The general display value for the AD group in precanned
ParentGroup_ObjectName
report. Format:<AD group samAccountName>@<domain Name>
ParentGroup_ParentGroupGUID The object GUID of the parent group ADGroups.GUID
ParentGroup_ParentGroupName The name of the parent group
SubGroup_CanonicalName The canonical name of the sub group
SubGroup_DomainId The domainIDof the sub group Domains.Id
SubGroup_DomainName The domain name of the sub group
SubGroup_EffectiveSubGroupGUID The object GUID of the sub group ADGroups.GUID
SubGroup_GroupName The group name of the sub group
SubGroup_GroupType The group type of the sub group 1-Domain local, 2-Global, 3-Universal
SubGroup_GroupTypeDesc The display value for SubGroup_GroupType (Domain local/Global/Universal)
The NTLogon name of the sub group Note: There is also a column with a similar name,
SubGroup_NTLogonName
SubGroup_NTLogoName, that will be deprecated in a future release.
The object name of the sub group. The general display value for the AD group in precanned report.
SubGroup_ObjectName
Format:<AD group samAccountName>@<domain Name>
ADGroupUserMembers View
The ADGroupUserMembers view lists all user members for each Active Directory group. Nested members are included.
ADGroup_CanonicalName The canonical name of the Active Directory group
ADGroup_GUID The GUID of the Active Directory group ADGroups.GUID
ADGroup_Name The name of the Active Directory group
The display name for the Active Directory group, formatted as <group
ADGroup_ObjectName
ADUser_GUID The GUID of the Active Directory user ADUsers.ADUser_GUID
ADUser_Name The name of the Active Directory user
ADUser_ObjectName The object name for the Active Directory user.
ADUser_SamAccountName The samAccountName of the Active Directory user
ADUser_UPN The upn name of the Active Directory user
ADUsers View
The ADUsers view lists all Active Directory users for each monitored domain.
ADUser_AccountExpiryDate The expiration date for the Active Directory user account.
ADUser_AccountLockedUntil The date and time until which time that the user’s account is locked.
ADUser_AccountLockedUntil_Desc The description text string for the ADUser_AccountLockedUntil field.
ADUser_CannotBeDelegated Cannot be delegated.
ADUser_CanonicalName The canonical name of the Active Directory user
ADUser_City The city of the Active Directory user
ADUser_Company The company of the Active Directory user
ADUser_Country The country of the Active Directory user
ADUser_CreationTime The creation time of the Active Directory user
ADUser_Department The department of the Active Directory user
ADUser_Description The description of the Active Directory user
ADUser_DialInCallbackNumber The dialin callback number of the Active Directory user
ADUser_DialInCallbackOptions The dialin callback options of the Active Directory user
ADUser_DialInCallerId The dialin callerIDof the Active Directory user
ADUser_DialInStaticIp The dialin static IP address of the Active Directory user
ADUser_DialInStaticRoutes The dialin static routes of the Active Directory user
ADUser_DisplayName The display name of the Active Directory user
ADUser_DomainId TheIDof the Domain Domains.Id
ADUser_DomainName The name of the Domain
ADUser_Email The email of the Active Directory user
ADUser_Enabled If the Active Directory user account is enabled 1 – Enabled, 0 - Disabled
ADUser_Enabled_Desc The description string for the aduser_enabled (Yes / No)
ADUser_FaxNumbers The fax numbers of the Active Directory user
ADUser_FirstName The first name of the Active Directory user
ADUser_GUID The GUID of the Active Directory user
ADUser_HomePhoneNumbers The home phone numbers of the Active Directory user
ADUser_Initials The initials of the Active Directory user
ADUser_IpPhoneNumbers The ip phone numbers of the Active Directory user
ADUser_IsNeverExpire Specifies if the user account is set to never expire.
ADUser_IsNeverExpire_Desc The description text string for the ADUser_IsNeverExpire column.
ADUser_JobTitle The job title of the Active Directory user
ADUser_LastLogonTime The last logon time of the Active Directory user
ADUser_LastName The last name of the Active Directory user
ADUser_LogonScriptPath The logon script path of the Active Directory user
ADUser_ManagerGUID The hosting Active Directory user's GUID of the user or group
ADUser_ManagerObjectName The Active Directory user's manager object name
ADUser_ManagerType The Active Directory user's manager type 1 - User, 2-Group
ADUser_ManagerType_Desc The Active Directory user's manager type description (User/Group)
ADUser_MobilePhoneNumbers The mobile phone numbers of the Active Directory user
ADUser_Name The name of the Active Directory user
The display name for the Active Directory user, formatted as <user
ADUser_ObjectName
ADUser_Office The office of the Active Directory user
ADUser_PagerPhoneNumbers The pager phone numbers of the Active Directory user
ADUSer_PasswordNeverExpire Password set to never expire.
ADUser_PhoneNumbers The phone numbers of the Active Directory user
ADUser_PoBox The post office box address of the Active Directory user.
ADUser_PostalCode The postal code (zip code) of the Active Directory user.
ADUser_PreauthenticationNotRequired Pre-authentication not required.
ADUser_PrimaryGroupId The primary group ID of the Active Directory group.
ADUser_ProfileHomeFolder The profile home folder of the Active Directory user
ADUser_ProfilePath The profile path of the Active Directory user
ADUser_PwdLastSetTime The password last set time of the Active Directory user. This is an approximation only.
ADUser_PwdStoreUsingReversibleEncryption Password stored using reversible encryption.
ADUser_RemoteAccessPermissions The remote access permissions of the Active Directory user
ADUser_SamAccountName The samAccountName of the Active Directory user
ADUser_SmartCardNeededForLogon Smart card needed for login.
ADUser_State The state of the Active Directory user
ADUSer_Street The Active Directory user’s street address.
ADUser_TrustedForDelegation Trusted for delegation.
ADUser_Upn The upn name of the Active Directory user
ADUser_UseDesEncryption Uses DES Encryption.
ADUser_WebPages The web pages of the Active Directory user
ADUser Columns Used in Other Views
ADGroupUserMembers.ADUser_GUID EffectiveUserPrivileges_Computer.ADUser_GUID
EffectiveUserPrivileges_ComputerRole.ADUser_GUID EffectiveUserPrivileges_Zone.ADUser_GUID
ADUsers.ADUser_GUID
EffectiveZoneUsers.ZoneUser_ADUserGUID ZoneUsers.ZoneUser_ADUserGUID EffectiveUserPrivileges_Computer.Trustee_Id
EffectiveUserPrivileges_ComputerRole.Trustee_Id EffectiveUserPrivileges_Zone.Trustee_Id
ApplicationRight View
The ApplicationRight view lists the detailed attributes for each application right.
Right_Description The description of the application right
Right_FullName The full name of the right <right name>/<zone name>
Right_GUID The GUID of the Right Rights.Right_GUID
Right_Name The name of the application right
Right_Priority The priority of the application right
Right_RequireAuthentication If this right requires authentication 1 – Yes, 0 – No
Right_RequireAuthentication_Desc If this right requires authentication (Yes/No)
Right_RunasUser Run as the specified AD user
Right_ZoneId The Id of the Zone that the Right belongs to Zones.Zone_Id
Right_ZoneName The name of the Zone that the Right belongs to
AutoZoneComputers View
The AutoZoneComputers view lists the computers that are joined to the AutoZone.
ZoneComputer_ADComputerCnName AD computer’s cn name
ZoneComputer_ADComputerId The GUID of the AD computer ADComputers_ADComputer_GUID
ZoneComputer_ADComputerName AD computer’s name
Format: <AD computer CN>.<AD computer domain> Mainly used by

ZoneComputer_ADComputerObjectName
precanned-report
ZoneComputer_AgentVersion The agent version of the Auto Zone Computer
The IDof the computer type of the Auto Zone Computer. This value is
ZoneComputer_ComputerType
always 2
The computer type of the Auto Zone Computer. This value is always
ZoneComputer_ComputerType_Desc
‘Unix’
ZoneComputer_Id The ID of the Auto Zone Computer
ZoneComputer_IsOrphan To identifier if this is an orphan Auto Zone Computer 1 – Yes, 0 – No
ZoneComputer_IsOrphan_Desc (Yes/No)
ZoneComputer_Name The name of the Auto Zone Computer
ZoneComputer_ZoneId The ID of the zone. Always be -1
ZoneComputer_ZoneName The name of the zone. The value is always ‘Auto Zone’
CommandRight View
This view lists the detailed attributes for each command right.
Right_AddVar Comma separated list of environment variable name-value pairs to add
Right_AllowNested Nested command execution is allowed or not 1 – Yes, 0 – No
Right_AllowNested_Desc The description to the Right_AllowNested (Yes/No)
Right_Authentication Type of authentication required to run the command
Right_DeleteVar Comma separated list of environment variables to delete in addition to the default set
Right_Description The description of the command right
Right_DzdoRunAsGroup Comma separated list of groups allowed to run this command using dzdo
Right_DzdoRunAsUser Comma separated list of users, uids, groups or gids allowed to run this command using dzdo
Right_DzshRunas The user this command will run as under dzsh
Right_FullName The full name of the command rights. Format <command right name>/<zone name>
Right_GUID The GUID of the command right Rights.Right_GUID
Right_KeepVar Comma separated list of environment variables to keep in addition to the default set
Right_MatchPath The match path of the command right
Right_Name The name of the command right
Right_Pattern The pattern of the command right
Right_PatternType The type of the command right pattern 0 – Global, 1 – Regular expression
Right_PatternType_Desc The description of the type of the command right pattern (Global / Regular expression)
Right_PreserveGroup Preserve group membership or not
Right_Priority The priority of the command right
Right_UMask The umask value used to define who can execute the command
Right_ZoneId The ID of the zone that the command right is defined Zones.Zone_Id
Right_ZoneName The name of the zone that the command right is defined
ComputerRoleCustomAttribute View
This view lists the computer role custom attributes.
RoleAssignment_GUID The computer role’s object GUID. ComputerRoles.ComputerRole_GUID
CustomAttribute_Name The custom attribute’s name.
CustomAttribute_Value The custom attribute’s value.
ComputerRoleEffectiveMembers View
This view lists the effective members of a computer role.
ComputerRole_GUID The GUID of the Computer Role
ComputerRole_ZoneId The zone ID where the Computer Role is defined Zones.Zone_Id
ComputerRole_ComputerRoleName The name of the Computer Role
ADComputer_GUID The object GUID of the Active Directory computer ADComputes.ADComputer_GUID
ADComputer_DomainId The ID of the computer’s domain Domains.Id
Format: <AD computer CN>.<AD computer domain> This field is mainly used by
the default reports.
ADComputer_CnName The Active Directory computer’s cnName
ZoneComputer_Id The ID of the computer
ZoneComputer_ZoneId The ID of the zone that the computer is managed by Zones.Zone_Id
ZoneComputer_Name The name of the computer
ZoneComputer_AgentVersion The agent version of the computer
ZoneComputer_Platform The platform of the computer 1 – Windows, 2 – UNIX
ZoneComputer_Platform_Desc The description string of the ZoneComputer_Platform (Windows/UNIX)
ZoneComputer_IsOrphan If the computer is orphan 1 – Yes, 0 – No
ZoneComputer_JoinDate The date when the computer joined zone (UTC time)
ComputerRoleMembership View
The ComputerRoleMembership view lists all computer members for each Computer Role. The view includes computers that have been added into the zone.
ADComputer_DnsHostName The dns host name of the Active Directory Computer
ADComputer_DomainId The domain ID of the Active Directory computer Domains.Id
ADComputer_GUID The GUID of the Active Directory computer ADComputes.ADComputer_GUID
The object name of the computer, in the format of <computer CN>.<computer

domain>.
ComputerRole_ComputerRoleName The name of the Computer Role
ComputerRole_GUID The object GUID of the computer role
ComputerRole_ZoneId The ID of the zone where this computer role is defined Zones.Zone_Id
ZoneComputer_AgentVersion The agent version of the computer
ZoneComputer_Id The ID of the computer
ZoneComputer_IsOrphan If the computer is orphaned 1 – Yes, 0 – No
ZoneComputer_JoinDate The date when the computer joined zone (UTC time)
ZoneComputer_Name The name of the computer
ZoneComputer_Platform The computer platform 1 – Windows, 2 – Unix
ZoneComputer_PlatformDesc The display value of ZoneComputer_Platform (Windows/Unix)
ZoneComputer_ZoneId The ID of the zone where the computer is joined to Zones.Zone_Id
ComputerRoles View
This view lists the computer role information.
ComputerRole_Description The description of the Computr Role
ComputerRole_GroupGUID The GUID of the AD group which the Computer Role monitoring ADGroups.GUID
ComputerRole_GroupName The name of the AD group which the Computer Role monitoring
ComputerRole_GUID The GUID of the Computer Role
ComputerRole_Name The name of the Computer Role
ComputerRole_ZoneId The ID of the zone where the Computer Role is defined Zones.Zone_Id
ComputerRole_ZoneName The name of the zone where the Computer Role is defined
DelegationTasks View
This view lists which user, group, computer, or well-known SID have which delegation tasks.
Target The target in which the Server Suite task is delegated
Target_DomainId The domain ID of the target Domains.Id
Target_GUID The GUID of the target
Zone_Id The zone ID Zones.Zone_Id
Scope The scope in which the Server Suite task is delegated
Scope_Id The scope ID: 1 - Zone; 2 - UNIX Computer; 3 - WINDOWS Computer; 4 - Computer Role
Trustee_Name The trustee name
The trustee type is one of the following: 1 - User; 2 - UNIX computer; 3 - Windows computer; 4 -
Trustee_Type
computer role.
Trustee_Type_Desc The description of the trustee type
Trustee_DomainId The domain ID of the trustee Domains.Id
Task_Id Task Id DelegationTaskType.Task_Id
Task_Name Task name
DelegationTaskType View
This view lists the Server Suite delegation tasks.
Task_Name Task name
Task_Id Task Id
Domains View
The Domains view lists all monitored domains.
Column Name Description
Dc The domain controller for the monitored domain
DomainName The name of the monitored domain
Id The ID of the monitored domain
Domains Columns Used in Other Views
Column
Referred from other view
name
ADComputers.ADComputer_DomainID ADComputers_Stale.ADComputer_DomainId ADGroups.DomainId ADUsers.ADUser_DomainID
ComputerRoleMembership.ADComputer_DomainId RoleAssignments_ComputerRole.RoleAssignment_ZoneDomainId
Domains.Id
UserAccounts.ADUser_DomainId ZoneRolePrivileges.ZoneRolePrivileges_RightZoneDomainId Zones.Zone_DomainID
Zones_Classic.Zone_DomainID Zones_Hierarchical.Zone_DomainID
EffectiveAuthorizedUserPrivilegesSummary View
This view lists effective privileges rights granted to Active Directory users for both hierarchical and classic zones.
ADUser_GUID The object GUID of the Active Directory user that the user profile refers to. ADUsers.ADUser_GUID
ZoneComputer_ID The object GUID ID of the computer profile ZoneComputers. ZoneComputer_Id
Right_GUID The GUID of the right Rights.Right_GUID
EffectiveAuthorizedUserPrivilegesSummary__Hierarchical View
This view lists effective privileges rights granted to Active Directory users for just hierarchical zones.
EffectiveAuthorizedUserPrivilegesSummary_Classic View
This view lists effective privileges rights granted to Active Directory users for just classic zones.
EffectiveAuthorizedLocalUserPrivileges_Computer View
This view lists the authorized local user’s effective rights and privileges for each computer.
ADComputer_CanonicalName The canonical name of the Active Directory computer
ADComputer_CnName The cn name of the Active Directory computer
ADComputer_DnsHostName The dns host name of the Active Directory computer
ADComputer_ObjectName The object name of the Active Directory computer
Assigned_Location The display value of the source assignment location
Assigned_LocationType The source assignment location
The type of the source assignment location 1 – Zone 2 – Computer 3 –

Assigned_LocationType_Desc
Computer Role
EffectiveZone_Id The auto generated ID of the Zone Zones.Zone_Id
EffectiveZone_Name The name of the Zone
LocalUser_Name The name of the local user
The profile state of the local user 1 =Enabled, 2 = Disabled, 3 = Removed from
LocalUser_ProfileState
/etc/passwd
The display value for LocalUser _ProfileState (Enabled/Disabled/Removed

LocalUser_ProfileState_Desc
from /etc/passwd)
Right_FullName The full name of the right. Format in <Right name> / <Right’s zone name>
Right_Grants_Logon If this right could support a user to logon to a system 1 – Yes, 0 – No
Right_Name The name of the right
Right_Platform The ID of the right platform
Right_Platform_Desc The display value of the right platform
Right_Type The type ID of the right RightType.RightTypeId
Right_Type_Desc The type description of the right
Role_FullName The full name of the role. Format in <Role name> / <Role’s zone name>
Role_GUID The GUID of the role Roles.Role_Id
Role_Name The name of the role
RoleAssignment_GUID The object GUID of the role assignment RoleAssignments.RoleAssignment_GUID
Trustee_Name The trustee name of the role assignment
Trustee_Type The trustee type ID of the role assignment TrusteeTypes.TrusteeType_Id
Trustee_Type_Desc The type description of the trustee
ZoneComputer_Id The object GUID ID of the computer profile ZoneComputers. ZoneComputer_Id
EffectiveAuthorizedLocalUsers_Computer View
This view lists the effective, authorized local users for each computer.
LocalUser_Name The name of the local user ZoneLocalUsers.ZoneLocalUser_Name
ZoneComputer_Id The ID of the zone computer ZoneComputers.ZoneComputer_Id
The state of the local user profile, indicated by a number: Enabled Disabled
LocalUserProfileState
Removed from /etc/passwd
LocalUser_ProfileState_Desc The text description of LocalUserProfileState
EffectiveAuthorizedUserPrivileges_Computer View
This view lists the users who are authorized to log in and the computers that they can log in to. This EffectiveAuthorizedUserPrivileges_Computer view is the
same as EffectiveLoginUserPrivilege_Computer View .
EffectiveAuthorizedUsers_Computer View
This view lists the users who can log in and the computers that they can log in to.
ZoneComputer_Id The computer profile’s object GUID. ZoneComputer.ZoneComputer_ID
EffectiveAuthorizedUsers_Computer_Classic View
This view lists the users who can log in and the classic zone computers that they can log in to.
EffectiveAuthorizedUsers_Computer_Hierarchical View
This view lists the users who can log in the hierarchical zone computers that they can log in to.
EffectiveAuthorizedZoneLocalUsers View
This view lists the effective user profiles for local users who can log in and the computers that they can log in to.
EffectiveZone_Id The auto generated ID of the Zone Zones.Zone_Id
EffectiveZone_DomainId The domain ID of the Zone
ZoneLocalUsers.
ZoneLocalUser_Id The auto generated ID of the local user profile
ZoneLocalUser_Id
ZoneLocalUser_Name The name of the local user profile
ZoneLocalUser_HomeDirectory The home directory of the local user profile
ZoneLocalUser_PrimaryGroupId The primary group ID of the local user profile
ZoneLocalUser_PrimaryGroupName The primary group name of the local user profile
ZoneLocalUser_Shell The shell of the local user profile
ZoneLocalUser_Uid The UID of the local user profile
ZoneLocalUser_GECOS The GECOS of the local user profile
The profile state of the local user profile 1 means Enabled, 2 means Disabled,
ZoneLocalUser_ProfileState
3 means Removed from /etc/passwd
The display value for ZoneLocalUser_ProfileState

ZoneLocalUser_ProfileState_Desc
(Enabled/Disabled/Removed from /etc/passwd)
ZoneLocalUser_AssignmentLocation_Type The type code of the location where the zoned local user is assigned
The display text of the type of the location where the zoned local user is
ZoneLocalUser_AssignmentLocation_Type_Desc
assigned
ZoneLocalUser_AssignmentLocation_GUID The GUID of the location object where the zoned local user is assigned
ZoneLocalUser_AssignmentLocation_Name The name of the location object where the zoned local user is assigned
ZoneComputers.
ZoneComputer_Id The object GUID of the computer profile
ZoneComputer_Id
ADComputer_ObjectName The object name of the ad computer
ADComputer_DnsHostName The DNS host name of the ad computer
ADComputer_CnName The CN name of the ad computer
ADComputer_Os The operating system of the Active Directory computer
ADComputer_DomainId The domain ID of the Active Directory computer
EffectiveAuthorizedZoneUsers View
This view lists the authorized Active Directory user’s effective user profiles for each computer.
EffectiveZone_Id The auto-generated ID of the Zone Zones.Zone_Id
EffectiveZone_DomainId The domain ID of the Zone
ZoneUser_Id The auto generated ID of the user profile ZoneUsers. ZoneUser_Id
ZoneUser_Name The name of the user profile
ZoneUser_HomeDirectory The home directory of the user profile
ZoneUser_PrimaryGroupId The primary group ID of the user profile
ZoneUser_PrimaryGroupName The primary group name of the user profile
ZoneUser_Shell The shell of the user profile
ZoneUser_Uid The UID of the user profile
ZoneUser_GECOS The GECOS of the user profile
ZoneUser_IsSecondaryProfile Whether the user profile is a secondary profile or not: 1 – Yes 0 – No
ZoneUser_IsSecondaryProfile_Desc The display value for ZoneUser_IsSecondaryProfile (Yes/No)
ZoneUser_AssignmentLocation_Type The type code of the location where the zoned user is assigned
The display text of the type of the location where the zoned user is
ZoneUser_AssignmentLocation_Type_Desc
assigned
ZoneUser_AssignmentLocation_GUID The GUID of the location object where the zoned user is assigned
ZoneUser_AssignmentLocation_Name The name of the location object where the zoned user is assigned
ADUser_DomainId The domain ID of the Active Directory user
ADUser_GUID The GUID of the ad user
ADUser_ObjectName The object name of the Active Directory user
ZoneComputers.
ZoneComputer_Id The object GUID ID of the computer profile
ZoneComputer_Id
ADComputer_ObjectName The object name of the Active Directory computer
ADComputer_CnName The CN name of the Active Directory computer
ADComputer_Os The operating system of the Active Directory computer
ADComputer_DomainId The domain ID of the Active Directory computer
EffectiveDelegationTasks View
This view lists which Active Directory user has which delegation tasks.
Target The target in which the Server Suite task is delegated
Target_DomainId The domain ID of the target Domains.Id
Target_GUID The GUID of the target
Zone_Id The zone ID Zones.Zone_Id
Scope The scope in which the Server Suite task is delegated
Scope_Id The scope ID: 1 - Zone; 2 - UNIX Computer; 3 - WINDOWS Computer; 4 - Computer Role
Trustee_GUID The GUID of trustee
Trustee_DomainId The domain ID of the trustee Domains.Id
Task_Id Task Id DelegationTaskType.Task_Id
Task_Name Task name
EffectiveGroupPrivileges_Computer View
This view lists the consolidated role assignments, logon privileges, system rights privileges for each group and computer. This view only lists the role
assignments that are assigned to Active Directory groups, and lists the trustee Active Directory groups and nested groups.
The canonical name of the Active Directory Computer in where the privileges
ADComputer_CanonicalName
effective
The CN name of the Active Directory Computer in where the privileges

ADComputer_CnName
effective
The DNS host name of the Active Directory Computer in where the privileges
ADComputer_DnsHostName
effective
The object name of the Active Directory Computer in where the privileges
effective
ADGroup_CanonicalName The canonical name of the effective assigned Active Directory group
ADGroup_GUID The GUID of the effective assigned Active Directory group ADGroups.GUID
ADGroup_Name The name of the effective assigned Active Directory group
The object name of the effective assigned Active Directory group. The format
ADGroup_ObjectName
is <samAccountName>@<domain name>
ADGroup_SamAccountName The samAccountName of the effective assigned Active Directory group
Assigned_Location The name of the assignment location
Assigned_LocationType The type of the assignment location 1 – Zone, 2 – Computer, 3 – Computer Role
The description fo the type of the assignment location (Zone, Computer,

Assigned_LocationTypeDesc
Computer Role)
The platform ID of the Active Directory Computer in where the privileges

Computer_Platform
effective 1 – Windows, 2 – UNIX
The platform description name of the Active Directory Computer in where the
Computer_Platform_Desc
privileges effective (Windows/UNIX)
EffectiveZone_Id The ID of the effective zone for the privilege assignment Zones.Zone_Id
EffectiveZone_Name The name of the effective zone for the privilege assignment
Right_FullName The full name of the right
Right_Platform The platform ID of the right 0 – Windows, 1 – UNIX, 2 – Windows/UNIX
Right_Platform_Desc The platform description of the right (Windows, UNIX, Windows/UNIX)
Role_FullName The full name of the role <role name>/<zone name>
Trustee_Id The GUID of the Trustee ADGroups.ADGroup_GUID
Trustee_Name The name of the trustee
Trustee_Type The type ID of the trustee type TrusteeTypes.TrusteeType_Id
Trustee_Type_Desc The type description of the trustee type
ZoneComputer_Id The ID of the Zone Computer in where the privileges effective ZoneComputer.ZoneComputer_Id
EffectiveLocalUserPrivilegesSummary View
This view lists effective privileges rights granted to local UNIX users for both hierarchical and classic zones.
The state of the local user profile, indicated by number: Enabled Disabled
LocalUser_ProfileState_Desc The text description of LocalUser_ProfileState.
ZoneComputer_Id The object GUID ID of the computer profile ZoneComputers. ZoneComputer_Id
EffectiveLocalUsersRoleAssignment View
This view lists the effective role assignments for local users for each computer.
Assigned_Location The name of the assigned location
Assigned_LocationTypeDesc The assigned location: zone, computer, or computer role
The state of the local user profile, indicated by number: Enabled Disabled
LocalUser_ProfileState_Desc The text description of LocalUser_ProfileState.
Role_GUID The GUID for the role. Roles.Role_Id
RoleAssignment_EndTime The end date and time for the role assignment.
RoleAssignment_StartTime The start date and time for the role assignment.
The type of trustee, indicated by number: Active Directory user Active Directory
group Local UNIX user Local UNIX group Local Windows user Local Windows
Trustee_Type
group All Active Directory users All local UNIX users All local Windows users
local UNIX UID
Trustee_Type_Desc The text description of the Trustee_Type
ZoneComputer_Id The ID of the zone computer. ZoneComputers.ZoneComputer_Id
EffectiveLoginUserPrivilege_Computer View
This view lists the users who can log in and the computers that they can log in to. .
The canonical name of the AD Computer in where the privileges

effective
The Cn name of the AD Computer in where the privileges

ADComputer_CnName
effective
The dns host name of the AD Computer in where the privileges

effective
The object name of the AD Computer in where the privileges

effective
The canonical name of the assigned Active Directory user. It will

ADUser_CanonicalName
be null when trustee type = 7
The full name of the assigned Active Directory user. It will be null
ADUser_FullName
when trustee type = 7
The GUID of the assigned Active Directory user. It will be null

ADUser_GUID ADUsers.ADUser_GUID
The name of the assigned Active Directory user. It will be null

ADUser_Name
The display name for the Active Directory user, formatted as

ADUser_ObjectName
<user samAccountName>@<domain name>.
The samAccount name of the assigned Active Directory user. It

ADUser_SamAccountName
will be null when trustee type = 7
The upn name of the assigned Active Directory user. It will be null
ADUser_Upn
The type of the assignment location 1 – Zone, 2 – Computer, 3 –

Assigned_LocationType
Computer Role
The description fo the type of the assignment location (Zone,

Computer, Computer Role)
If this right could support a user to logon to a system 1 – Yes, 0 –

Right_Grants_Logon
No
The platform ID of the right 0 – Windows, 1 – UNIX, 2 –

Right_Platform
Windows/UNIX
The platform description of the right (Windows, UNIX,

Right_Platform_Desc
Windows/UNIX)
Trustee_Type = 1: ADUsers.ADUser_GUID
Trustee_ID The ID of the Trustee
Trustee_Type = 2: ADGroups.ADGroup_GUID
EffectiveRoleAssignment View
This view lists all effective role assignments for each user and for each computer.
ADUser_GUID The object GUID of the AD user which the user profile referring to. ADUsers.ADUser_GUID
Assigned_Location The source assignment location

Computer Role
Assigned_LocationType_Desc The display value of the source assignment location
Role_GUID The object GUID ID of the role Roles.Role_Id
Trustee_Id The trustee ID of the role assignment
Trustee_Type The trustee type ID of the role assignment TrusteeTypes.TrusteType_Id
ZoneComputer_Id The object GUID ID of the computer profile ZoneComputer.ZoneComputer_Id
EffectiveRoleAssignment_Classic View
This view lists all effective role assignments in classic zones for each user and for each computer.

Computer Role
EffectiveRoleAssignment_Hierarchical View
This view lists all effective role assignments in hierarchical zones for each user and for each computer.

Computer Role
EffectiveRolePrivileges_Computer View
This view lists the consolidated role assignments, logon privileges, system rights privileges for each computer. This view does not expand the trustee to
individual Active Directory users.
The canonical name of the AD Computer in where the privileges

effective
The Cn name of the AD Computer in where the privileges

ADComputer_CnName
effective
The dns host name of the AD Computer in where the privileges

effective
The object name of the AD Computer in where the privileges

effective
The type of the assignment location 1 – Zone, 2 – Computer, 3 –

Computer Role
The description fo the type of the assignment location (Zone,

Computer, Computer Role)
The platform ID of the AD Computer in where the privileges

Computer_Platform
effective 1 – Windows, 2 – UNIX
The platform description name of the AD Computer in where the

privileges effective (Windows/UNIX)
Right_Description The description of the right.
If this right could support a user to logon to a system 1 – Yes, 0 –

Right_Grants_Logon
No
The platform ID of the right 0 – Windows, 1 – UNIX, 2 –

Right_Platform
Windows/UNIX
The platform description of the right (Windows, UNIX,

Right_Platform_Desc
Windows/UNIX)
Trustee_Type = 1: ADUsers.ADUser_GUID
Trustee_GUID The GUID of the Trustee
EffectiveSysRights View
This view lists the effective system rights in hierarchical zones for each user and for each computer.
The role’s audit level (It will be null for classic zone’s role) 0 – audit not required, 1 –
-Audit-Level
audit if possible, 2 – audit required
The display value of Role_AuditLevel (It will be null for classic zone’s role) (Audit not
AuditLevel_Desc
Required/Audit if Possible/Audit required)
Always-Permit-Logon (It will be null for classic zone’s role) 1 – always permit, 0 – not always permit
The display value of -Always-Permit-Logon (It will be null for classic zone’s role)
AlwaysPermitLogon_Desc
(Always permit/Not always permit)
AllowPasswordLogon Allow Password Logon 0 – No, 1 – Yes, Null – N/A
AllowPasswordLogon_Desc The display value of AllowPasswordLogon (No, Yes, N/A)
AllowPsRemoteAccess Allow PowerShell remote access 0 - No, 1- Yes, Null - N/A
AllowPsRemoteAccess_Desc The display value of AllowPsRemoteAccess (No, Yes, N/A)
AllowNonPasswordLogon Allow Non Password Logon 0 – No, 1 – Yes, Null – N/A
AllowNonPasswordLogon_Desc The display value of AllowNonPasswordLogon (No, Yes, N/A)
AllowConsoleLogon Allow Console Logon 0 – No, 1 – Yes, Null – N/A
AllowConsoleLogon_Desc The display value of AllowConsoleLogon (No, Yes, N/A)
AllowRemoteLogon Allow Remote Logon 0 – No, 1 – Yes, Null – N/A
AllowRemoteLogon_Desc The display value of AllowRemoteLogon (No, Yes, N/A)
HasVisibleRight Has Visible Right 0 – No, 1 – Yes, Null – N/A
HasVisibleRight_Desc The display value of HasVisibleRight (No, Yes, N/A)
IgnoreDisabled If this user has ‘ignore disabled’ right on this computer 0 – No, 1 – Yes, Null – N/A
IgnoreDisabled_Desc The display value of IgnoreDisabled (No, Yes, N/A)
EffectiveUserPrivileges_Computer View
The EffectiveUserPrivileges_Computer view lists consolidated role assignments, logon privileges, and system rights’ privileges for each user and computer.
ADComputer_CanonicalName The canonical name of the computer
ADComputer_DnsHostName The DNS host name of the computer
The object name of the computer, in the format of <computer CN>.

<computer domain>.
The canonical name of the assigned Active Directory user. It will be null
The full name of the assigned Active Directory user. It will be null when
ADUser_FullName
trustee type = 7
The GUID of the assigned Active Directory user. It will be null when
trustee type = 7
The name of the assigned Active Directory user. It will be null when
ADUser_Name
trustee type = 7
The display name for the Active Directory user, formatted as <user
ADUser_ObjectName
The samAccount name of the assigned Active Directory user. It will be

null when trustee type = 7
The upn name of the assigned Active Directory user. It will be null when
ADUser_Upn
trustee type = 7
The name of the source assignment location. It might be the zone

Assigned_Location name, computer dns host name or Computer Role name, depends on
the location type

Computer Role
The display value of the source assignment location Zone Computer

Computer Role
If this user has ‘console logon’ right on this computer 0 – No, 1 – Yes,
Effective_AllowConsoleLogon
Null – N/A
Effective_AllowLogon If this user can logon this computer
If this user has ‘non password logon’ right on this computer 0 – No, 1 –
Effective_AllowNonPasswordLogon
Yes, Null – N/A
If this user has ‘non restricted Shell’ right on this computer 0 – No, 1 –
Effective_AllowNonRestrictedShell
Yes, Null – N/A
If this user has ‘password logon’ right on this computer 0 – No, 1 – Yes,
Effective_AllowPasswordLogon
Null – N/A
If this user has the 'PowerShell Remote Access' right on this computer
Effective_AllowPsRemoteAccess
0 - No; 1 - Yes; Null - N/A
If this user has ‘remote logon’ right on this computer 0 – No, 1 – Yes,
Effective_AllowRemoteLogon
Null – N/A
The human readable text of the effective audit level for this user on
Effective_AuditLevel this computer 0 – Audit not required, 1 –Audit if possible, 2 – Audit
required
If this user has ‘Cloud authorization required’ right on this computer 0 –

Effective_CloudAuthorizationRequired
No, 1 – Yes, Null – N/A
If this role grants ‘rescue’ right to this user on this computer 0 – No, 1 –
Effective_HasRescueRight
Yes
Effective_HasVisibleRight Specifies if the user is visible on this computer
If this user has ‘ignore disabled’ right on this computer 0 – No, 1 – Yes,
Effective_IgnoreDisabled
Null – N/A
Zones.Zone_Id
EffectiveZone_Id The ID of the effective zone for the privilege assignment
Zones_Hierarchical.Zone_Id
If this role grants the effective Audit level 0 – Audit not required, 1 –
Audit if possible, 2 – Audit required Given the Effective AuditLevel is 0 If
Grants_AuditLevel
this roles’s AuditLevel equals to the Effective Audit Level, then this
column is 1 – Yes, Otherwise, 0 -- No
If this role grants ‘Cloud authorization required’ right to this user on this
Grants_CloudAuthorizationRequired
computer 0 – No, 1 – Yes, Null – N/A
If this role grants ‘console logon’ right to this user on this computer 0 –
Grants_ConsoleLogon
Specifies if the role grants the visible right to this user on this
Grants_HasVisibleRight
computer.
If this role grants ‘ignore disabled’ right to this user on this computer 0
Grants_IgnoreDisabled
– No, 1 – Yes, Null – N/A
Grants_Logon If this role grants logon
If this role grants ‘non password logon’ right to this user on this
Grants_NonPasswordLogon
If this role grants ‘non restricted Shell’ right to this user on this
Grants_NonRestrictedShell
If this role grants ‘password logon’ right to this user on this computer 0
Grants_PasswordLogon
– No, 1 – Yes, Null – N/A
If this role grants the 'PowerShell Remote Access' right to this user on
Grants_PsRemoteAcccess
this computer 0 - No; 1 - Yes; Null - N/A
If this role grants ‘remote logon’ right to this user on this computer 0 –
Grants_RemoteLogon
Grants_RescueRight If this user has ‘rescue’ right on this computer 0 – No, 1 – Yes
The full name of the right. Format in <Right name> / <Right’s zone
Right_FullName
name>
Right_Platform Whether the right applies to windows, unix or both.
Right_Type The ID of the right type RightType.RightTypeId
Right_Type_Desc The display value of the right type (see RightTypes view)
Trustee_Type = 1:
Trustee_Id The GUID of the trustee ADUsers.ADUser_GUID Trustee_Type =
2: ADGroups.ADGroup_GUID
The type of the trustee 1 – Active Directory users 2 – Active Directory

Trustee_Type
groups 7 – All Active Directory users
The display value of the trustee Active Directory users Active Directory
Trustee_Type_Desc
groups All Active Directory users
ZoneComputer_Id The zone computer ID ZoneComputer.ZoneComputer_Id
EffectiveUserPrivileges_ComputerRole_UNIX View
The EffectiveUserPrivileges_ComputerRole_UNIX view lists effective computer role level role assignments for each user. This view assumes that all
computers within the computer role are UNIX computers. The assigned Active Directory users must have at least one completed profile in the zone where the
computer role is defined. Assignee “All Active Directory users” will be expanded to Active Directory users.
ADUser_FullName
trustee type = 7
The GUID of the assigned Active Directory user. It will be null when trustee
type = 7
The name of the assigned Active Directory user. It will be null when trustee
ADUser_Name
type = 7
The general display value for the Active Directory use in the default report.
ADUser_ObjectName
The format is <Active Directory samAccountName>@<domain name>.
The samAccount name of the assigned Active Directory user. It will be null
ADUser_Upn
trustee type = 7
The name of the source assignment location. For this view, it will be always
Assigned_Location
the Computer Role name
Assigned_LocationType The type of the source assignment location 3 – Computer Role
Assigned_LocationTypeDesc The display value of the source assignment location Computer Role
EffectiveZone_Id The ID of the effective zone for the privilege assignment Zones.Zone_Id Zones_Hierarchical.Zone_Id
Right_Type_Desc Whether this right is for Unix, Windows or both
If Trustee_Type = 1: ADUsers.ADUser_GUID If
Trustee_Id The GUID of the trustee

Trustee_Type TrusteeTypes.TrusteeType_Id
Trustee_Type_Desc
Note: Assigned_LocationType and Assigned_LocationTypeDesc might be removed in subsequent release.
EffectiveUserPrivileges_ComputerRole_Windows View
The EffectiveUserPrivileges_ComputerRole_Windows view lists effective computer role level role assignments for each user. This view assumes that all
computers within the computer role are Windows computers. Assignee “All Active Directory users” are NOT expanded to Active Directory users.
ADUser_FullName
trustee type = 7
The GUID of the assigned Active Directory user. It will be null when trustee
type = 7
The name of the assigned Active Directory user. It will be null when trustee
ADUser_Name
type = 7
The general display value for the Active Directory use in the default report.
ADUser_ObjectName
The format is <Active Directory samAccountName>@<domain name>.
The samAccount name of the assigned Active Directory user. It will be null
ADUser_Upn
trustee type = 7
The name of the source assignment location. For this view, it will be always
Assigned_Location
the Computer Role name
Assigned_LocationType The type of the source assignment location 3 – Computer Role
Assigned_LocationTypeDesc The display value of the source assignment location Computer Role
EffectiveZone_Id The ID of the effective zone for the privilege assignment Zones.Zone_Id Zones_Hierarchical.Zone_Id
Right_Type_Desc Whether this right is for Unix, Windows or both
If Trustee_Type = 1: ADUsers.ADUser_GUID If

Trustee_Type_Desc
EffectiveUserPrivileges_Zone_UNIX View
The EffectiveUserPrivileges_Zone view lists effective zone level role assignments for each user. This view assumes that all computers in the zone are UNIX
computers. The assigned Active Directory users must have at least one completed profile in the zone. Assignee “All Active Directory users” is expanded to
Active Directory users.
ADUser_FullName
trustee type = 7
The GUID of the assigned Active Directory user. It will be null when
trustee type = 7
ADUser_Name
trustee type = 7
The display value for the Active Directory in the default report. The
ADUser_ObjectName
format is <Active Directory samAccountName>@<domain name>.

ADUser_Upn
trustee type = 7
The name of the the source assignment location. For this view, it will be
Assigned_Location
always the same as the EffectiveZone_Name
Assigned_LocationType The type of the source assignment location 1 – Zone
Assigned_LocationTypeDesc The display value of the source assignment location Zone
Right_FullName
name>
Right_Platform Whether this right is for Unix, Windows or both
Right_Type_Desc The display value of the right type
if Trustee_Type = 1: ADUsers.ADUser_GUID If

The display value of the trustee: Active Directory users Active Directory
Trustee_Type_Desc
Note: Assigned_LocationType and Assigned_LocationTypeDesc may be removed in a subsequent release.
EffectiveUserPrivileges_Zone_Windows View
This view lists the effective role assignments for each user, assuming that all computers within the zone are Windows computers. Assignee “All Active
Directory users” is NOT expanded to Active Directory users.
ADUser_FullName
trustee type = 7
The GUID of the assigned Active Directory user. It will be null when the
trustee type = 7
ADUser_Name
trustee type = 7
The display value for the Active Directory in the default report. The
ADUser_ObjectName
format is <Active Directory samAccountName>@<domain name>.

The UPN name of the assigned Active Directory user. It will be null when
ADUser_Upn
trustee type = 7
The name of the the source assignment location. For this view, it will be
Assigned_Location
always the same as the EffectiveZone_Name
Assigned_LocationType The type of the source assignment location 1 – Zone
Assigned_LocationTypeDesc The display value of the source assignment location Zone
Right_FullName
name>
Right_Platform Whether this right is for Unix, Windows or both
Right_Type_Desc The display value of the right type
if Trustee_Type = 1: ADUsers.ADUser_GUID If

The display value of the trustee: Active Directory users Active Directory
Trustee_Type_Desc
EffectiveZoneGroups View
The EffectiveZoneGroups view lists effective group profiles for each computer and zone.
The object GUID of the Active Directory group which the group profile
ZoneGroup_ADGroupGUID ADGroups.GUID
referring to.
ZoneGroup_AssignmentLocation_GUID The object GUID of the assignment location
ZoneGroup_AssignmentLocation_Name The name of the assignment location
ZoneGroup_AssignmentLocation_Type The type code of the assignment location type 1 – Zone, 2 – Computer
ZoneGroup_AssignmentLocation_TypeDesc (zone/Computer)
ZoneGroup_Gid The GID of the group profile
ZoneGroup_Id The auto generated ID of the group profile ZoneGroups.ZoneGroup_Id
ZoneGroup_Name The UNIX name of the group
ZoneGroup_ZoneComputerId The ID of the computer where the group profile is effective ZoneComputers.ZoneComputer_Id
ZoneGroup_ZoneId The ID of the zone where the group profile is defined Zones.Zone_Id
EffectiveZoneLocalGroupMembers View
This view lists the effective local group members for each computer and zone.
ZoneLocalGroup_ZoneId The ID of the zone where the local group profile under Zones.Zone_Id
The ID of the computer profile where the local group profile

ZoneLocalGroup_ZoneComputerId ZoneComputers.ZoneComputer_Id
effective in
ZoneLocalGroup_Name The UNIX name of the local group
ZoneLocalGroup_MemberName The name of the local group’s member
The type code of the assignment location type 1 – Zone, 2 –

ZoneLocalGroup_AssignmentLocation_Type
Computer
ZoneLocalGroup_AssignmentLocation_TypeDesc (zone/Computer)
ZoneLocalGroup_AssignmentLocation_GUID The object GUID of the assignment location
ZoneLocalGroup_AssignmentLocation_Name The name of the assignment location
EffectiveZoneLocalGroups View
This view lists the effective local group profiles for each computer and zone.
ZoneLocalGroup_Id The auto generated ID of the local group profile ZoneLocalGroups.ZoneLocalGroup_Id
ZoneLocalGroup_ZoneId The ID of the zone where the local group profile under Zones.Zone_Id
The ID of the computer profile where the local group profile

effective in
ZoneLocalGroup_Name The UNIX name of the group
ZoneLocalGroup_Gid The GID of the local group profile
The profile state of the local group profile 1 = Enabled, 3 =

ZoneLocalGroup_ProfileState
Removed from /etc/group
The display value for ZoneLocalGroup_ProfileState

ZoneLocalGroup_ProfileState_Desc
(Enabled/Removed from /etc/group)
ZoneLocalGroup_IsCompleteProfile To indicate if this profile was a complete profile 1 – Yes, 0 - No
The description to the ZoneLocalGroup_IsCompleteProfile

ZoneLocalGroup_IsCompleteProfile_Desc
(Yes/No)

Computer
ZoneLocalGroup_AssignmentLocation_TypeDesc (zone/Computer)
EffectiveZoneLocalUsers View
This view lists the effective local user profiles for each computer and zone.
ZoneLocalUser_Id The auto generated ID of the local user profile ZoneLocalUsers.ZoneLocalUser_Id
ZoneLocalUser_ZoneId The ID of the zone where the local user profile under Zones.Zone_Id
ZoneLocalUser_ComputerProfileId The name of the zone where the local user profile under ZoneComputers.ZoneComputer_Id
ZoneLocalUser_HomeDirectory The local user profile’s home directory
ZoneLocalUser_Name The local user profile’s unix name
ZoneLocalUser_PrimaryGroupId The local user profile’s primary group id
ZoneLocalUser_PrimaryGroupName The local user profile’s primary group name
ZoneLocalUser_GECOS The local user profile’s GECOS
ZoneLocalUser_Shell The local user profile’s shell
ZoneLocalUser_Uid The local user profile’s UID
The profile state of the local user 1= Enabled, 2 = Disabled, 3 =


(Enabled/Disabled/Removed from /etc/passwd)
ZoneLocalUser_IsCompleteProfile To indicate if this profile was a complete profile 1 – Yes, 0 - No
The description to the ZoneLocalUser_ IsCompleteProfile

ZoneLocalUser_IsCompleteProfile_Desc
(Yes/No)
ZoneLocalUser_AssignmentLocation_Type The type code of the location where the zoned user is assigned
The display text of the type of the location where the zoned local
ZoneLocalUser_AssignmentLocation_TypeDesc
user is assigned
The GUID of the location object where the zoned local user is
ZoneLocalUser_AssignmentLocation_GUID
assigned
The name of the location object where the zoned local user is
ZoneLocalUser_AssignmentLocation_Name
assigned
EffectiveZoneLocalWinGroupMembers View
This view lists the effective local Windows group members for each computer and zone.
ZoneLocalGroup_ZoneId The ID for the zone that contains the local Windows group profile Zones.Zone_Id
The ID of the computer profile where the local Windows group

profile is effective
ZoneLocalGroup_Name The name of the local Windows group
ZoneLocalGroup_MemberName The name of the local Windows group's member

Computer
The display value for

ZoneLocalGroup_AssignmentLocation_TypeDesc
ZoneLocalGroup_AssignmentLocation_Type (zone/Computer)
EffectiveZoneLocalWinGroups Views
This view lists the effective local Windows group profiles for each computer and zone.
ZoneLocalGroup_Id The auto-generated ID of the local Windows group profile ZoneLocalGroups.ZoneLocalGroup_Id
The ID of the zone that contains the local Windows group

ZoneLocalGroup_ZoneId Zones.Zone_Id
profile
The ID of the computer profile where the local Windows group

ZoneLocalGroup_Name The name of the local Windows group
ZoneLocalGroup_Description The description of the local Windows group
The profile state of the local Windows group profile 1 = Enabled,

ZoneLocalGroup_ProfileState
3 = Removed
The display value for ZoneLocalGroup_ProfileState

ZoneLocalGroup_ProfileState_Desc
(Enabled/Removed)

Computer

ZoneLocalGroup_AssignmentLocation_TypeDesc
ZoneLocalGroup_AssignmentLocation_Type(zone/Computer)
EffectiveZoneLocalWinUsers View
This view lists the effective local Windows user profiles for each computer and zone.
ZoneLocalUser_Id The auto-generated ID of the local windows user profile ZoneLocalUsers.ZoneLocalGroup_Id
ZoneLocalUser_ZoneId The ID of the zone that contains the local Windows user profile Zones.Zone_Id
The ID of the computer profile where the local Windows user

ZoneLocalUser_ComputerProfileId ZoneComputers.ZoneComputer_Id
ZoneLocalUser_Name The name of the local Windows user
ZoneLocalUser_FullName The full name of the local Windows user
ZoneLocalUser_PasswordOption The password option of the local Windows user
ZoneLocalUser_Description The description of the local Windows user
The profile state of the local Windows user profile 1 = Enabled, 2

= Disabled, 3 = Removed

(Enabled/Disabled/Removed)

ZoneLocalUser_AssignmentLocation_Type
Computer

ZoneLocalUser_AssignmentLocation_TypeDesc
ZoneLocalUser_AssignmentLocation_Type (zone/Computer)
ZoneLocalUser_AssignmentLocation_GUID The object GUID of the assignment location
ZoneLocalUser_AssignmentLocation_Name The name of the assignment location
EffectiveZoneUsers View
The EffectiveZoneUsers view lists effective user profiles for each computer and zone,
The object GUID of the Active Directory user which the user profile
ZoneUser_ADUserGUID ADUsers.ADUser_GUID
referring to.
ZoneUser_AssignmentLocation_GUID The GUID of the location object where the zoned user is assigned
ZoneUser_AssignmentLocation_Name The name of the location object where the zoned user is assigned
ZoneUser_AssignmentLocation_Type The type code of the location where the zoned user is assigned
The display text of the type of the location where the zoned user is
ZoneUser_AssignmentLocation_TypeDesc
assigned
ZoneUser_ComputerProfileId The name of the zone computer where the user profile is effective ZoneComputers.ZoneComputer_Id
ZoneUser_GECOS The user profile’s GECOS
ZoneUser_HomeDirectory The user profile’s home directory
ZoneUser_Id The auto generated ID of the user profile ZoneUsers.ZoneUser_Id
ZoneUser_IsCompleteProfile To indicate if this profile was a complete profile 1 – Yes, 0 - No
ZoneUser_IsCompleteProfile_Desc The description string for ZoneUser_ IsCompleteProfile (Yes/No)
To indicate if this profile was enabled. Only available to classic zone’s

ZoneUser_IsEnabled
profile. For hierarchical zone profile, it will always be null 1 – Yes, 0 - No
ZoneUser_IsEnabled_Desc The description string for ZoneUser_ IsEnabled (Yes/No)
ZoneUser_IsOrphan 1 – It is an orphan user profile. 0 – It is not an orphan profile 1 – Yes, 0 - No
ZoneUser_IsOrphan_Desc The description to the ZoneUser_ IsOrphan (Yes/No)
ZoneUser_IsSecondaryProfile To indicate if this profile was a secondary profile 1 – Yes, 0 - No
ZoneUser_IsSecondaryProfile_Desc The description string for ZoneUser_IsSecondaryProfile (Yes/No)
ZoneUser_Name The user profile’s unix name
ZoneUser_PrimaryGroupId The user profile’s primary group id
ZoneUser_PrimaryGroupName The user profile’s primary group name
ZoneUser_Shell The user profile’s shell
ZoneUser_Uid The user profile’s uid
ZoneUser_ZoneId The ID of the zone where the user profile under Zones.Zone_Id
Rights View
The Rights view lists all rights and system rights defined for each zone.
Grants_Logon Specifies whether the right allows a user to log on to a computer.
Right_-
The description of the right
Description
Right_-Full-Name The full name of the right. The format of the full name is: Right_-Name/Right_ZoneName
Right_-GUID The object GUID of the right
The ID of the right type 1 – Network Access right 2 – Desktop right 3 – Application right 4 – PAM Access right 5 –
SSH right 6 – Command right 7 – Restricted Environment 101 – Allow password logon 102 – Allow non password
Right_-Type logon 103 – Ignore disabled 104 – Allow non restricted shell 105 – Allow console logon 106 – Allow remote logon RightType.RightTypeId
107 – Always permit logon 108 – Audit level – Not required 109 – Audit level – If possible 110 – Audit level –
Required 111 – Cloud Authorization Required
The display value of the right type: Network Access right Desktop right Application right PAM Access right SSH
right Command right Restricted Environment Allow password logon Allow non password logon Ignore disabled
Right_Type_Desc
Allow non restricted shell Allow console logon Allow remote logon Always permit logon Audit level – Not
required Audit level – If possible Audit level – Required Cloud Authorization Required
Right_ZoneId The zone ID of the right. It will be null for system rights Zones.Zone_Id
Right_-
The zone name of the right. It will be null for system rights
ZoneName
Rights columns used in other views
EffectiveUserPrivileges_Computer.Right_GUID EffectiveUserPrivileges_ComputerRole.Right_GUID
Rights.Right_GUID
EffectiveUserPrivileges_Zone.Right_GUID
RightType View
The RightType view provides the type of rights that are defined in the zone and what operating system platform the type applies to.
Grants_Logon Specifies if the right can support a user to log on to a system. 0 – No 1 – Yes
RightPlatformId The platform ID of the right type 0 – Unix 1 – Windows 2 – Unix/Windows
RightTypeDesc The display value of the right type
RightTypeId The ID of the right type
RightType columns used in other views
EffectiveUserPrivileges_Computer.Right_Type EffectiveUserPrivileges_ComputerRole.Right_Type
RightType.RightTypeId
EffectiveUserPrivileges_Zone.Right_Type Rights.Right_Type ZoneRolePrivileges.ZoneRolePrivileges_RightType
RoleAssignmentCustomAttribute View
This view lists the role assignment’s custom attributes.
Role_Id The role’s object GUID. Roles.Role_Id
RoleAssignments View
This view lists the role assignments, based on zones, computer roles, or computers.
RoleAssignment_GUID The object GUID of the role assignment
RoleAssignment_ZoneId The ID of the zone where the role assignment belongs to Zones.Zone_Id
RoleAssignment_ZoneName The name of the zone where the role assignment belongs to
RoleAssignment_ZoneDomainId The ID of the domain where the role assignment belongs to Domains.Id
Assigned_Location The name of the location where the role assignment is created
The type of the location where the role assignment was created 1 - Zone , 2 - Computer, 3 -
Computer Role
The type description of the location where the role assignment was created 1 - Zone , 2 -
Assigned_LocationType_Desc
Computer, 3 - Computer Role
RoleAssignment_TrusteeName The name of the trustee
The type of the trustee 1 - AD user 2 - AD group 3 - Local UNIX user 4 - Local UNIX group 5 - Local
RoleAssignment_TrusteeType
Windows user 6 - Local Windows group 7 - All AD users 8 - All UNIX user 9 - All Windows users
RoleAssignment_TrusteeType_Desc The type description of the trustee
RoleAssignment_RoleGUID The object GUID of the assigned role Roles.Role_Id
RoleAssignment_RoleName The name of the assigned role
RoleAssignment_RoleFullName The full name of the assigned role
RoleAssignment_Description The description of the role assignment
RoleAssignments_Computer View
This view lists the role assignments defined for computers.
RoleAssignment_ZoneComputerId The ID of the zone computer where the role assignment is defined ZoneComputers.ZoneComputer_Id
The name of the zone computer where the role assignment is

RoleAssignment_ADComputer_ObjectName
defined
The Active Directory computer's CN name of the zone computer

RoleAssignment_ADComputer_CnName
where the role assignment is defined
The Active Directory computer's canonical name of the zone

RoleAssignment_ADComputer_CanonicalName
computer where the role assignment is defined
The Active Directory computer's Dns host name name of the zone
RoleAssignment_ADComputer_DnsHostName
computer where the role assignment is defined
The platform of the zone computer where the role assignment is

Computer_Platform .
defined 1 - Windows 2 - UNIX
The platform description of the zone computer where the role

assignment is defined 1 - Windows 2 - UNIX
RoleAssignment_ZoneId The ID of the zone where the role assignment belongs Zones.Zone_Id
RoleAssignment_ZoneName The name of the zone where the role assignment belongs
RoleAssignment_ZoneDomainId The ID of the domain where the role assignment belongs Domains.Id
The type of the trustee 1 - AD user 2 - AD group 3 - Local UNIX user

RoleAssignment_TrusteeType 4 - Local UNIX group 5 - Local Windows user 6 - Local Windows
group 7 - All AD users 8 - All UNIX user 9 - All Windows users
RoleAssignment_TrusteeType_Desc The type description of the trustee .
RoleAssignment_Description The role assignment description
RoleAssignments_ComputerRole View
The RoleAssignments_Computer Role view lists the role assignments for each computer role.
RoleAssignment_ComputerRoleDescription The description of the Compute Role
RoleAssignment_ComputerRoleGUID The GUID of the Computer Role
RoleAssignment_ComputerRoleName The name of the Computer Role
RoleAssignment_RoleFullName The effective end time of the role assignment
RoleAssignment_RoleGUID The GUID of the assigned role Roles.Role_Id
RoleAssignment_RoleName The object GUID of the role that is being assigned
RoleAssignment_TrusteeName The trustee name of the role assignment
The trustee type code of the role assignment 1 – Active Directory user 2 – Active Directory
RoleAssignment_TrusteeType group 3 – Local UNIX user 4 – Local UNIX group 5 – Local Windows user 6 – Local Windows
group 7 – All Active Directory users 8 – All UNIX user 9 – All Windows users
The display value of the trustee type: Active Directory user Active Directory group Local
RoleAssignment_TrusteeType_Desc UNIX user Local UNIX group Local Windows user Local Windows group All Active Directory
users All UNIX user All Windows users
RoleAssignment_ZoneDomainId The zone’s domain ID of the role assignment Domains.Id
RoleAssignment_ZoneId The zone ID of the role assignment Zones.Zone_Id
RoleAssignments_Zone View
This view lists the role assignments defined in zones.
RoleAssignment_ZoneId The ID of the zone where the role assignment belongs Zones.Zone_Id
RoleAssignment_ZoneName The name of the zone where the role assignment belongs
RoleAssignment_ZoneDomainId The id of the domain where the role assignment belongs Domains.Id
The type of the trustee 1 - AD user 2 - AD group 3 - Local UNIX user 4 - Local UNIX group 5 - Local
RoleAssignment_TrusteeType
Windows user 6 - Local Windows group 7 - All AD users 8 - All UNIX user 9 - All Windows users
RoleAssignment_TrusteeType_Desc The type description of the trustee
RoleCustomAttribute View
This view lists the computer role’s custom attributes.
RoleAssignment_GUID The role assignment’s object GUID. RoleAssignments.RoleAssignment_GUID
RoleRights View
This view lists the rights for each role.
Role_-Name The name of the role
Role_-Full-Name The full name of the role. The format of the full name is: <Role_Name>/<Role_ZoneName>
Right_GUID The object GUID of the right Rights.Right_Id
Right_-Name The zone name of the right. It will be null for system rights.
Right_-Full-Name The full name of the right. The format of the full name is: Right_-Name/Right_ZoneName
Right_ZoneId The zone ID of the right. This column is null for system rights. Zones.Zone_Id
The ID of the right type 1 – Network Access right 2 – Desktop right 3 – Application right 4 – PAM Access
right 5 – SSH right 6 – Command right 7 – Restricted Environment 101 – Allow password logon 102 – Allow
Right_-Type non password logon 103 – Ignore disabled 104 – Allow non restricted shell 105 – Allow console logon 106 – RightType.RightTypeId
Allow remote logon 107 – Always permit logon 108 – Audit level – Not required 109 – Audit level – If possible
110 – Audit level – Required 111 – Cloud Authorization Required
The display value of the right type: Network Access right Desktop right Application right PAM Access right
SSH right Command right Restricted Environment Allow password logon Allow non password logon Ignore
Right_Type_Desc
disabled Allow non restricted shell Allow console logon Allow remote logon Always permit logon Audit level
– Not required Audit level – If possible Audit level – Required Cloud Authorization Required
Right_-Description The description of the right
Right_Platform The platform ID of the right 0 – Windows, 1 – UNIX, 2 – Windows/UNIX
Right_Platform_Desc The platform description of the right (Windows, UNIX, Windows/UNIX)
Roles View
The Roles view lists all roles for each zone. This view is a combined view of the Roles_Classic and Roles_Hierarchical views.
Role_-Always-Permit-Logon (It will be null for classic zone’s role) 1 – always permit, 0 – not always permit
The display value of _-Always-Permit-Logon (It will be null for classic zone’s role) (Always permit/Not
Role_AlwaysPermitLogon_Desc
always permit)
The role’s audit level (It will be null for classic zone’s role) 0 – audit not required, 1 – audit if possible, 2 –
Role_-Audit-Level
audit required
The display value of Role_AuditLevel (It will be null for classic zone’s role) (Audit not Required/Audit if
Role_AuditLevel_Desc
Possible/Audit required)
Role_-Description The description of the role
Role_-Id The object GUID of the role
Role_-Zone-Id The ID of the zone where the role is defined Zones.Zone_Id
Role_ZoneName The name of the zone where the role is defined
Roles Columns Used in Other Views
Roles.Right_GUID ZoneRolePrivileges.ZoneRolePrivileges_RightGUID
EffectiveUserPrivileges_Computer.Role_GUID EffectiveUserPrivileges_ComputerRole.Role_GUID
Roles.Role_Id EffectiveUserPrivileges_Zone.Role_GUID RoleAssignments_ComputerRole.RoleAssignment_RoleGUID
ZoneRolePrivileges.ZoneRolePrivileges_RoleGUID
Roles_Classic View
The Roles_Classic view lists all roles for each classic zone.
Role_-Always-Permit-Logon (It will be null for classic zone’s role) It is NULL in this view as Audit Level is not applicable in classic zone
The display value of Role_-Always-Permit-Logon (It will be null for classic zone’s role) It is NULL in this
Role_AlwaysPermitLogon_Desc
view as Audit Level is not applicable in classic zone
The role’s audit level (It will be null for classic zone’s role) It is NULL in this view as Audit Level is not
Role_-Audit-Level
applicable in classic zone
The display value of Role_AuditLevel (It will be null for classic zone’s role) It is NULL in this view as Audit
Role_AuditLevel_Desc
Level is not applicable in classic zone
Role_-Id The object GUID of the role
Roles_Hierarchical View
The Roles_Hierarchical view lists all roles for each hierarchical zone.
Role_-Always-Permit-Logon 1 – always permit, 0 – not always permit
Role_AlwaysPermitLogon_Desc The display value of Role_-Always-Permit-Logon (Always permit/Not always permit)
Role_-Audit-Level The role’s audit level 0 – audit not required, 1 – audit if possible, 2 – audit required
Role_AuditLevel_Desc The display value of Role_AuditLevel (Audit not Required/Audit if Possible/Audit required)
Role_-ID The object ID of the role
TrusteeTypes View
This view lists the role assignment trustee types.
TrusteeType_Id The type ID of the trustee
TrusteeType_Desc The type description of the trustee
Zone_Classic View
The Zones_Classic view lists all Classic zones.
Zone_AvailableShells Zone’s Available shells
Zone_CanonicalName The canonical name of the Zone
Zone_DefaultGroup Zone’s default group
Zone_DefaultHomeDirectory Zone’s default home directory
Zone_DefaultPrimaryGroupId The default primary group
Zone_DefaultPrimaryGroupName The name of the default primary group
Zone_DefaultShell Zone’s default shell
Zone_DomainId The name of the domain which the Active Directory user belongs to Domains.Id
Zone_DomainName The ID of the domain which the Active Directory user belongs to
Zone_Id The auto generated ID of the Zone
Zone_IsHierarchical If the zone was a Hierarchical zone or not 1 – Is Hierarchical Zone, 0 – Classic Zone
Zone_IsHierarchical_Desc The display value for Zone_IsHierarchical (Yes/No)
Zone_IsSFU If the zone was a SFU zone or not 1 – SFU Zone, 0 – Non SFU Zone
Zone_IsSFU_Desc (Yes/No)
Zone_Name The name of the Zone
Zone_NextGID Zone’s next gid
Zone_NextUID Zone’s next uid
Zone_NISDomain Zone’s NIS domain
Zone_ReservedGID Zone’s reserved gid
Zone_ReservedUID Zone’s reserved uid
Zone_SFUDomain Zone’s SFU domain
Zone_Hierarchical View
The Zones_Hierarchical view lists all Hierarchical zones.
Zone_IsHierarchical_Desc The display value for Zone_IsHierarchical 1 – Yes, 0 - No
Zone_IsSFU_Desc 1 – Yes, 0 - No
Zone_TrustedCloudInstanceUrl Trusted cloud instance URL
Zones_Hierarchical Columns Used in Other Views
EffectiveUserPrivileges_Computer.EffectiveZone_Id EffectiveUserPrivileges_Computer.ZoneUser_Id
Zones_Hierarchical.Zone_Id
EffectiveUserPrivileges_ComputerRole.EffectiveZone_Id
ZoneComputers View
The ZoneComputers view lists computer profiles for each zone.
ZoneComputer_ADComputerCnName The Active Directory computer’s common name.
ZoneComputer_ADComputerDnsHostName The Active Directory computer’s DNS hostname
The domain ID of the Active Directory computer which is managed by

ZoneComputer_ADComputerDomainId
the zone
The object GUID of the Active Directory computer which is managed by

ZoneComputer_ADComputerId ADComputers.ADComputer_GUID
the zone
The name of the Active Directory computer which is managed by the

ZoneComputer_ADComputerName
zone
The object name of the computer, in the format of <computer CN>.

ZoneComputer_ADComputerObjectName
<computer domain>.
ZoneComputer_AgentVersion The agent version of the managed computer
ZoneComputer_ComputerType The type of the managed computer 1 – Windows, 2 – Unix
The display value of the ZoneComputer_ComputerType

ZoneComputer_ComputerType_Desc
(Windows/Unix)
ZoneComputer_Id The object GUID of the computer profile
1 – It is managed by a hierarchical zone, 0 – It is managed by a classic

ZoneComputer_IsHierarchical
zone
ZoneComputer_IsHierarchical_Desc The display value of the ZoneComputer_IsHierarchical (Yes/No)
ZoneComputer_IsOrphan 1 – It is an orphan profile, 0 – It is not an orphan profile
ZoneComputer_IsOrphan_Desc The display value of the ZoneComputer_IsOrphan (Yes/No)
If the computer joined zone 1 – Joined zone, 0 – Only has machine

ZoneComputer_IsZoned
overrides
ZoneComputer_JoinDate The date when the managed computer joined zone (UTC time)
Specifies the type of computer license. 1 - Server, 2-Workstation, 3-

ZoneComputer_LicenseType
UNIX, 4-Express
ZoneComputer_LicenseType_Desc The description of the license type.
ZoneComputer_Name The name of the managed computer
ZoneComputer_PreferredSite The preferred site of the computer.
ZoneComputer_PreferredSubnetSite The preferred subnet site of the computer.
ZoneComputer_ZoneDomainId The domain ID of the zone by which the computer is managed
ZoneComputer_ZoneId The ID of the zone by which the computer managed Zones.Zone_Id
ZoneComputer_ZoneName The name of the zone by which the computer managed
ZoneComputer Columns Used in Other Views
EffectiveUserPrivileges_Computer.ZoneComputer_Id EffectiveZoneGroups.ZoneGroup_ZoneComputerId
ZoneComputer.ZoneComputer_Id
EffectiveZoneUsers.ZoneUser_ComputerProfileId
ZoneGroups View
The ZoneGroups view lists group profiles for each zone.
ZoneGroup_-ADGroup-
The object GUID of the Active Directory group which the group profile referring to. ADGroups.GUID
GUID
ZoneGroup_ADGroupName The name of the Active Directory group which the user profile referring to.
ZoneGroup_-Gid The group profile’s gid
ZoneGroup_-Id The auto generated ID of the group profile
If the zone group referencing to a valid Active Directory group 1 – It is an orphan user profile. 0 – It is not an
ZoneGroup_IsOrphan
orphan profile
ZoneGroup_IsOrphan_Desc The display value for ZoneGroup_IsOrphan 1 – Yes, 0 – No
ZoneGroup_-Name The group profile’s name
ZoneGroup_-Zone-Id The ID of the zone where the group profile is defined Zones.Zone_Id
ZoneGroup_ZoneName The name of the zone where the group profile is defined
ZoneGroup Columns Used in Other Views
EffectiveUserPrivileges_Computer.ZoneComputer_Id EffectiveZoneGroups.ZoneGroup_ZoneComputerId
ZoneGroups.ZoneGroup_Id
EffectiveZoneUsers.ZoneUser_ComputerProfileId
ZoneHierarchy View
ParentZone_Id The ID of the parent zone. Zones.Zone_Id
ParentZone_Name The name of the parent zone.
ParentZone_DomainID The domain ID of the parent zone. Domains.Id
ChildZone_Id The ID of the child zone. Zones.Zone_Id
ChildZone_Name The name of the child zone.
ChildZone_DomainId The domain ID of the child zone. Domains.Id
ZoneLocalGroupMembers View
This view lists the local group members for each zone.
ZoneLocalGroup_-Id The auto generated ID of the local group profile
ZoneLocalGroup_-Zone-Id The ID of the zone where the local group profile is Zones.Zone_Id
ZoneLocalGroup_ZoneName The name of the zone where the local group profile is
ZoneLocalGroup_-Name The local group profile’s name
ZoneLocalGroup_MemberName The name of the local group’s member
ZoneLocalGroups View
This view lists the local group profiles for each zone.
ZoneLocalGroup_-Id The auto generated ID of the local group profile
ZoneLocalGroup_-Zone-Id The ID of the zone where the local group profile is Zones.Zone_Id
ZoneLocalGroup_ZoneName The name of the zone where the local group profile is
ZoneLocalGroup_-Gid The local group profile’s GID
ZoneLocalGroup_-Name The local group profile’s name
ZoneLocalGroup_ProfileState The profile state of the local group profile 1 = Enabled, 3 = Removed from /etc/group
ZoneLocalGroup_ProfileState_Desc The display value for ZoneLocalGroup_ProfileState (Enabled/Removed from /etc/group)
ZoneLocalUsers View
This view lists the local user profiles for each zone.
ZoneLocalUser_Id The auto generated ID of the local user profile
ZoneLocalUser_ZoneId The ID of the zone where the local user profile is Zones.Zone_Id
ZoneLocalUser_ZoneName The name of the zone where the local user profile is
ZoneLocalUser_Name The local user profile’s UNIX name
ZoneLocalUser_HomeDirectory The local user profile’s home directory
ZoneLocalUser_PrimaryGroupID The local user profile’s primary group ID
ZoneLocalUser_PrimaryGroupName The local user profile’s primary group name
If the zone user was defined in a hierarchical zone or not 1 – It is defined in a hierarchical zone. 0 –
ZoneLocalUser_IsHierarchical
Is is defined in a classic zone
ZoneLocalUser_IsHierarchical_Desc The display value for ZoneLocalUser_IsHierarchical (Yes/No)
ZoneLocalUser_Shell The shell of the zone user
ZoneLocalUser_GECOS The GECOS of the zone user
ZoneLocalUser_Uid The zone user’s uid
The profile state of the local user 1 means Enabled, 2 means Disabled, 3 means Removed from
ZoneLocalUser_ProfileFlag
/etc/passwd
The display value for ZoneLocalUser_ProfileState (Enabled/Disabled/Removed from

ZoneLocalUser_ProfileFlag_Desc
/etc/passwd)
ZoneLocalWinGroupMembers View
This view lists the local Windows group members for each zone.
ZoneLocalGroup_Id The auto-generated ID of the local Windows group profile
ZoneLocalGroup_ZoneId The ID of the zone that contains the local Windows group profile Zones.Zone_Id
ZoneLocalGroup_ZoneName The name of the zone that contains the local Windows group profile
ZoneLocalGroup_Name The local Windows group profile’s name
ZoneLocalGroup_MemberName The name of the local Windows group’s member
ZoneLocalWinGroups View
This view lists the local Windows group profiles for each zone.
ZoneLocalGroup_Id The auto-generated ID of the local Windows group profile
ZoneLocalGroup_ZoneId The ID of the zone that contains the local Windows group profile Zones.Zone_Id
ZoneLocalGroup_ZoneName The name of the zone that contains the local Windows group profile
ZoneLocalGroup_Name The local Windows group profile’s name
ZoneLocalGroup_ProfileState The profile state of the local Windows group profile 1 = Enabled, 3 = Removed
ZoneLocalGroup_ProfileState_Desc The display value for ZoneLocalGroup_ ProfileState (Enabled/Removed)
ZoneLocalWinUsers View
This view lists the local Windows user profiles for each zone.
ZoneLocalUser_Id The auto generated ID of the local Windows user profile
ZoneLocalUser_ZoneId The ID of the zone where the local Windows user profile is Zones.Zone_Id
ZoneLocalUser_ZoneName The name of the zone where the local Windows user profile is
ZoneLocalUser_Name The local Windows user profile’s name
If the zone user was defined in a hierarchical zone or not 1 – It is defined in a hierarchical zone. 0 – It
ZoneLocalUser_IsHierarchical
is defined in a classic zone
ZoneLocalUser_IsHierarchical_Desc The display value for ZoneLocalUser_IsHierarchical (Yes/No)
ZoneLocalUser_FullName The full name of the local Windows user
ZoneLocalUser_Description The description of the local Windows user
ZoneLocalGroup_ProfileFlag The profile state of the local Windows user profile 1 = Enabled, 2 = Disabled, 3 = Removed
ZoneLocalGroup_ProfileFlag_Desc The display value for ZoneLocalUser_ ProfileState (Enabled/Disabled/Removed)
ZoneRolePrivileges View
The ZoneRolePrivileges view lists the roles that are defined for each zone and the rights that are granted by each of these roles.
ZoneRolePrivileges_RightFullName The full name of the right
ZoneRolePrivileges_RightGUID The GUID of the right Roles.Right_GUID
ZoneRolePrivileges_RightName The name of the right
ZoneRolePrivileges_RightPlatform Whether the right is for Unix, Windows or both
ZoneRolePrivileges_RightPlatform_Desc The display value of the right platform
ZoneRolePrivileges_RightType The type ID of the right RightType.RightTypeId
ZoneRolePrivileges_RightType_Desc The display value of the right’s type
ZoneRolePrivileges_RightZoneDomainId The domain ID of the zone of the right Domains.Id
ZoneRolePrivileges_RightZoneId The zone ID of the right Zones.Zone_Id
ZoneRolePrivileges_RightZoneIsHierarchical If the zone of the right is hierarchical 1 – Yes, 0 – No
The display value of the ZoneRolePrivileges_RightZoneIsHierarchical

ZoneRolePrivileges_RightZoneIsHierarchical_Desc
(Yes/No)
ZoneRolePrivileges_RightZoneName The zone name of the right
ZoneRolePrivileges_RoleFullName The full name of the role
ZoneRolePrivileges_RoleGUID The GUID of the role Roles.Role_Id
ZoneRolePrivileges_RoleName The name of the role
ZoneRolePrivileges_RoleZoneDomainId The domain ID of the zone of the domain
ZoneRolePrivileges_RoleZoneId The zone ID of the role Zones.Zone_Id
ZoneRolePrivileges_RoleZoneIsHierarchical If the zone of the role is hierarchical 1 – Yes, 0 – No
The display value of the ZoneRolePrivileges_RoleZoneIsHierarchical

ZoneRolePrivileges_RoleZoneIsHierarchical_Desc
(Yes/No)
ZoneRolePrivileges_RoleZoneName The zone name of the role
Zones View
The Zones view lists all the zones in the domain. This view is a combination of both Zones_Classic and Zones_Hierarchical.
The ID of the default GID type 1—Use the auto-incremented GID 2—Use the generated GID from the SID 3—
Zone_DefaultGIDType
Use the Apple GID scheme
The description of the default GID type (Use auto-incremented GID, Generated GID from SID, or Use Apple
Zone_DefaultGIDType_Desc
GID scheme)
The ID of the default UID type (applies to hierarchical zones only) 1—Use auto-incremented UID 2—
Zone_DefaultUIDType
Generated UID from SID 3—Use Apple UID scheme
The description of the default type. For hierarchical zones, this is one of the following: Use auto-
Zone_DefaultUIDType_Desc incremented UID, Generated UID from SID, or Use Apple UID scheme. For classic zones: Use auto-
incremented UID.
Zone_DefaultUserName The description of the zone scheme ID, such as Standard, RFC 2307, or SFU.
Zone_IsHierarchical_Desc If the zone was a Hierarchical zone or not (Yes/No)
Zone_IsSFU_Desc If the zone was a SFU zone or not (Yes/No)
Zone_Schema The ID of the zone scheme: 1—Standard 2—RFC 2307 3—SFU
Zone_Type The zone type (hierarchical or classic)
Zone_TrustedCloudInstanceUrl Trusted cloud instance URL
Zone view columns used in other views
Column
name
Roles_Classic.Role_ZoneId ComputerRoleMembership.ComputerRole_ZoneId ComputerRoleMembership.ZoneComputer_ZoneId

EffectiveUserPrivileges_Computer.EffectiveZone_Id EffectiveUserPrivileges_ComputerRole.EffectiveZone_Id
Column
name
EffectiveUserPrivileges_Zone.EffectiveZone_Id EffectiveZoneGroups.ZoneGroup_ZoneId EffectiveZoneUsers.ZoneUSer_ZoneId

Zone.Zone_Id
Rights.Right_Id RoleAssignments_ComputerRole.RoleAssignment_ZoneId Roles.Role_ZoneId Roles_Hierarchical.Role_ZoneId
ZoneComputers.ZoneComputer_ZoneId ZoneGroups.ZoneGroup_ZoneId ZoneRolePrivileges.ZoneRolePrivileges_RoleZoneId
ZoneRolePrivileges.ZoneRolePrivileges_RightZoneId ZoneUsers.ZoneUser_ZoneId
ZoneUsers View
The ZoneUsers view lists the user profiles for each zones.
ZoneUser_ADUserGUID The object GUID of the Active Directory user which the user profile referring to. ADUsers.ADUser_GUID
ZoneUser_ADUserName The name of the Active Directory user which the user profile referring to.
ZoneUser_GECOS The GECOS of the zone user
ZoneUser_HomeDirectory The user profile’s home directory
ZoneUser_Id The auto generated ID of the user profile
If the zone user was defined in a hierarchical zone or not 1 – It is defined in a hierarchical zone. 0
ZoneUser_IsHierarchical
– Is is defined in a classic zone
ZoneUser_IsHierarchical_Desc The display value for ZoneUser_IsHierarchical (Yes/No)
If the zone user referencing to a valid Active Directory user 1 – It is an orphan user profile. 0 – It is
ZoneUser_IsOrphan
not an orphan profile
ZoneUser_IsOrphan_Desc The display value for ZoneUser_IsOrphan (Yes/No)
If the zone user was defined in a SFU zone or not 1 – It is defined in a SFU zone. 0 – Is is not
ZoneUser_IsSFU
defined in a SFU zone
ZoneUser_IsSFU_Desc The display value for ZoneUser_IsSFU (Yes/No)
ZoneUser_Name The user profile’s unix name
ZoneUser_PrimaryGroupID The user profile’s primary group id
ZoneUser_PrimaryGroupName The user profile’s primary group name
ZoneUser_Shell The shell of the zone user
ZoneUser_Uid The zone user’s uid
If the zone user is enabled (For classic zone user only, it will be null for Hierarchical zone user) 1
ZoneUser_UserEnabled
– enabled, 0 – disabled, NULL – not applicable
ZoneUser_UserEnabled_Desc (Yes/No)
ZoneUser_ZoneId The ID of the zone where the user profile under Zones.Zone_Id
ZoneUser_ZoneName The name of the zone where the user profile under
ZoneUser Columns Used in Other Views
EffectiveUserPrivileges_Computer.ZoneUser_Id EffectiveUserPrivileges_ComputerRole.ZoneUser_Id
ZoneUsers.ZoneUser_Id
EffectiveUserPrivileges_Zone.ZoneUser_Id EffectiveZoneUsers.ZoneUser_Id
Configuring Report Services for Large Active Directory Environments
Configuration issues can significantly affect the performance of synchronizing Active Directory information and report queries and generation. This section
describes additional considerations for deploying Delinea Report Services successfully in a large Active Directory environment.
Memory Recommendations and Requirements for Large Active Directory Environments
Domain Controller Memory
Symptoms
The domain controller runs slower or stops responding.
You can use the Performance monitor tool to evaluate if the system is operating within adequate capacity thresholds.
For details, see: http://social.technet.microsoft.com/wiki/contents/articles/14355.capacity-planning-for-active-directory-domain-

services.aspx#Monitoring_For_Compliance_With_Capacity_Planning_Goals
Resolution
Ensure the system has a sufficient amount of RAM. The minimum amount of RAM should be the sum of:
Active Directory database size (such as the size of the C:\Windows\NTDS\ folder)
Total SYSVOL size (such as the size of the C:\Windows\SYSVOL folder)
Operating system recommended amount of RAM
Vendor recommendations for the agents (antivirus, monitoring, backup, and so on)
Additional amount of RAM to accommodate growth over the lifetime of the server.
For details, see: http://social.technet.microsoft.com/wiki/contents/articles/14355.capacity-planning-for-active-directory-domain-services.aspx
Windows Memory Requirements
Here are the memory requirements for different versions of Windows:
Windows version Minimum memory required
Windows 2008, 2008 R2 512 MB minimum 2 GB or more is recommended
Windows 2012, 2012 R2 512 MB minimum
Windows 7, 8, 8.1, 10 2 GB minimum for 64-bit systems
References
http://windows.microsoft.com/en-us/windows7/products/system-requirements
http://windows.microsoft.com/en-US/windows-8/system-requirements
http://www.microsoft.com/en-us/windows/windows-10-specifications
https://technet.microsoft.com/en-us/windowsserver/bb414778.aspx
https://technet.microsoft.com/en-us/library/dn303418.aspx
Sql Server Memory
Symptoms
Delinea Report Services fails to rebuild or refresh a snapshot because of insufficient system memory or an out of memory error.
You cannot open reports in SSRS because of insufficient system memory or an out of memory error.
Resolution
Ensure that your SQL Server deployment has sufficient memory. Different versions of SQL Server have different memory requirements. For details, please
see:
In addition to Microsoft’s recommended memory requirement for SQL Server, an additional amount of memory is required for SQL Server in order to
rebuild/refresh snapshot data and render the report successfully.
For more information, see Configuration Recommendations for Large Active Directory Environments.
Configuration Recommendations for Large Active Directory Environments
The major factor of evaluating the configuration requirements for SQL Server is the total number of effective users who can access the computers that are
joined to zone in the Active Directory environment. You can estimate the total number of effective users by multiplying the number of computers joined to the
zone by the average number of users who can access the computer.
Below lists the recommended configurations for SQL Server for some sample Active Directory environments.
Active Directory environment Sample #1:
Number of computers joined to a zone 1000
Average number of users who can access the computer 500
Total number of effective users 500 * 1000= 500,000
90% of user profiles and role assignments are explicitly defined at the zone level
Active Directory environment Sample #1 configuration recommendations :
SQL Server edition SQL Server Express Edition with Advanced Services
SQL Server memory 8 GB
SQL Server disk space 30 GB
Active Directory environment Sample #2:
Number of computers joined to a zone 5,000
Average number of users who can access the computer 3,000
Total number of effective users 3,000 * 5,000 = 15,000,000
90% of user profiles and role assignments are explicitly defined at the zone level
Active Directory environment Sample #2 configuration recommendations :
SQL Server edition SQL Server Standard Edition or above
SQL Server memory 64 GB
SQL Server disk space 80 GB
Setting the Maximum Server Memory for SQL Server
To prevent Microsoft SQL Server from consuming too much memory, you can use the following formula to determine the recommended maximum server
memory:
Reserve 4GB from the first 16GB of RAM and then 1GB from each additional 8GB of RAM for the operating system and other applications.
Configure the remaining memory as the maximum server memory allocated for the Microsoft SQL Server buffer pool.
For example, if the computer hosting the Microsoft SQL Server instance has 32GB of total physical memory, you would reserve 4GB (from first 16 GB) + 1GB
(from next 8 GB) + 1 GB (from next 8 GB) for the operating system, then set the Maximum server memory for Microsoft SQL Server to 26GB (32GB – 4GB – 1GB
– 1GB = 26).
Reference:
https://msdn.microsoft.com/en-us/library/ms178067(v=sql.105).aspx
To set the maximum server memory for SQL Server:
1. Open the SQL Server Management Studio, enter the SQL Server properties:
2. Set the maximum server memory (in MB).
Using Report Filters to Limit the Output Data of a Report
Symptoms
In large Active Directory environments, the following reports can take too long to render because they generate a huge volume of output:
Authorization Report
Classic Zone – User Privileged Command Rights Report
Classic Zone – User Role Assignment Report
Hierarchical Zone - Computer Role Effective Assignments Report (UNIX)
Hierarchical Zone - Computer Role Effective Assignments Report (Windows)
Hierarchical Zone - Effective Audit Level Report
Hierarchical Zone - Effective Rights Report
Hierarchical Zone - Effective Role Report
Hierarchical Zone - Users Report
Hierarchical Zone - Zone Effective Assignments Report (UNIX)
Hierarchical Zone - Zone Effective Assignments Report (Windows)
All PCI reports
All SOX reports
Resolution
You can use report filters to limit the report to only list data for specific zone types and zones in a specific domain. This can reduce the amount of data output
from the report and the report will take less time to render.
If you are opening the PCI and SOX reports, you can use the Zone Type filter to limit the reports to only list data for Classic zones or Hierarchical zones.
For all reports, you can use the Zone Domain filter to limit the reports to only list data for zones in a specific domain. By default, the Zone Domain filter of all
the reports is set to the first zone domain.
By default, reports are set to run automatically when you open the report. If you prefer to set the reports to not run automatically upon opening, do the
following. You must have manage report permission in order to configure the report.
To configure a report to not run automatically when you open the report:
1. In the list of reports in the web browser, locate the desired report.
2. Move your mouse pointer over the report to open the report context menu.
3. From the context menu, select Manage.
4. Select the Parameters page.
Notice that ‘Has Default’ is selected for all parameters.
5. Deselect the ‘Has Default’ setting for any one parameter.
6. Click Apply to save the changes.
7. Open the report.
The report does not run automatically. You can specify the filter values and click “View Report” button to run the report.
Increasing the Time-Out Value for Rebuild/Refresh Data Operations
Delinea Report Services invokes multiple database operations when it refreshes and rebuilds its cache of information stored in Active Directory. These
database operations can be time-consuming in a large Active Directory environment. If any such database operation cannot be completed within a certain
time period, the Delinea Report Services control panel will show that the Refresh/Rebuild process failed.
Symptom
When Delinea Report Services perform a snapshot rebuilding or refreshing and the amount of the monitored data is too large to be processed within the time-
out period, this error will occur:
A database operation error occurred. Please contact your administrator to make sure the remote database is accessible and working properly. --->
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Resolution
You can change the time-out value (3,600 seconds by default) for that time period by performing the following steps:
1. Open the registry editor and then locate the key ‘SQLCmdTimeout’ under HKLM\Software\Centrify\Report Services\Service. If you cannot find it under
the path, create one with the same name and as 'DWORD' type.
2. Set to 'SQLCmdTimeout' to a large enough value (unit in second) so that the rebuild/refresh/computing can be finished within the time period.
Note: Set the SQLCmdTimeout to 0 (ZERO) mean no time-out. Customer should contact Delinea Technical Support first before changing
SQLCmdTimeout to 0.
Increasing the Time-Out Values for Microsoft SQL Server Reporting Services
Consider increasing the following SSRS configuration parameter values so that the large reports can be opened successfully.
Report Execution Time-out
A report execution time-out value is the maximum number of seconds that report processing can continue before it is stopped. This value is defined at the
system level. You can vary this setting for individual reports.
Symptoms
For example, you can run a report that has underlying queries that cannot be completed within the time-out period. The following error will be shown on the
Report Manager like this:
An error has occurred during report processing. (rsProcessingAborted)

Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)
A severe error occurred on the current command. The results, if any, should be discarded. Operation cancelled by user.
Resolution
Increase the Report execution time-out value. For details, see https://msdn.microsoft.com/en-us/library/ms155782.aspx.
HTTP Runtime Execution Timeout
Symptoms
You cannot open the report and you get the following error instead. This error generally occurs when the HTTP runtime execution timeout is too short.
The remote server returned an error: (500) Internal Server Error.
Resolution
1. Open the Report Server’s Web.config file, which is usually in this location:
<Drive>:\Program Files\Microsoft SQL Server\MSRS<version number>.<instance name>\Reporting Services\ReportServer
2. Locate the HttpRuntime parameter and alter the value. If it doesn't exist, you will have to create it within the section.
The default value is 9000, and the value is in the seconds. The maximum value is 922337203685.
3. Increase the executionTimeout value to allow the report to be rendered.
Increasing the ReceiveTimeOut Value for Internet Explorer
Symptoms
The following error is shown when you try to open a report:
An unknown error occurred while processing the request on the server. The status code returned from the server was: 12002
Resolution
Note: The resolution for this symptom involves changing a registry setting. Before you change this registry setting, you should contact Delinea
Technical Support first.
You can change the ReceiveTimeout setting for Internet Explorer using the following steps:
1. Start the Windows Registry Editor.
2. Locate the following subkey:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
3. In this subkey, add a ReceiveTimeout DWORD entry that has a value of (<number of seconds>)*1000.
For example, if you want the time-out duration to be 120 minutes, set the value of the ReceiveTimeout entry to 7200000 (<120*60>*1000).
4. Restart the computer.
Using a URL to Export Report Data to CSV
Symptoms
The underlying queries in some reports take a long time to execute and you may get the following errors when opening reports:
The remote server returned an error: (500) Internal Server Error.
Resolution
Besides using the report filters to make the report take less time to execute as described in earlier section, you can export the report to CSV by using a URL. In
addition, you can skip exporting the chart data for the following reports:
PCI – Login Summary Report

PCI – Right Summary Report
SOX – Login Summary Report
SOX – Right Summary Report
To configure the report URL to export to CSV and skip the chart data in the exported file:
1. Compose the URL in the following format:
http://\<hostname\>:\<port\>/ReportServer_\<instancename\>?\<report path\>&rs:Command=Render&rs:Format=CSV&pZoneDomainId=-1&SkipChartData=True
For example:
This is a URL to export the PCI – Login Summary report:
http://win2012r2/ReportServer_CENTRIFYSUITE?%2fcentrify+Report+Services%2fAttestation+Reports%2fPCI+Reports%2fPCI+-
+Login+Summary+Report&rs:Command=Render&rs:Format=CSV&SkipChartData=True&pZoneDomainId=-1
This is a URL to export the PCI – Right Summary report:
http://win2012r2/ReportServer_CENTRIFYSUITE?%2fcentrify+Report+Services%2fAttestation+Reports%2fPCI+Reports%2fPCI+-
+Right+Summary+Report&rs:Command=Render&rs:Format=CSV&SkipChartData=True&pZoneDomainId=-1
2. Access the URL in Internet Explorer.
3. Save the exported CSV file.
References
https://msdn.microsoft.com/en-us//library/ms153586.aspx
Creating the Report Subscription for CSV Export
This section shows how to use the SQL Server Reporting Services (SSRS) subscription feature to export report data to CSV regularly.
Prerequisites
Please check whether your SQL Server edition supports the reporting subscription feature.
https://msdn.microsoft.com/en-us/library/cc645993(v=sql.100).aspx
SQL Server Agent is already installed and running.
Configuring The Report Data Source For Subscriptions
To configure a report subscription in SSRS for CSV export and skip the chart data in the export:
1. Open Delinea Report Services.
2. Click ReportDataSource to open the report data source properties page.
3. Configure the report data source to store connection credentials in the report server:
1. For the connection method, select Credentials stored securely in the report server.
2. Enter the login user name and password.
3. Select Use as Windows credentials when connecting to the data source.
4. The following screenshot is an example of the connection settings configuration:
4. Secure access to the reports and the report data by adding or editing role assignments for the report folder.
1. Open the Security page for the report folder ‘Access Manager Reports’ and ‘Attestation Reports’.
1. Here you can view, add, edit, or delete role assignments for the report folder.
2. The data source uses stored credentials, which means that users who are able to view the reports would be able to read the report data. To
avoid this potential risk, you can define role-based security for reports in the Security page, as shown below.
2. Delete the default role assignment that assigns the Browser role to NT AUTHORITY\Authenticated Users to remove report read access to all
authenticated users.
3. In the report folder’s Security page, click New Role Assignment.
4. Enter the users or groups who can access the reports.
5. Select one or more roles to assign to the specified user(s).
For example, if you want the specified users to only view the report, select the Browser role.
6. Click OK to save the changes.
Creating A CSV Report Subscription
1. In the list of reports, select the report that you want to export to CSV.
2. Click the context menu and click Subscribe.
3. In the Subscription page, set the options according to the following screenshot.
1. To specify when the scheduled report runs, click Select Schedule.
2. When you specify the file path, the path must conform to the Uniform Naming Convention format.
3. In the lower area of the subscription page, set the Zone domain parameter to ALL in order to export report data for all zone domains.
4. After setting the options, click O K to create this subscription.
Skipping Chart Data From CSV Report Subscriptions
You can skip exporting the chart data to CSV for the following reports:
PCI – Login Summary Report

PCI – Right Summary Report
SOX – Login Summary Report
SOX – Right Summary Report
1. Open the report subscription. (From the report’s context menu, click Manage, and then click the Subscription page.)
2. In the lower area of the subscription page, set the SkipChartData parameter to True.
3. After setting the options, click O K to save the subscription.
Troubleshooting Reports
In general, if something doesn't work the way that you think it should, try the following to troubleshoot your reporting environment:
View the log files

Rebuild or refresh the reporting data
Validate that the reporting service has the correct permissions to read data from the monitored domains and replicate the data.
Export diagnostics data for use by Delinea Technical Support (if technical support requests that you do so).
This section describes some situations that you might encounter, along with some suggested solutions or workarounds.
You Don’t See Any data When You Open a Report
Problem: You’ve installed everything and you can open a report, but you don’t see any data.
Solution: Make sure that there has been at least one synchronization between Active Directory and the reporting database. Use the Report Configuration
wizard to do this.
You Don’t See the Report Builder Link in Internet Explorer
Problem: You go the Home page in Internet Explorer, the home page for your deployed reports in SSRS, and you do not see the Report Builder link. But you’re
fairly sure that you have the required permissions to create reports.
Solution: Here are some things for you to check:
1. Make sure that you are logging in within the same domain that SSRS is installed within. For example, if you’re creating an evaluation version that uses a
different domain, there may be issues.
2. Go download the Report Builder for your SQL Server version. For now, it’s a separate download.
You Can’t Log in to Report Services in Internet Explorer
Problem: When you log in to Delinea Report Services in Internet Explorer, you cannot successfully log in. You see an error message like this: “User
domain\user does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions
have been addressed.”
Explanation: If you’re seeing this issue, it may have happened after your first installation or an upgrade in which you created a new SQL Server instance.
Solution: Here are some things for you to try:
When you go to launch Report Services, right-click it and select Run as Administrator. This may allow you to log in to Report Services, and from there you
can edit the Site Settings for security.
Log in to Report Services as an administrator, and go to Site Settings to add your users by way of adding the domain and assign the group or user a role.
For details, see Granting access in SSRS to reports.
Make sure that you also set permissions for the home folder, as mentioned in the topic mentioned above.
You Get a Server Error When You Try to Synchronize with Active Directory
Problem: In the Report Services control panel, when you go to synchronize data for report services, the following error displays: “The server is unwilling to
process the request.” (KB-6350)
You also see a similar error in the report services log file. Here’s an example of what the error looks like:
[2015-08-21 10:53:25.714 +0800] Centrify.Report.Service.exe[3596,10] Error: SyncServer.DoSynchronization: Failure during synchronize domain a9f1r1.test,
DC: a9d1-w2k12r2.a9f1r1.test.
[2015-08-21 10:53:25.714 +0800] Centrify.Report.Service.exe[3596,10] Error: SyncServer.DoSynchronization: Reason: The server is unwilling to process the
request.
Explanation: The issue is due to insufficient memory on the domain controller. The domain controller is unable to allocate enough memory for Active
Directory caching.
Solution: Adjust the memory allocated to the domain controller, according to Memory requirements.
Port Conflicts
Problem: Delinea Report Services not install correctly when port 80 is used by another application, such as Apache Tomcat. The following error displays
during the report services configuration wizard: “The service was unable to access Report Services.” (KB-7443)
Explanation: By default, Microsoft SQL Server Reporting Services (SSRS) use port 80, and it is not recommended to run it with a third party software that
also uses port 80 or 443.
Solution: For port conflict situations, you can configure SSRS to use another port.
To change the port that SQL Server Reporting Services (SSRS) uses:
1. Open the SQL Server Reporting Services Configuration Manager.

2. Navigate to the Web Service URL.
3. Change the TCP port to an unused port other than 80.
For example, port 8080.
4. Navigate to the Report Manager URL, and click Advanced.

5. Change the TCP port to the same port number that you specified in Step 3.
6. Run the Delinea Report Services Configuration Wizard and specify URLs with the new port number.
For example, http://reportservice:8080/ReportServer_CssREPORTS2
7. Verify that you can access reports through the specified port.
You may also need to modify your firewall rules for access to the specified port.
SSRS Fails to Start on Windows 2008 R2 Systems
Problem: SQL Server Reporting Services (SSRS) fails to start, due to a timeout issue. This issue occurs only on Windows 2008 R2 systems. (KB-8065)
SSRS Produces the Following Error
Windows could not start the SQL Server Reporting Services (MSSQLSERVER) service on local computer. Error 1053: The service did not respond to the start
or control request in a timely fashion.
Explanation: This happens due to SSRS checking for certificate revocation lists (CRL), and this is a Microsoft known issue, as detailed here:
http://support.microsoft.com/kb/2745448.
Note: Delinea does not take any responsibility for the content or availability of this link, it is provided as a courtesy. You should contact Microsoft if
there are any further questions.
Solution: You can perform one of the following tasks to try and resolve this issue:
Disable certificate revocation lists checking. For details, see http://tech.lanesnotes.com/2014/02/sql-server-reporting-services-service.html

Change the default revocation checking behavior using group policy. For details, see https://technet.microsoft.com/en-
us/library/ee619786(v=ws.10).aspx
SQL Server 2008 R2 Express Edition Produces an Installation Error
Problem: When you run the installer, you get an error when it tries to install the SQL Server 2008 R2 Express edition for report services. The installer
produces the following error: (KB-8172)
The Report Services Configuration Wizard Cannot be Completed Due to an Error that Occurred
The program was unable to install SQL Server on this computer, exit code: 0x851A0017. Please refer to the Delinea Knowledge Base article (KB-4589) for
more information on the error code you received. Please fix the issue and run Setup again.
You might also see something like the following errors in the SQL Server log file, which you can locate in a directory such as C:\Program Files\Microsoft SQL
Server\100\Setup Bootstrap\Log\<number>\Detail.txt.
2017-01-25 12:41:31 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC. 2017-01-25 12:41:31
Slp: Could not find the Database Engine startup handle. 2017-01-25 12:41:31 Slp: The configuration failure category of current exception is
ConfigurationFailure 2017-01-25 12:41:31 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC.
2017-01-25 12:41:31 Slp: Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineConfigException: Could not find the Database Engine startup handle. 2017-
01-25 12:41:31 Slp: at Microsoft.SqlServer.Configuration.SqlEngine.SqlServerServiceBase.WaitSqlServerStart(Process processSql) 2017-01-25 12:41:31 Slp:
at Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.ConfigSQLServerSystemDatabases(EffectiveProperties properties, Boolean
isConfiguringTemplateDBs, Boolean useInstallInputs) 2017-01-25 12:41:31 Slp: at
Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineDBStartConfig.DoCommonDBStartConfig(ConfigActionTiming timing) 2017-01-25 12:41:31 Slp: at
Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.ExecuteAction(String actionId) 2017-01-25 12:41:31 Slp: at
Microsoft.SqlServer.Configuration.SqlConfigBase.SlpConfigAction.Execute(String actionId, TextWriter errorStream) 2017-01-25 12:41:31 Slp: Exception:
Microsoft.SqlServer.Configuration.SqlEngine.SqlEngineConfigException. 2017-01-25 12:41:31 Slp: Source:
Microsoft.SqlServer.Configuration.SqlServer_ConfigExtension. 2017-01-25 12:41:31 Slp: Message: Could not find the Database Engine startup handle.
Explanation: The SQL Server Express edition isn’t able to use the encryption protocols provided by the server.
The installation error occurs because TLS1.0/1.1 and SSL 3.0 protocols and some ciphers have been disabled on the server, due to customer security
concerns. SQL Server 2008 R2 Express Edition does not support the newer version of cipher suites (such as TLS1.2 with SHA256), while the regular versions
of SQL Server with the latest updates or support packs (SP) do.
Solution: Restore the server settings back to the system defaults that allow TLS1.0/1.1, SSL 3.0 protocols and ciphers. After you do that, the installer will
successfully complete a report services installation with SQL Server Express edition.
Installing SQL Server from the Delinea Management Services Installer Generates Error Codes
Problem: When you install the SQL Server version that is bundled with the Delinea Management Services installer, there are errors. (KB-4589)
SQL Server
installation Description
error
0x84B40000 -
full text service
This means user is trying to install SQL Server on a Domain Controller with Full Text Search service configured under a local system
cannot run
account. This is not supported by Microsoft. Workaround is to either install SQL on a member server, or manually install SQL and select a
under local
different account to run it as Full Text Search service.
system
account on DC.
For this error code, more information is needed, see below on how to collect logs.
If SQL server is already installed on a machine with default SQL server instance (with advanced services), the SQL server setup will fail
0X6AA with the above error code. To workaround this issue, reinstall SQL Native Client (SNAC) before installing the second instance of SQL
Server 2005 Express Edition with Advanced Services. - http://msdn.microsoft.com/en-us/sqlserver/ff658533 (Provided as a courtesy)
This means a hyphen (-) in the SQL server's instance name has been specified and is not allowed.
SQL Server Management Studio 2005 has been installed on the system and there is an attempt to install SQL 2008 on top of it. To
workaround this issue, manually uninstall SQL Server Management Studio and then install the later version.
PowerShell 2.0, which is a prerequisite for Microsoft SQL server 2014, is not installed. Install Windows Management Framework 2.0 first
before run Report Services Configuration Wizard
SQL Server 2008 R2 express edition with advanced features will fail to install an new instance when TLS 1.0/1.1 and SSL 3.0 protocols are
disabled. It fails with a message like: SQL Server installation failed. To continue, investigate the reason for the failure, correct the
problem, uninstall SQL Server, and then rerun SQL Server Setup. To work around this issue, re-enable the protocols (Update
corresponding values to 1.) The SQL Server instance then can be installed successfully. Refer to:
https://blogs.msdn.microsoft.com/friis/2016/07/25/disabling-tls-1-0-on-your-windows-2008-r2-server-just-because-you-still-have-
one/
If the SQL Server installation fails for any other reason, send the installation log files to Delinea support. You can locate the installation log files in the
following locations:
SQL Server 2008 and 2008 R2:
%ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\LOG
SQL Server 2012:
%ProgramFiles%\Microsoft SQL Server\110\Setup Bootstrap\Log\.
SQL Server 2014:
%ProgramFiles%\MicrosoftSQL Server\120\Setup Bootstrap\Log\.
SQL Server 2016:
%ProgramFiles%\ Microsoft SQL Server\130\Setup Bootstrap\Log\
See also: https://centrify.my.salesforce.com/50180000000blYD, http://support.microsoft.com/kb/955396.
Can’t install SQL Server 2012 or 2014 instance on Windows 2008 SP2
Problem: If you use the Report Services Configuration wizard to install a new instance of SQL Server version 2012 or 2014 on Windows Server 2008 SP2, the
installation fails if Windows Powershell 2.0+ or Windows Management Framework 2.0 is not already installed. The installation failure has an exit code of
0x84BE0260 (KB-7096).
Explanation: Windows Server 2008 SP2 doesn’t include PowerShell 2.0 or Windows Management Framework 2.0 by default. Later versions of Windows
Server do include these components by default.
Solution: Install PowerShell 2.0 or higher and Windows Management Framework 2.0 before you run the Report Services Configuration Wizard to install a
new instance of Microsoft SQL Server 2012 or 2014.
You can download Windows Management Framework 2.0 from https://support.microsoft.com/en-us/kb/968930.
Report Services computation takes longer than it used to
Problem: If Report Services uses SQL Server 2014 or above, you might notice that Report Services spends more time on computation.
Explanation: In SQL Server 2014, Microsoft introduced a new cardinality estimator (CE). This cardinality estimator was redesigned to improve query
performance, and there may be some performance degradation for some SQL statements.
Solution: If you notice some report services computation performance issues, set the database compatibility level to 110 to force SQL Server to use the old
cardinality estimator.
To set the database compatibility level to 110:
1. In SQL Server Management studio, run the following before Report Services synchronizes with Active Directory:
ALTER DATABASE <the database name deployed by Report Services> SET COMPATIBILITY_LEVEL = 110
Frequently asked questions about report services
Question: Is it possible for report services to use an existing database that's already been created according to our organization's standards?
Answer: Report services cannot use an existing database, the Configuration Wizard creates a new database.
Question: Does report services create just one database?
Answer: Yes. If you reconfigure report services, the Configuration Wizard creates a new database.
Question: Does the report services installation make any other modifications to database objects other than in the database it creates?
Answer: No.
Synchronized Active Directory Attributes for Reports
This section covers which Active Directory attributes that report services synchronizes for use in reports. Report services synchronizes these attributes from
Active Directory to the reports database in a one-way synchronization process.
AD Computer
Active
Directory Computer
class
Available in
Yes
zone mode?
Available in
domain Yes
mode?
objectGUID parentGUID name sAMAccountName userAccountControl primaryGroupID dNSHostName operatingSystem

Attributes operatingSystemVersion operatingSystemServicePack description whenCreated pwdLastSet objectSid sIDHistory managedBy location
givenName postalAddress
AD Group
Active
Directory group
class
Available in
Yes
zone mode?
Available in
Yes
domain mode?
objectGUID parentGUID name description gidNumber groupType mail member msSFU30GidNumber msSFU30Name msSFU30NisDomain
Attributes
objectSid primaryGroupToken sAMAccountName sIDHistory whenCreated managedBy
AD User
| Active Directory class | user |
| Available in zone mode? | Yes | | Available in domain mode? | Yes | | Attributes | objectGUID parentGUID name sAMAccountName userPrincipalName
userAccountControl primaryGroupID msSFU30NisDomain uid uidNumber | | Attributes (continued) | gidNumber loginShell unixHomeDirectory gecos
msSFU30Name msSFUUidNumber msSFU30GidNumber msSFU30HomeDirectory msSFU30Gecos whenCreated | | Attributes (continued) |
lastLogonTimestamp accountExpires lockoutTime pwdLastSet givenName sn initials displayName description | | Attributes (continued) |
physicalDeliveryOfficeName telephoneNumber mail wWWHomePage objectSid SIDHistory streetAddress postOfficeBox l st | | Attributes (continued) |
postalCode co homePhone otherHomePhone pager otherPager mobile otherMobile facsimileTelephoneNumber otherFacsimileTelephoneNumber | |
Attributes (continued) | ipPhone otherIpPhone title department company manager profilePath scriptPath homeDirectory homeDrive msNPAllowDialin | |
Attributes (continued) | msNPCallingStationID msRADIUSServiceType msRADIUSCallbackNumber msRADIUSFramedIPAddress msRADIUSFramedRoute |
Application Right
Active Directory msDS-AzOperation
Available in zone mode? Yes
Active Directory msDS-AzOperation
Available in domain mode? Yes
Attributes objectGUID parentGUID name description msDS-AzApplicationData msDS-AzOperationID
Command Right
Active Directory class msDS-AzOperation
Computer Role
Active Directory class msDS-AzScope
Computer SCP
Active Directory class serviceConnectionPoint
Attributes objectGUID parentGUID name displayName keywords managedBy whenCreated
Computer Zone AzScope
Active Directory class msDS-AzScope
Attributes objectGUID parentGUID name displayName msDS-AzScopeName
Computer Zone Container
Active Directory class container
Active Directory class container
Attributes objectGUID parentGUID name displayName description
Container
Active Directory class all possible container classes
Attributes objectGUID parentGUID name
Desktop Right
Domain
Active Directory class domainDNS
Attributes msDS-LogonTimeSyncInterval distinguishedName lockoutDuration
Dzsh Command Right
Group SCP
Attributes objectGUID parentGUID name displayName keywords gidNumber managedBy
License Container
Active Directory class classStore
Available in zone mode? No
Attributes objectGUID parentGUID name displayName description whenCreated
Local Group SCP
Attributes objectGUID parentGUID name displayName keywords gidNumber
Local User SCP
Attributes objectGUID parentGUID name displayName keywords uid uidNumber gidNumber unixHomeDirectory loginShell gecos
Network Right
Pam Right
Attributes objectGUID parentGUID name description msDS-AzApplicationData
Privileged Command Right
Restricted Environment
Active Directory class msDS-AzTask
Attributes objectGUID parentGUID name description msDS-AzApplicationData msDS-OperationsForAzTask
Role
Active Directory class msDS-AzTask
Attributes objectGUID parentGUID name description msDS-AzApplicationData msDS-OperationsForAzTask msDS-TasksForAzTask
Role Assignment
Active Directory class msDS-AzRole
Attributes objectGUID parentGUID name displayName msDS-AzApplicationData msDS-TasksForAzRole msDS-MembersForAzRole
Ssh Right
Attributes objectGUID parentGUID name description msDS-AzApplicationData
User SCP
Active Directory
class
Available in domain
Yes
mode?
objectGUID parentGUID name displayName name keywords uid uidNumber gidNumber unixHomeDirectory loginShell gecos
Attributes
managedBy
Zone
Active Directory class container or OU
Attributes objectGUID parentGUID name description displayName
Auditing Guides
Auditing Administrator Guide
Audit Database Management Guide
Find Sessions Guide
Auditing and Monitoring Administration
Overview of the Auditing Infrastructure

Planning an Audit Installation
Installing the Audit & Monitoring Service
Managing an Installation
Querying and Reviewing Audited Activity
Advanced Monitoring
Command Line Programs for Managing Audited Sessions
Installing the Unix Agent on Remote Computers
Permissions Required to Perform Administrative and Auditing Tasks
Sizing Recommendations for Audit Installations
Overview of the Auditing Infrastructure
Auditing is a key feature of Server Suite. If you choose to enable auditing in your organization, you can capture detailed information about user activity on
Linux, UNIX, and Windows computers and store that activity to improve regulatory compliance and accountability and mitigate security risks. This section
provides an overview of the auditing infrastructure, including key components and terminology.
Deciding whether to audit user activity

Capturing detailed and summary information for user sessions
Reviewing recorded activity
Auditing requires a scalable architecture
How audited sessions are collected and stored
Auditing architecture and data flow
Deploying auditing components in an audit installation
Agent components on audited computers - UNIX and Windows
Deciding Whether to Audit User Activity
Just as it is important to protect assets and resources from unauthorized access, it is equally important to track what users who have permission to access
those resources are doing or have done in the past. For users who have privileged access to computers and applications with sensitive information, auditing
their actions helps ensure accountability and improve regulatory compliance.
There are many reasons for organizations to establish auditing policies and enable auditing of user activity. For example, you might want to audit activity for
any of the following reasons:
To prove certain computers or applications are secure in order to comply with government or industry regulatory requirements.
To report on actions taken by users with elevated privileges.
To prevent the use of shared passwords when more than one person needs administrative access to a computer or an application.
To improve accountability when users with elevated permissions have access to privileged resources.
To detect suspicious activity and mitigate the threat posed by malicious insiders or third parties who have access to sensitive systems.
To pinpoint actions that may have caused failures and simplify troubleshooting procedures.
To capture information, such as the steps that resolved an open case, that can be used to help your organization improve its helpdesk operations or
security procedures.
Capturing Detailed and Summary Information for User Sessions
After you deploy the auditing infrastructure, you can capture detailed information about user activity and the events that occurred on the computers you
choose to audit. On those computers, an agent starts recording user activity when a user selects an audited role or starts a login shell locally, using a remote
shell, or through a virtual network connection such as Citrix or VNC.
Each record of continuous user activity is called a session. A session ends when the user logs out, disconnects, or is inactive long enough to lock the desktop.
If the user reconnects or unlocks the desktop, the agent resumes recording the user’s activity as a new session. When users start a new session on an audited
computer, they can be notified that their session is being audited but they cannot turn off auditing except by logging off, so you have a complete record of
what happened, includes an audit trail of the actions a user has taken.
You can choose whether to record only summaries of user activity or a full visual record of user activity.
Sessions include different kinds of information depending on the audited system's operating system:
Windows: When auditing Windows computers, each session is a video capture of everything that takes place on the desktop, including the applications
opened, text that was entered, and the results that were displayed.
Linux: When auditing Linux computers, the agent records shell activity, such as the commands a user runs or the changes made to key files and data.
On some versions of Linux computers, actions performed using a display manager, such as GNOME or KDE, are also recorded. Consult the Delinea
release notes for supported platform details.
In addition to capturing detailed information about user activity, sessions provide a summary of actions taken so that you can scan the applications opened or
commands executed for potentially interesting or damaging actions without playing back a complete session. After you select a session of interest in the
Audit Analyzer, the console displays an indexed list of actions taken in the order in which they occurred. You can then select any entry in the list to start
viewing the session beginning with that action. For example, if a user opened an application that stores credit card information, you can scan the list of
actions for that event and begin reviewing what happened in the session from the time the user opened that particular application.
If users change their account permissions to take any action with elevated privileges, the change is recorded as an audit trail event. You can also search for
these events to find sessions of interest.
Reviewing Recorded Activity
The information recorded in each session is transferred to a Microsoft SQL Server database so that it is available for querying and playback. Because the
information is collected as it happens, you can monitor computers for suspicious activity or troubleshoot problems immediately after they occur.
You can also search for and play back sessions to locate past events that occurred on specific computers or that affected particular users. For example, you
might be interested in activity that occurred immediately before a security breach or want to investigate the cause of an application failure. Similarly, a
security expert might want to see who had access to computers with sensitive data, such as payroll information or medical records, during a particular period
of time, such as the last 72 hours.
Auditing Requires a Scalable Architecture
To ensure scalability for large organizations and provide fault tolerance, the auditing infrastructure has a multi-tier architecture that consists of the
following layers:
Audited computers are the computers on which you want to monitor activity. To be audited, the computer must have an agent installed, audit
features enabled, and be joined to an Active Directory domain.
Collectors are intermediate services that receive and compress the captured activity from the agents on audited computers as the activity occurs.
You should establish at least two collectors to ensure that auditing is not interrupted. You can add collectors to your installation at any time and it is
common to have multiple collectors to provide load balancing and redundancy.
Audit stores define a scope for auditing and include the audit store databases that receive captured activity and audit trail records from the
collectors and store it for querying and playback. Audit store databases also keep track of all the agents and collectors you deploy. For scalability and
network efficiency, you can have multiple audit stores each with multiple databases.
A management database server is a computer that hosts the Microsoft SQL Server instance with the audit management database. The
management database stores information about the overall installation, such as the scope of each audit store, which audit store database is active and
where there are attached databases, the audit roles you create, and the permissions you define. The management database enables centralized
monitoring and reporting across all audit stores, collectors, and audited computers.
The Audit Manager and Audit Analyzer consoles are the graphical user interfaces which administrators can use to configure and manage the
deployment of audit components, such as agents and collectors, or to query and review captured user sessions.
To ensure that audit data transferred over the network is secure, communication between components is authenticated and encrypted.
In addition to these core components of the auditing infrastructure, there is a separate Windows service that collects audit trail events when there are audit
store databases that are not accessible, for example, because of network issues or the database server is shut down. This audit management server runs as a
Windows service and spools the events on the management database, then sends them to the audit store database when the inaccessible database comes
back online.
In addition to spooling audit trail events, the audit management server automatically calculates the approximate disk space used by audited sessions on the
database server. The audit management server will calculate the session size for all completed audited sessions. The session size is not calculated for in-
progress or disconnected sessions. You can view the session size for all completed sessions in the Audit Analyzer console’s query results.
How Audited Sessions are Collected and Stored
The agent on each audited computer captures user activity and forwards it to a collector on a Windows computer. If the agent cannot connect to a collector—
for example, because all of the computers hosting the collector service for the agent are shut down for maintenance—the agent spools the session data
locally and transfers it to a collector later.
The collector sends the data to an audit store server, where the audit data is stored in the Microsoft SQL Server database that you have designated as the
active audit store database. As you accumulate data, you can add more SQL Server databases to the audit store to hold historical information or to
change the database designated as the active audit store database.
After the audit data is transferred to the audit store database, you can use the Audit Analyzer console to request session data. The audit management
database, which stores information about all of the components that make up the auditing infrastructure, retrieves the session data from the appropriate
Auditing Architecture and Dataflow
The following figure illustrates the basic architecture and flow of data with a minimum number of auditing components installed.
In the illustration, each agent connects to one collector. In a production environment, you can configure agents to allow connections to additional collectors
for redundancy and load balancing or to prevent connections between specific agents and collectors. You can also add audit stores and configure which
connections are allowed or restricted. The size and complexity of the auditing infrastructure depends on how you want to optimize your network topology,
how many computers you are auditing, how much audit data you want to collect and store, and how long you plan to retain audit records.
The following figure illustrates the data flow details. You can see which components communicate to other components and in what order. The diagram also
includes some port details.
The following diagram shows how the Linux Desktop auditing session data is collected.
Within the Linux Desktop, there's a component called DAX that generates the recorded session data and passes it to the audit daemon. The audit daemon
encrypts and passes the recorded session data to the collector. The collector channels session data of different types together and passes that encrypted
session data along to the active audit store database.
Deploying Auditing Components in an Audit Installation
The multi-tiered architecture of the auditing infrastructure is referred to collectively as a DirectAudit installation. The DirectAudit installation
represents a logical object similar to an Active Directory forest or site. It encompasses all of the auditing components you deploy—agents, collectors, audit
stores, management database, and consoles—regardless of how they are distributed on your network. The installation also defines the scope of audit data
available. All queries and reports are against the audit data contained within the installation boundary.
The most common deployment scenario is to have a single audit installation for an entire organization so that all audit data and management of the audit
data is centralized. Within a single installation, you can have components wherever they are needed, as long as you have the appropriate network
connections that allow them to communicate with each other. The audit data for the entire installation is available to users who have permission to query and
view it using a console. For most organizations, having a single installation is a scalable solution that allows a “separation of duties” security model through
the use of audit roles. If you establish a single installation, there will be one Master Auditor role for the entire organization, and that Master Auditor can control
the audit data that other users and groups can see or respond to by defining roles that limit access rights and privileges.
However, if you have different lines of business with different audit policies—in different geographic locations, or with different administrative groups—you
can configure them as separate audit installations. For example, if you have offices in North America and Hong Kong managed by two different IT teams—IT-
US and IT-HK—you might want to create two DirectAudit installations to maintain your existing separation of duties for the ITUS and IT-HK teams.
Planning Where to Install Auditing Components
Before you install Centrify Audit & Monitoring Service, you should develop a basic deployment plan for how you will distribute and manage the components
that make up an installation. For example, you should decide how many collectors and audit stores to create and where to put them. You should also consider
the network connections required and how many computers you plan to audit. For example, you can have multiple agents using the same set of collectors, but
you should keep the collectors within one hop of the agents they serve and within one hop of the audit stores to which they transfer data.
By planning where to install components initially, you can determine the number of collectors you should have for load balancing or redundancy. After the
initial deployment, you can add collectors and audit stores whenever and wherever they are needed.
Using Multiple Databases in an Audit Store
Each audit store uses Microsoft SQL Server to provide database services to the audit installation. When you install the first audit store, you configure the
database instance you want to use and that database becomes the active database for storing incoming audit data. A single audit store, however, can have
several databases attached to it. Attached databases store historical information and respond to queries from the management database. You can use the
Audit Manager console to control the databases that are attached to the audit store and to designate which database is active. Only one database can be
active in an audit store at any given time.
Although the audit store can use multiple databases, the presentation of session data is not affected. If a session spans two or more databases that are
attached to the audit store, the Audit Analyzer console presents the data as a single, unbroken session. For example, if you change the active database during
a session, some of the session data is stored in the attached database that is no longer active and some of it stored in the newly activated database, but the
session data plays back as a single session to the auditor.
Using Multiple Consoles in an Installation
A single installation always has a single audit management database. In most cases, however, you use more than one console to request data from the audit
management database. The two most important consoles in an installation are the Audit Manager console and the Audit Analyzer console.
As the audit installation owner, you use the Audit Manager console to configure and manage the auditing components in your installation. In most
organizations, there is only one Audit Manager console installed.
Auditors use the Audit Analyzer console to search, retrieve, and play back sessions. The auditor can use predefined queries to find sessions or define
new queries. Auditors can also choose whether to share their queries with other auditors or keep them private. In most organizations, there are multiple
Audit Analyzer consoles installed.
In addition to the Audit Manager and Audit Analyzer consoles, you can use the Agent Control Panel and the Collector Control Panel to configure and manage
agents and collectors.
The following figure shows the architecture of a medium-size installation.
Agent Components
On Audited UNIX computers
To enable auditing for Linux and UNIX computers, you must install the Centrify Agent for *NIX on the computers you want to audit and make sure the
computers are joined to an Active Directory domain. Joining a domain is required to ensure that authentication and authorization services are provided by
Active Directory. To enable auditing on a computer, the Centrify Agent for *NIX includes the following components:
dad—the core auditing service that collects the audit data and either sends it to a collector or spools it locally until a collector is available.
cdash—the UNIX shell wrapper that intercepts all user traffic and sends it to the dad process.
dacontrol, dainfo, dareload, and other command-line programs that enable you to manage agent operations from a login shell.
dax—the audit service that records graphical user interface sessions on xWindows computers. Consult the release notes for which xWindows versions
are supported.
If you're auditing only shell sessions on a UNIX computer: after you enable auditing on a computer, the agent captures all output (stdout), error messages
(stderr), and user input (stdin) except for passwords. By default, the agent captures user input even if a user runs commands with echo turned off. For
example, if a user logs on, then runs echo off before typing the sudo command, the auditing service captures the sudo entry as part of the user’s session.
If you're auditing xWindows sessions: the agent captures all windows that a user opens and which user interface items the user interacts with. For web
browser applications, the agent captures the title of the web page but not any activity within the web page.
On Audited Windows Computers
To enable auditing for Windows computers, you must install the Centrify Agent for Windows on the computers you want to audit and make sure the
computers are joined to an Active Directory domain. Joining a domain is required to ensure that authentication and authorization services are provided by
Active Directory. If you enable auditing for the Centrify Agent for Windows, the agent includes the following components:
wdad—the Windows audit data collection service.

wash—the Windows service that intercepts all user traffic and sends it to the Windows audit data collection service.
The Agent Control Panel—an applet that enables you to configure and manage the agent.
For example, you can use the Agent Control Panel to configure the color depth of audit data to achieve the desired balance between playback screen
resolution and audit store database size.
Planning an Audit Installation
This section describes the decisions you need to make during the planning phase of a deployment and summarizes what’s involved in deploying audit and
monitoring service components and auditing-related services on the computers to be audited. It includes simplified diagrams that highlight the steps
involved.
Deciding on the scope of the installation

Deciding where to install the management database
Deciding where to install collectors and audit stores
Deciding where to install agents
Deciding where to install consoles
Supported SQL Server editions

Checking SQL Server logins for auditing
Determining storage requirements for auditing
What’s involved in the deployment process
Deciding on the Scope of the Installation
Before you deploy any part of the auditing infrastructure, you should decide on the scope of the audit installation and whether you want to use a single
installation for your entire Active Directory site, or separate audit installations for different geographical areas or functional groups.
The most common deployment scenario is a single installation for each Active Directory forest, so that auditors can query and review information for the
entire organization. However, if your Active Directory site has more than one forest, you might want to use more than one installation. If you want to use more
than one installation, you should determine the subnetwork segments that will define the scope of each installation.
In Active Directory, a site represents the collection of Internet Protocol (IP) addresses that describe the physical structure of your network. If you are not
familiar with how Active Directory sites are defined, you should consult Microsoft documentation for more information.
Deciding Where to Install Different Audit Components
It is important to plan the installation of all the different audit and monitoring services components.
Deciding where to install the management database

Deciding where to install collectors and audit stores
Deciding Where to Install the Management DDatabase
Each audit installation has a single audit management server and audit management database. The management database is a Microsoft SQL Server
database that stores information about the installation such as the Active Directory sites or subnets associated with each audit store.
The computer you use for the audit management database should have reliable, high-speed network connectivity. The management database does not store
the captured sessions, and is, therefore, much smaller than the audit store databases. There are no specific sizing requirements or recommendations for the
You can use the following guideline as the recommended minimum hardware configuration for the computer you use as the management database:
Management database Any 1 to 2 2.33 GHz 8 GB
The audit management server is a Windows service that performs two main tasks:
The service collects audit trail events on the management database, then sends them to the audit store database.
The service automatically calculates the approximate disk space used by audited sessions.
Deciding Where to Install Collectors and Audit Stores
Although a collector and an audit store database can be installed on the same computer for evaluation, you should avoid doing so in a production
environment. As part of the planning process, therefore, you need to decide where to install collectors and audit store databases. In designing the network
topology for the installation, there are several factors to consider. For example, you should consider the following:
Database load and capacity

Network connectivity
Port requirements
Active Directory requirements
The next sections provide guidelines and recommendations to help you decide where to install the collectors and audit store databases required to support
the number of computers you plan to audit.
Use Separate Computers for Collectors and Audit Store Databases
To avoid overloading the computers that host collectors and audit store databases, you should install collectors and audit store SQL Server databases on
separate computers. Because SQL Server uses physical memory to store database information for fast query results, you should use a dedicated computer
for the audit store database, and allocate up to 80% of the computer's memory to SQL Server. In most installations, you also need to plan for more than one
audit store database and to periodically rotate from one database to another to prevent any one database from getting too large. For more information about
managing audit store databases, see Managing audit store databases.
Plan for Network Traffic and Default Ports
You should minimize the distance network packets have to travel between an agent and its collector. You should also minimize the distance between
collectors and their audit stores. If possible, you should not have more than one gateway or router hop between an agent and its collector.
To help you plan for network traffic, the following ports are used in the initial set of network transactions:

Kerberos - Ticket Granting Ticket (TGT) request on port 88.
Network Time Protocol (NTP) Server - Time synchronized for Kerberos on port 123.
Domain Name Service (DNS) - Host (A), Pointer (PTR), Service Location (SRV) records on port 53.
ports used for Server Suite software.
This
Is used for Server Suite software component
port
Server Suite authentication service, privilege elevation service, and audit and monitoring
23 TCP communication for Telnet connections service. By default, telnet connections are not allowed because passwords are transferred
over the network as plain text.
53 TCP/UDP communication Clients use the Active Directory DNS server for DNS lookup requests.
88 Encrypted UDP communication Kerberos ticket validation and authentication, agents, Server Suite PuTTY
UDP communication for simple network time protocol

123 Keeps time synchronized between clients and Active Directory for Kerberos ticketing.
(NTP)
389 Encrypted TCP/UDP communication Active Directory authentication and client LDAP service.
Cloud Connector communication with Privileged

443 Cloud Connector
Access Service
Encrypted TCP/UDP communication for delivery of The adclient and adgpupdate use Samba (SMB) and Windows file sharing to download and
445
group policies update group policies, if applicable.
This
Is used for Server Suite software component
port
Encrypted TCP/UDP communication for Kerberos Kerberos ticket validation and authentication for agents, Server Suite PuTTY, adpasswd, and
464
password changes passwd.
Encrypted TCP communication for the collector

1433 The collector service sends audited activity to the database
connection to Microsoft SQL Server
3268 Encrypted TCP communication Active Directory authentication and LDAP global catalog updates.
Encrypted TCP/RPC communication for the agent

5063 The auditing service records user activity on an audited computer.
connection to collectors
Encrypted SSL/TLS communication for the agent

The auditing service records user activity on an audited computer outside of Active
5064 connection to collectors for systems that are not
Directory.
joined to Active Directory.
none ICMP (ping) connections To determine whether if a remote computer is reachable.
Identify an Active Directory Site or Subnets
Depending on the size and distribution of your Active Directory site, an audit store might cover an entire site or specific subnet segments. If you have a large,
widely distributed site, you should consider network connectivity and latency issues in determining which subnets each audit store should serve. In addition,
you should always place collectors in the same site as the agents from which they receive data. Collectors and agents must always be in the same Active
Directory forest. If possible, you should put collectors and agents in the same domain.
Note: If you deploy agents in a perimeter network, such as a demilitarized zone (DMZ), that is separated from your main network by a firewall, put
the collectors in the same Active Directory domain as the audited computers. The collectors can communicate with the audit store database
through a firewall.
Determining How Many Collectors and Audit Stores to Install
Although you can add collectors and audit stores to your audit installation after the initial deployment, you might want to calculate how many you will need
before you begin deploying components. You should always have at least two collectors to provide redundancy. As you increase the number of agents
deployed, you should consider adding collectors.
Estimate the Number of Agents and Sessions Audited
If you plan to use more than the minimum number of collectors, the most important factor to consider is the number of concurrent sessions you expect to
monitor on audited computers. The number of concurrent sessions represents the number of agents that are actively capturing user sessions in a site at the
same time.
Guidelines for Linux and UNIX Computers
You can use the following guidelines as a starting point and adjust after you have observed how much audit data you are collecting and storing for Linux and
UNIX computers:
500 (or less) agents 2 1
up to 1000 agents 4 1
Guidelines for Windows Computers or Mixed Environments
You can use the following guidelines as a starting point and adjust after you have observed how much audit data you are collecting and storing for Windows
computers:
100 (or less) agents 2 1
If you auditing Linux, UNIX, and Windows computers, use the numbers of collectors and audit stores recommended for Windows agents unless you have
significantly fewer Windows agents.
Determine the Recommended Hardware Configuration
The hardware requirements for collectors and audit store servers depend on the size of the installation and where the components are installed on the
network. For example, the requirements for a computer that hosts the collector service are determined by the number of audited computers the collector
supports, the level of user activity being captured and transferred, and the speed of the network connection between the agents and the collector and
between the collector and its audit store.
Guidelines for Linux and UNIX Computers
You can use the following guidelines as the recommended hardware configuration for the computers you use for collectors and audit store servers when
auditing Linux and UNIX computers:
Collectors Up to 250 active UNIX agents 2 2.33 GHz 8 GB
250 to 500 active UNIX agents 4 2.33 GHz 16 GB
Audit store Up to 250 active UNIX agents 2 2.33 GHz 8 GB
Guidelines for Windows Computers
You can use the following guidelines as the recommended hardware configuration for the computers you use as collectors and audit store servers when
auditing Windows computers:
Collectors Up to 100 active Windows agents 2 2.33 GHz 8 GB
Audit store Up to 200 active Windows agents 2 2.33 GHz 8 GB
200 to 500 active Windows agents 4 2.33 GHz 32 GB
Guidelines for Storage
Because audit and monitoring service collectors send captured user sessions to the active SQL Server database, you should optimize SQL Server storage for
fast data logging, if possible. For the active database, you get the most benefit from improvements to disk write performance. Read performance is
secondary. Fibre Attached Storage (FAS) and Storage Area Network (SAN) solutions can provide 2 to 10 times better performance than Direct Attached
Storage (DAS), but at a higher cost. For attached databases that are only used to store information for queries, you can use lower-cost storage options.
Guidelines for Disk Layout
The following table outlines the recommended disk arrays:
Operating system C: RAID 1 Operating system files, page file, and SQL Server binaries.
Microsoft SQL Server D: RAID 10 (1+0) Audit store database.
E: RAID 10 (1+0) Audit store database log files.
F: RAID 1 or 10 (1+0) Temporary database space (tempdb) for large queries for reports.
G: RAID 1 Database dump files.
The size of disk needed depends on the number, length, and types of sessions recorded each day, the selected recovery model, and your data retention
policies. For more information about managing audit store databases, see Managing audit store databases.
The Centrify Agent must be installed on all of the computers you want to audit. Therefore, as part of your planning process, you should decide whether you
want to audit every computer on the network or specific computers, such as the computers used as servers or used to run administrative software.
Before installing the Centrify Agent for Windows, verify the following:

The computer has Microsoft Windows Installer version 3.1 or newer.
Agents can communicate with a collector only if the agents and collector are in the same Active Directory forest.
For UNIX and Linux systems, be aware that desktop auditing is available only for some Linux distributions. Please see the release notes for the supported
platform details.
Linux desktop auditing workings independently from shell session auditing. For platforms that support both, you can enable either one or both.
You can install and run the Audit Manager console and the Audit Analyzer console on the same computer or on different computers. The computers where you
install the consoles must be joined to the Active Directory domain and be able to access the management database that serves the installation.
You can also use the Audit Analyzer console to run queries from any additional computers with network access to the management database. Therefore, you
should decide where it would be convenient to have this capability.
Audit and Monitoring Deployment Checklist
The following checklist provides an overview of each of the main steps that are involved when you deploy the Audit & Monitoring Service. For any tasks related
to other Delinea software, there are links to more information and procedures.
For authentication and privilege elevation deployment steps, please see Authentication and Privilege Elevation services deployment checklist.
Step Auditing and Monitoring Installation Step Notes Link to Details
Preparation and Planning
Analyze your network topology to determine where to install

Overview of the Auditing
1 components and services and any hardware or software updates
Infrastructure
required.
Create a list of the computers where you plan to install different

2 Planning an Audit Installation
components.
Deciding on the Scope of the

3 Determine the scope of the audit installation.
Installation
Sizing Recommendations for Audit

4 Determine the size of your database storage.
Installations
Pre-Requisite Tasks
Create Active Directory security groups for managing the permissions Creating Security Groups for
5
required for the auditing and monitoring service infrastructure. Auditing
Install Microsoft SQL Server and create a database instance for use Installing and Configuring Microsoft
6
with the audit and monitoring service. SQL Server for Auditing
This includes creating a backend

Configuring SQL Server to Prepare
7 Prepare SQL Server for auditing. service account that will run stored
for Auditing
procedures.
Create a setup user account and give it database administrator (DBA) You'll use this account and Creating a Setup User Account for
8
privileges. password to run the installers. Installation
Install Tasks
Installing the Audit Manager and

9 Install the Audit Manager and Audit Analyzer consoles.
Audit Analyzer Consoles
10 In Audit Manager, create a new installation for auditing. Creating a New Installation
Creating the First Audit Store,

11 In Audit Manager, set up the Audit Stores and Audit Store databases. Creating the First Audit Store
Database
Install and configure the audit collector service on at least two

12 Installing the Audit Collectors
Windows computers.
Install a Server Suite Agent for Windows on each Windows computer Installing the Server Suite Agent for
13
that you want to audit. Windows
Install a Server Suite Agent for *NIX on each UNIX or Linux computer
14 Installing an Server Suite Agent for
that you want to audit.
Step Auditing and Monitoring Installation Step Notes Link to Details
For this task, run the installer using Installing the Audit Management
Install and configure the Audit Management Server component on a
15 the setup user account that you Server and Configuring the Audit
Windows server computer.
created in step 8. Management Server
Configure and enable auditing on the Windows computers, if they're Enabling or Disabling Auditing on
16
not already enabled. Windows Computers
Enabling or Disabling Auditing on

17 Configure and enable auditing on the UNIX or Linux computers.
Linux and UNIX Computers
Install additional Audit Manager or Audit Analyzer consoles on any

Installing Additional Audit Manager
18 Windows computer that you want to use for the auditing and
or Audit Analyzer Consoles
monitoring service.
Verification Tasks
Verify that data is being collected and agents are working correctly:
Checking the Status of the UNIX
19 Run dainfo on audited UNIX computers. Use Audit Analyzer to verify
Agent
that data is being collected.
Supported SQL Server Editions
The current release of the Audit & Monitoring Service supports 64-bit versions of the following SQL Server editions:
SQL Server 2008 Express with Advanced Services

SQL Server 2008
SQL Server 2008 R2 Express with Advanced Services (Service Pack 2 or higher recommended)
SQL Server 2008 R2 (Service Pack 2 or higher recommended)
SQL Server 2012 (All SP levels)
SQL Server 2014 (All SP levels)
SQL Server 2016 -- all SP levels for SQL Server 2016 Standard and Enterprise including the latest 2016 SP2 CU7 version.
SQL Server 2017
SQL Server 2017 Express Advanced
SQL Server 2019
SQL Server 2019 Express Advanced
Note: SQL Server 2008 and 2008 R2 are not compatible with Windows 10
Checking SQL Server Logins for Auditing
An audit installation requires at least two Microsoft SQL Server databases: one for the management database and at least one for the first audit store
database. To successfully connect to these databases, you must ensure that the appropriate users and computers have permission to read or to read and
write for the databases that store audit-related information.
The simplest way to manage SQL Server logins for auditors and administrators is to do the following:
Ensure you have a SQL Server login account for the NT Authority\System built-in account.
Add the NT Authority\System account to the sysadmin fixed server role.
Use the Audit Manager console to add Active Directory users and groups to the Auditor roles and/or assign them administrative rights over the audit
installation.
If you use Audit Manager to manage SQL Server logins, you can use Active Directory membership to automatically add and remove the permissions required
for auditing activity. There is no requirement to use the SQL Server Management Studio to manage logins or permissions. Since it is recommended that you
have a dedicated SQL Server instance for auditing, giving the NT Authority\System account a SQL Server login and system administrator role is an
acceptable solution for most organizations.
Auditing Permissions for SQL Server
SQL Server account Type of account Required permissions Notes
NT Authority\System machine account SQL Server Roles: sysadmin role
Creating Security Groups for Auditing
Depending on whether you configure Microsoft SQL Server to use Windows only authentication or Windows or SQL Server authentication, your SQL Server
login credentials might be a Windows account or a SQL Server login account that is not associated with a Windows account.
To facilitate communication and the management of SQL Server logins, you can create Active Directory security groups for the following users and
computers:
Centrify-Admins for the user accounts that perform administrative tasks using Audit Manager.
Centrify-Auditors for the user accounts that use Audit Analyzer.
Centrify-TrustedCollectors for the computers accounts that host the collector service.
If you create these Active Directory security groups, you can then use Audit Manager to grant Manage SQL Login permissions for each group to allow its
members to connect to the appropriate SQL Server database. Creating Active Directory security groups with SQL Server logins enables you to manage
access to the databases required for auditing through Active Directory group membership without the help of the database administrator.
Any time you want to add an administrator, auditor, or collector computer to the installation, you simply add that user account or computer object to the
appropriate Active Directory group. If an administrator or auditor leaves or if you want to stop using the collector on a particular computer, you can remove
that user or computer from its Active Directory security group to prevent it from accessing the database.
Auditing Security Groups
Active Directory Security Type of Required SQL Server

Notes
Groups account permissions
Centrify-Admins for the user no explicit SQL Server Creating Active Directory security groups with SQL Server logins enables
accounts that perform Active permissions needed — Audit you to manage access to the databases required for auditing through
administrative tasks using Audit Directory Manager handles the SQL Active Directory group membership without the help of the database
Manager. Server permissions administrator.
Centrify-Auditors for the

user accounts that use Audit
Analyzer.
Centrify-Collectors for the
Active Directory Security Type of Required SQL Server
Notes
Groups account permissions
computer accounts that host the

collector service.
Determining Storage Requirements for Auditing
There are two important policy decisions your organization must make to determine how much disk space you need for storing audit data and how frequently
you should plan to rotate the active database. Early on in the deployment, your organization should consider the following policy decisions:
What is your rotation policy?
To answer this question, you should decide the period of time audited sessions should be available in the active and attached database for auditors to
review using the Audit Analyzer console. For example, you might decide that you want to be able to query audited activity for a minimum of 90 days.
Alternatively, you might want to define a rotation policy that is based on the size of the database, so that the active database is not allowed to exceed a
specific size. For example, you might decide that the database should not exceed 4GB to optimize performance for archiving.
What is your retention policy?
To answer this question, you should decide the period of time to keep audited data available in attached databases and the maximum period of time to
keep archived audit data available before purging data that’s no longer needed.
To illustrate how these policies affect database management, consider a rotation policy based on a monthly schedule. In this example, an organization
decides that audit data must be available for querying for a minimum of 90 days. On the first of each month, a new active database is brought online and the
previous 3 months remain available as attached databases to support querying 90 to 120 days of audit data.
In this model, there are four databases online at the same time. This example organization has also decided on a two-stage retention policy. In the first stage,
older databases are detached from Audit Analyzer, but remain stored on the SQL Server instance for up to one year. The detached databases provide up to a
year of audit history and can be reattached, if that data is needed. In the second stage of the retention policy, the organization archives the audit store
databases for up to 3 years. After three years, the oldest data is permanently purged.
Depending on your requirements, you might use a similar retention policy or have different policies based on the session activity you are capturing. For
example, you might keep sessions that capture normal user activity for three years, but keep sessions that capture SOX compliance for ten years.
To project your storage requirements, you will need additional information that is specific to your organization, including the number of computers you plan to
audit, the number of sessions that are active on audited computers, and whether you record all activity using video capture or only summaries of user activity.
To collect this information, you should monitor a pilot deployment. You can then use the information from the pilot deployment as described in Estimating
database requirements based on the data you collect to estimate your storage requirements based on how much audit data you are generating. The
decisions you make for the rotation and retention policies will help you further refine those estimations as you expand the deployment.
Note: If you define a rotation policy similar to this example, you can automate the monthly database rotation using Centrify application
programming interfaces or using scheduled SQL Server jobs or scripts that perform database maintenance operations. For more information, see
the Database Management Guide.
What’s Involved in the Deployment Process
Most of the planning in this chapter has focused on designing the auditing infrastructure and deciding where to install components. The following illustration
provides a visual summary of the complete deployment process and highlights the keys to success. The sections after the flowchart provide additional
details about what’s involved in each phase or the decisions you will need to make, such as who should be part of the deployment team, where to install the
software, and who has permission to do what.
Plan
During the first phase of the deployment, you collect and analyze details about your organization’s requirements and goals. You can then also make
preliminary decisions about sizing, network communication, and where to install components.
Identify the goals of the deployment.

Is auditing important for specific computers?
Is auditing important for computers used to perform administrative tasks?
Is auditing important for computers that host specific applications or sensitive information?
Should auditing be required for users in specific groups or with specific roles?
Assemble a deployment team with Active Directory, UNIX, and other expertise, including at least one Microsoft SQL Server database administrator.
Provide basic training on Centrify architecture, concepts, and terminology.
Analyze the existing environment to identify target computers where you plan to install Centrify auditing infrastructure components.
Review network connections, port requirements, firewall configuration.
Identify computers for Audit Manager and Audit Analyzer consoles.
Identify computers to be used as collectors, audit stores, and the management Database.
Verify that you have reliable, high-speed network connections between components that collect and transfer audit data and sufficient disk
storage for the first audit store database.
Identify the initial target group of computers to be audited.
Define and document your data archiving and data retention policies.
Prepare
After you have analyzed the environment, you should prepare the Active Directory groups to use. You can then install administrative consoles and the auditing
infrastructure.
(Optional) Create the additional Active Directory security groups for your organization.
Groups can simplify permission management and the separation-of-duties security model.
Install Audit Manager and Audit Analyzer on at least one administrative Windows computer.
Create a new audit installation and a management database on one computer.
Create an audit store and audit store database on at least one computer.
Install a collector on at least two computers.
Deploy
After you have prepared Active Directory, installed administrative consoles on at least one computer, and created at least one installation, you are ready to
deploy agents on the computers to be audited.
Install the agent on the computers you want to audit.

Join the appropriate domains and zones.
Prepare a Group Policy Object for deploying agents remotely using a group policy.
Assign the appropriate permissions to the users and groups who should have access to audit data.
Validate
After you have deployed agents on target computers, you should test and verify operations before deploying on additional computers.
Log on locally to a target computer using an Active Directory user account and password to verify Active Directory authentication.
Open Audit Analyzer and query for your user session.
Manage
After you have tested and verified auditing operations, you are ready to begin managing your audit installation.
Secure the installation.

Add auditor roles and assign permissions to the appropriate users and groups.
Create new databases and rotate the active database.
Archive and delete old audit data.
Installing the Audit and Monitoring Service
This chapter describes how to install Delinea Audit & Monitoring Service in a production environment. In production environments, you should use a different
computer for each component. For example, you should install the collector on its own computer separate from the computer used for the audit store
database, and on a separate computer from the audit management database.
To create a simpler installation with all components on the same computer for evaluation purposes, see the Evaluation Guide for Linux and UNIX. For
evaluation of auditing features in a Windows-only environment, see the Evaluation Guide for Windows.
Installation Preview
Installing and Configuring Microsoft SQL Server for Auditing
Creating a Setup User Account for Installation
Creating a new Installation
Installing the Audit Collectors
Installing the Audit Management Server
Installing the Agent for Windows
Enabling or Disabling Auditing on Windows computers
Installing an Agent for
Enabling or Disabling Auditing on Linux and UNIX Computers
Enabling or Disabling Video Capture Auditing
Installing Additional Audit Manager or Audit Analyzer Consoles
Checklist for Auditing Systems outside of Active Directory
Auditing Systems that are inside a DMZ
Installation Preview
As a preview of what’s involved in the installation process, the following steps summarize what you need to do and the information you should have on hand
for a successful deployment of Centrify software.
To prepare for deployment:
1. Analyze your network topology to determine where to install components and services and any hardware or software updates required.
For a review of the decisions to make and recommended hardware configuration, see Planning an audit installation.
2. Create a list of the computers where you plan to install different components.
For example, list the computers where you plan to install agents, collectors, audit store databases, and consoles.
For a review of the requirements associated with each component, see Planning an audit installation.
3. Determine the scope of the audit installation.
The most common deployment scenario is a single installation for an Active Directory site, but you can have more than one installation, if needed, and
use subnets to limit the scope of the installation.
For a review of what constitutes an installation, see Deploying auditing components in an audit installation and Deciding on the scope of the installation.
4. Create Active Directory security groups for managing the permissions that are required for accessing the databases that store audit-related
information.
For a review of the Active Directory security groups to create, see Checking SQL Server logins for auditing.
5. Install Microsoft SQL Server.
If you are not a database administrator in your organization, you should submit a service request or contact an administrator who has permission to
create databases.
For more information about preparing a SQL Server database engine for auditing, see Installing and configuring Microsoft SQL Server for auditing.
6. Install the Audit Manager and Audit Analyzer consoles.
For more information about installing the consoles, see Installing the Audit Manager and Audit Analyzer consoles.
7. Create a service account with the permissions to create a new installation. For details, see Creating a setup user account for installation.
8. Open Audit Manager to create a new installation.
For more information about using Audit Manager to create a new installation and audit store, see Creating a new installation.
9. Install the audit collector service on at least two Windows computers.
You can add collectors to the installation at any time. For more information about installing and configuring collectors, see Installing the audit
collectors.
10. Install the Audit Management Server on a Windows computer.
For more information, see Installing the Audit Management Server.
11. Install a Centrify Agent on each Windows, Linux, or UNIX computer you want to audit.
For more information about installing Centrify Agents, see Installing the Centrify Agent for Windows and Installing an Centrify Agent for *NIX.
12. Make sure agents are enabled for auditing. For details, see Enabling or disabling auditing on Windows computers and Enabling or disabling auditing on
Linux and UNIX computers.
13. Install additional Audit Manager or Audit Analyzer consoles on any Windows computer that you want to use to manage the installation or query and play
back session data.
After the initial deployment, you can add new agents, collectors, audit stores, and audit store databases to the installation or create additional installations.
Installing and configuring Microsoft SQL Server for Auditing
If you want to audit user activity on Windows, you must have at least one Microsoft SQL Server database instance for the audit management database and
audit store databases. Centrify recommends that you use a dedicated instance of SQL Server for the audit management database. A dedicated SQL Server
instance is an instance that does not share resources with other applications. The audit store databases can use the same dedicated instance of SQL Server
or their own dedicated instances.
There are three database deployment scenarios for your audit installation:
Evaluation—You can install Microsoft SQL Server Express with Advanced features directly from the configuration wizard or by running the
SQLEXPRADV_x64_ENU.exe setup program to create a new Microsoft SQL Server Express database instance for testing. However, if you are auditing a
production environment*,* you should not use Microsoft SQL Server Express.
If you choose to install a different version of Microsoft SQL Server Express for an evaluation and the version requires .NET version 3.5 SP1, you will need
to manually install the .NET files yourself (the installer doesn't include these files)..
Manual installation with system administrator privileges—Install a Microsoft SQL Server database instance for which you are a system
administrator or have been added to the system administrator role.
Manual installation without system administrator privileges—Have the database administrator (DBA) install an instance of Microsoft SQL
Server and provide you with system administrator credentials or information about the database instance so that you can create the management
database and audit store databases.
Downloading and installing SQL Server manually
You can use an existing instance of Microsoft SQL Server or install a new instance. You can install Microsoft SQL Server directly from the Centrify ISO or ZIP,
or download it from the Microsoft web site. In selecting a version of SQL Server to download, you should be sure it includes Advanced Services. Advanced
Services are required to support querying using SQL Server full-text search.
After downloading an appropriate software package, run the setup program using your Active Directory domain account and follow the instructions displayed
to complete the installation of the Microsoft SQL Server instance.
When selecting the components to install in the setup program, expand the Database Services and select Full Text Search as a feature to be installed. For the
authentication mode, select Windows authentication if all connections between auditing components will be in the same forest. If any communication will be
outside of the forest, use Mixed Mode authentication and select the option to add the current user to the SQL Server Administrator role.
Note: Centrify does not recommend running SQL Server under a high privilege account such as a LocalSystem account.
Configuring SQL Server to prepare for auditing
After you install the SQL Server database engine and management tools, you should configure the SQL Server instance for auditing. For example, depending
on the version of SQL Server you install, you might need to manually enable fulltext search.
To prepare a Microsoft SQL Server database instance for storing audit data:
Use SQL Server Surface Area Configuration for Services and Connections to check the status and start the database engine, full-text search, and SQL
Server Browser services.
Use SQL Server Surface Area Configuration for Services and Connections or SQL Server Configuration Manager to enable remote connections for
TCP/IP.
Verify whether SQL Native Client Configuration Client Protocol is using the default TCP port 1433 for network communications. If you use a different
port, you should note the port number because you will need to specify it in the server name when you create the management and audit store
databases.
Use SQL Server Configuration Manager to restart the SQL Server and SQL Server Browser services.
Create a database backend service account in the system administrator (sa) fixed server role on the selected database server; you'll specify this
account when you create the audit installation. This account is used to run backend stored procedures. If desired, this can be the same account that you
use the create the audit installation, as mentioned in Creating a setup user account for installation.
Configuring Amazon RDS for SQL Server for auditing
You can deploy audit store databases on Amazon RDS instances, if desired. Centrify supports Amazon RDS for 2016 and earlier versions (not 2017).
You must host the audit management database on a traditional SQL Server, such as SQL Server Express, Standard, or Enterprise.
If you want to use an instance of Amazon RDS for SQL Server for audit store databases you need to do the following configurations:
After you set up your Amazon RDS for SQL Server, join the RDS SQL server to AWS Microsoft Active Directory.
Enable these DB Parameter Group settings on RDS SQL Server:
clr enabled
show advanced options
You can use the AWS Management Console, API, or the AWS command line interface to enable these settings.
For more details, see <http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html>.
Set up a one-way or two-way forest trust between the AWS Microsoft Active Directory and your on-premise Active Directory forest so that users of your
on-premise Active Directory forest can access resources in the AWS Microsoft Active Directory.
Note: Amazon RDS for SQL Server with High Availability is supported.
Amazon RDS for SQL Server required permissions
The permissions for Amazon RDS for SQL Server vary a little from the permissions for local or network instances of SQL Server. This section covers the
Amazon RDS for SQL Server permission required or granted for each auditing component.
Permissions to the audit store database stored procedures service account
The stored procedures service account (in other words, the ‘execute as’ account) no longer requires the sysadmin server role permission if the audit store
database is on Amazon RDS for SQL Server.
The service account requires only the db_owner database role permission and the account will be added to be member of db_owner database role by Add
Audit Store Database wizard.
Note:You do not need to grant the permissions manually. The Audit Manager console, Powershell cmdlet, or SDK grants the permissions to the
service account.
Collector account permissions for audit store databases on Amazon RDS for SQL Server
The collector account requires the following server level permissions on the Amazon RDS for SQL Server:
'View Any Definition' server level permission

'View Server State' server level permission
The collector account requires the following database level permissions on the audit store database:
A member of the 'collector' database role
Note:You do not need to grant the permissions manually. The Audit Manager console, Powershell cmdlet, SDK, or the Collector
Configuration wizard grants the permissions to the collector account.
Management Database Account permissions for audit store databases on Amazon RDS for SQL Server
The management database account requires the following server level permissions on the RDS SQL server:
'Alter Trace' server level permission

'Alter Any Login' server level permission
Grant permission of 'Alter Any Login' server level permission
Grant permission of 'View Any Definition' server level permission
Grant permission of 'View Server State' server level permission
The management database account requires the following database level permissions on the audit store database:
A member of 'managementdb' database role
Note:You do not need to grant the permissions manually. The Audit Manager console, Powershell cmdlet, or SDK grants the permissions to
the management database account.
Permissions to create the audit store database on Amazon RDS for SQL Server
In order to create an audit store database on Amazon RDS for SQL Server, you must have the following permissions:
'Create Any Database' server level permission to create the database on the server
'Alter Any Login' server level permission to create the login for the management database account and the collector account
Alter Any Login' server level permission to grant the 'Alter Any Login' permission to the management database account
'Alter Trace' server level permission to grant the 'Alter Trace' permission to the management database account
'View Any Definition' server level permission to grant the 'View Any Definition' (with grant) permission to the management database account and also to
grant the 'View Any Definition' permission to the collector account
Grant permission of 'View Server State' server level permission to grant the 'View Server State' (with grant) permission to the management database
account and also to grant the 'View Server State' permission to the collector account
Permissions to upgrade the audit store database on Amazon RDS for SQL Server
The required permission to upgrade the audit store database on Amazon RDS for SQL Server is the ‘db owner’ permission on the database. No server level
permissions are required
You can install Audit Manager and Audit Analyzer on the same computer or on different computers. The computers where you install the consoles must be
joined to the Active Directory domain and be able to access the management database.
In most cases, the consoles are installed together on at least one computer.
You can use either the individual console installers or the main installer.
Install Audit Manager using the console installer

Install Audit Analyzer using the console installer
Install both consoles using the main installer
Install Audit Manager Using the Individual Console Installer
1. Log on using an Active Directory domain account.
2. Open the ISO file, and navigate to the following folder:
\DirectAudit\Console\
3. Run the Audit Manager installer : Centrify DirectAudit Administrator Console64.exe.
5. Review the terms of the license agreement, click I accept the terms in the license agreement, then click Next.
6. On the Destination Folder page, review the installation location and click Next to continue.
7. If you want to install the console in a different location, click Change and navigate to the desired folder.
9. The installer installs the necessary files. To open the console, keep the Launch Centrify Audit Manager option selected. Otherwise, deselect the
option.
10. Click Finish to close the installer.
After you install Audit Manager, you can open Audit Manager to create a new installation.
Install Audit Analyzer Using the Individual Console Installer
\DirectAudit\Console\
3. Run the Audit Manager installer : Centrify DirectAudit Auditor Console64.exe.
9. The installer installs the necessary file. To open the console, keep the Launch Centrify Audit Analyzer option selected. Otherwise, deselect the
option.
Install Audit Manager and Audit Analyzer on the Same Computer Using the Main Installer
2. Open the ISO file.
If you created a physical CD from the ISO file that you downloaded, the Getting Started page is displayed automatically. If the page is not displayed, open
the autorun.exe file to start the installation.
3. On the Getting Started page, click Audit & Monitor to start the setup program for audit and monitoring service components.
6. Select Centrify Administration to install both Audit Manager and Audit Analyzer, then click Next.
7. In the rare case where the administrator should not have access to the Audit Analyzer, select Audit Manager, then click Next.
8. After you install Audit Manager, you are prompted to create a new installation. If you want to create the installation at a later time, you can run the setup
program again to create a new installation.
Creating a Setup User Account for Installation
You'll need to create an account to use when you create the audit installation, set up audit stores, and so forth. This account needs to have the following
permissions:
Active Directory:
Permission to create serviceConnectionPoint objects on the container or organizational unit you select for publishing installation information
SQL Server:
Be a member of the system administrator (sa) fixed server role
This user account needs these permissions for the initial installation and some maintenance tasks. It's a good practice to add this account to your Centrify-
admins security group, as mentioned in Creating security groups for auditing.
Creating a New Installation
Before you can begin auditing, you must create at least one audit installation and a management database. Creating the management database, however,
requires SQL Server system administrator privileges on the computer that hosts the SQL Server instance. If possible, you should have a database
administrator add your Active Directory domain account to the SQL Server system administrators role.
If you have not been added to the system administrators role, you should contact a database administrator to assist you. For more information about creating
a new installation when you don’t have system administrator privileges, see How to create an installation without system administrator privileges.
To Create a New Installation and Management Database as a System Administrator
1. Log on using an Active Directory account with permission to install software on the local computer and permissions listed in Creating a setup user
account for installation.
Note:If you haven’t configured an audit installation yet, the New Installation wizard opens automatically.
3. If this isn’t your first audit installation: in Audit Manager, right-click Centrify Audit Manager and select New Installation to open the New
Installation wizard.
4. Enter a name for the new installation, then click Next.
T i p: Name the installation to reflect its administrative scope. For example, if you are using one installation for your entire organization, you
might include the organization name and All or Global in the installation name, such as AcmeAll. If you plan to use separate installations for
different regions or divisions, you might include that information in the name, for example AcmeBrazil for a regional installation or
AcmeFinance for an installation that audits computers in the Finance department.
5. Select the option to create a new management database and verify the SQL Server computer name, instance name, and database name are correct.
If the server does not use the default TCP port (1433), you must provide the server and instance names separated by a backslash, then type a comma
and the appropriate port number. For example, if the server name is ACME, the instance name is BOSTON, and the port number is 1234, the server name
would be ACME\BOSTON,1234.
If you're installing on a SQL cluster, enter the SQL cluster name in the SQL Server computer name field.
parameters:
6. Select Use the default NT AUTHORITY\SYSTEM account to use the internal account or select a specific SQL login account with sufficient
privileges, then click Next.
A SQL login account is required to run the stored procedures that read and write information to the management database. The account must a
member of the system administrator (sa) fixed server role on the selected database server, as mentioned in Configuring SQL Server to prepare for
auditing.
7. Type the license key you received, then click A d d or click Import to import the keys directly from a file, then click Next.
8. Accept the default location or click Browse to select a different Active Directory location for publishing installation information, then click Next.
You must have the Active Directory permission to Create serviceConnectionPoint objects on the container or organizational unit you select for
publishing installation information.
9. Select the installation-wide auditing options you want to enable, then click Next.
Select Enable video capture recording of user activity if you want to capture shell or desktop activity on computers when users are
audited, then click Next.
Selecting this option enables you to review everything displayed during an audited user session, but will increase the audit store database storage
requirements for the installation. You can deselect this option if you are only interested in a summary of user activity in the form of audit trail events.
Audit trail events are recorded when users log on, open applications, and select and use role assignments with elevated rights.
Select Do not allow any users to review their own sessions to prevent all users from updating the review status for their own sessions or
adding comments to their own sessions.
Select Do not allow any users to delete their own sessions to prevent all users from deleting their own sessions.
If you set either of the installationwide policies disallowing user activity, the policy takes precedence over any rights provided by a user’s audit role.
10. Review details about the installation and management database, then click Next.
If you have SQL Server system administrator (sa) privileges and can connect to the SQL Server instance, the wizard automatically creates the management
database.
11. Select the Launch Add Audit Store Wizard option if you want to start the Add Audit Store wizard, then click Finish
If you want to create the first audit store database on a different SQL Server instance, you should deselect the Launch Add Audit Store Wizard option
and click Finish.
For more information about adding the first audit store database, see Creating the first audit store.
How to Create an Installation without System Administrator Privileges
If you do not have the appropriate permission to create SQL Server databases, you cannot use the New Installation wizard to create the management
database without the assistance of a database administrator.
administrator. For example:
If you don’t have a database administrator immediately available who can enter the credentials for you, you cannot continue with the installation.
To Create an Installation when you don’t have System Administrator Privileges
1. Select the option to generate the SQL scripts, then click Next.
2. Select the folder location for the scripts, then click Next.
3. Review details about the installation and management database you want created, then click Next.
The wizard generates two scripts: Script1 prepares the SQL Server instance for the management database and Script2 creates the database.
4. Click Finish to exit the New Installation wizard.
5. Send the scripts to a database administrator with a service or change-control request.
Note:You should notify the database administrator that the scripts must be run in the proper sequence and not modified in any way.
Changes to the scripts could render the database unusable.
6. After the database administrator creates the database using the scripts, open the Audit Manager console to run the New Installation wizard again.
7. Type the name of the installation, then click Next.
8. Select Use an existing database and verify the database server and instance name, then click the Database name list to browse for the database
name that the database administrator created for you.
9. Select the database name from the list of available databases, click O K, then click Next.
You should only select an existing database if the database was created using scripts provided by Centrify.
10. Select Use the default NT AUTHORITY\SYSTEM account to use the internal account or select a specific SQL login account with sufficient
privileges, then click Next.
A SQL login account is required to run the stored procedures that read and write information to the management database. The account must a member of
the system administrator (sa) fixed server role on the selected database server.
11. Type a license key or import licenses from a file, then click Next.
12. Review details about the management database to be installed, then click Next.
Creating the First Audit Store
If you selected the Launch Add Audit Store Wizard check box at the end of the New Installation Wizard, the Add Audit Store Wizard opens automatically. You
can also open the wizard at any time by right-clicking the Audit Stores node in the Audit Manager console and choosing Add Audit Store.
To create the first audit store:
1. Type a display name for the audit store, then click Next.
T i p: If your plan specifies multiple audit stores, use the name to reflect the sites or subnets serviced by this audit store. Note that an audit
store is actually a record in the management database. It is not a separate process running on any computer. You use a separate wizard to
create the databases for an audit store.
2. Select the type of systems that the audit store will serve.
You can choose to separate Windows traffic from UNIX traffic if both types of agents belong to the same site or subnet.
The options are:
Windows and UNIX

Windows
UNIX
3. Click Add Site or Add Subnet to specify the sites or subnets in this audit store.
If you select Add Site, you are prompted to select an Active Directory site.
If you select Add Subnet, you are prompted to type the network address and subnet mask.
After you make a selection or type the address, click O K. You can then add more sites or subnets to the audit store. When you are finished adding sites
or subnets, click Next to continue.
The computer you use to host the audit store database should be no more than one gateway or router away from the computers being audited. If your
Active Directory sites are too broad, you can use standard network subnets to limit the scope of the audit store.
4. Review information about the audit store display name and sites or subnets, then click Next.
5. Select the Launch Add Audit Store Database Wizard option if you want to create the first audit store database, then click Finish.
Creating the First Audit Store Database
If you selected the Launch Add Audit Store Database Wizard check box at the end of the Launch Add Audit Store Wizard, the Add Audit Store Database Wizard
opens automatically. You can also open the wizard at any time from the Audit Manager console by expanding an audit store, right-clicking the Databases
node, and choosing Add Audit Store Database.
To create the first audit store database:
The default name is based on the name of the audit store and the date the database is created.
2. Select the option to create a new database and verify that the SQL Server computer name, instance name, and database name are correct.
The default database name is the same as the display name. You can change the database name to be different from the display name, if you want to
use another name.
When entering the SQL Server host computer name, note that you can enter either the server short name (which is automatically resolved to its fully
qualified domain name, or FQDN) or the actual server FQDN or the CNAME alias for the server.
If the database is an Amazon RDS SQL Server:
1. Select the This is an Amazon RDS SQL Server option.

2. In the Server Name field, enter the RDS SQL Server database instance endpoint name used for Kerberos authentication.
For example, if the database host name is northwest1 and the domain name is sales.acme.com, then the endpoint name would be
northwest1.sales.acme.com.
Click Options to enter additional connection string parameters or to enable data integrity checking.
parameters:
You can enable or disable data integrity checking once, when you create the audit store database. To change the state, you must rotate to a new
When you create your audit store database, you have the option to enable data integrity checking. Data integrity checking provides the ability to detect
if auditing data has been tampered. For example, data integrity checking can detect if a user who has write privileges over the Audit Store database
directly manipulates the audited session data by making a direct connection to the Microsoft SQL Server database. Data integrity checking cannot
detect tampering if a database administrator deletes an entire session or database.
3. Because this is the first audit store database, you also want to make it the active database. This option is selected by default. If you are creating the
database for future use and don’t want to use it immediately, you can deselect the Set as active database option. The option to create a new
database is also selected by default.
4. Specify the stored procedures services account:
Select Use the default NT AUTHORITY\SYSTEM account to use the internal account
Or, select Specify a SQL Login account and enter a specific SQL login account with sufficient privileges.
A SQL Server login account is required to run the stored procedures that read and write information to the management database.
For local or network databases, the account must a member of the system administrator (sa) fixed server role on the selected database server.
If the database is an Amazon RDS for SQL Server, the account you specify will be added as a member of the db_owner fixed database role in Amazon
RDS for SQL Server.
5. Review details about the audit store database, then click Next.
If you have the correct privileges and can connect to the SQL Server instance, the wizard automatically creates the audit store database.
Installing the Audit Collectors
After you have created a new installation, with an audit management database and at least one audit store and audit store database, you must add the
collectors that will receive audit records from the agents and forward those records to the audit store. For redundancy and scalability, you should have at
least two collectors. For more information about planning how many collectors to use and the recommended hardware and network configuration for the
collector computers, see Deciding where to install collectors and audit stores.
Set the Required Permission
Before you configure a collector, you should check whether your user account has sufficient permissions to add new collector accounts to the audit store
database. If you are a database administrator or logged on with an account that has system administrator privileges, you should be able to configure the
collector without modifying your account permissions. If you have administrative rights on the computer that hosts Audit Manager but are not a database
administrator, you can set the appropriate permission before continuing.
To set the permission required to add accounts to the audit store database:
2. Expand the installation, then expand Audit Stores.
3. Select the audit store that the collector will connect to, right-click, then click Properties.
5. Click A d d to search for and select the user who will configure the collector.
6. Select the Manage SQL Logins right, then click O K.
Install the Collector Service using the Setup Program
If your user account has sufficient permissions to add new collector accounts to the audit store database, you can install a collector by running the setup
program on the computer on which you want to install the collector. When you are prompted to select components, select Audit Collector and deselect all of
the other components, then click Next. Follow the instructions in the wizard to select the location for installing files and to confirm your selections, then click
Finish to complete the installation.
The collector installer is in the \DirectAudit\Collector folder in your installation media.
Configure the Audit Collector Service
By default, when you click Finish, the setup program opens the Collector Configuration Wizard. Alternatively, you can launch the configuration wizard at any
time by clicking Configure in the Collector Control Panel.
To configure the collector service:
1. On the first screen of the Collector Configuration Wizard, select the DirectAuditinstallation to assign this collector to.
If the computer is also enrolled in the Centrify Cloud Platform and you have already enabled auditing in the Admin Portal, you can choose which kind of
audit installation to assign the collector to:
Automatic: This option configures the collector to receive audit data from systems that are enrolled in the Centrify Cloud Platform and systems
that are joined to Active Directory.
You use the Admin Portal to configure which installation is used by these systems. The systems have either the Centrify Client for Linux or Centrify
Client for Windows and the audit packages installed so that auditing is enabled. These systems do not have to be joined to Active Directory.
Manual: This option configures the collector to receive audit data from systems that are joined to Active Directory and have either the Centrify
Agent for *NIX or Centrify Agent for Windows installed and the system is enabled for auditing. For this option, select the audit installation.
Computers that are not enrolled in the Centrify Cloud Platform have a single list of audit installations to pick from.
The configuration wizard verifies that the specified installation has an audit store that services the site that the collector is in and that the collector and
its audit store database are compatible.
2. Enter the port number(s) that the collector will use to communicate with the audited systems.
The default port is 5063 for systems that have either the Centrify Agent for *NIX or Centrify Agent for Windows installed.
If the computer is also enrolled in the Centrify Cloud Platform, the default port is 5064 for systems that have either the Centrify Client for Linux or
Centrify Client for Windows installed.
If you set the installation to Manual in the previous step, Centrify Client System port is greyed out.
For either port, if you specify a different port and have the default Windows firewall turned on, the wizard checks whether the port is open. If the
port isn't open, the wizard offers to open it for you.
If you are using another vendor’s firewall, open the port with the tools provided by that vendor. If there’s an upstream firewall—such as a dedicated
firewall appliance—between the collector and the computers to be audited, contact the appropriate personnel to open the port on that firewall.
3. If the computer where you’re configuring a collector belongs to multiple audit stores in the auditing installation, choose which audit store this collector
will connect to, then click Next.
For example, two audit stores can have an overlapping scope if one audit store scope is configured for Active Directory sites and another one is set by
subnets.
4. Select whether you want to use Windows authentication or SQL Server authentication when the collector authenticates to the audit store database,
then click Next.
In most cases, you should choose Windows authentication to add the computer account to the audit store database as a trusted, incoming user.
If Microsoft SQL Server is in a different forest or in an untrusted forest, you should use SQL Server Management Studio to set up one or more SQL Server
login accounts for the collector. After you create the SQL Server login account for the collector to use, you can select SQL Server authentication, then
type the SQL Server login name and password in the wizard.
5. Type the maximum number of connections for the Microsoft SQL Server connection pool, then click Next.
6. Review the settings for the collector, then click Next.
7. Click Finish to close the wizard and start the collector service.
Installing the Audit Management Server
It's a best practice to install the Audit Management Server after you've installed your audit stores, audit store databases, and installed your collectors. You
can install the Audit Management Server either on a new computer or one where you've installed a collector.
To install the Audit Manager Server:
\DirectAudit\Audit Management Server\
3. Run the Audit Management Server installer : Centrify DirectAudit Audit Management Server64.exe.
9. The installer installs the necessary files. To open the console, keep the Run Audit Management Configuration Wizard option selected.
Otherwise, deselect the option.
Configuring the Audit Management Server
By default, when you finish installing the Audit Management Server, the installer opens the Audit Management Server Configuration Wizard.
To configure the Audit Management Server:
1. On the first page, select the installation for which you want to configure the Audit Management Server.
If you have one installation, it's already selected.
2. On the Authentication Type page, specify which kind of authentication that the Audit Management Server will use. The choices are:
Windows Authentication: Specify the computer account that will run the Audit Management Server.
SQL Server Authentication: Specify the SQL Server user name and password to use. Click Test Connection to make sure that the login
credentials work.
3. On the Summary page, review the Audit Management Server configuration details, and click Next to continue.
Installing the Centrify Agent for Windows
You must install an agent on every Windows computer that you want audit. You can install the agent in the following ways:
Interactively, by running the Centrify setup program on each computer.
When the installation finishes, the agent configuration wizard launches automatically. You can configure the agent right away, or exit the configuration
wizard and configure the agent later. See Installing interactively using the setup program for details.
Silently, by executing appropriate commands in a terminal window on each computer.
You can installation silently on a local computer or use a software distribution product, such as Microsoft System Center Configuration Manager
(SCCM), to execute the appropriate commands remotely to deploy agents on remote computers. After installation, you can change the default agent
settings, if needed. See Installing silently by using the Microsoft Windows Installer for details.
Silently and centrally, by using a group policy to execute commands remotely on the computers in a domain or organizational unit.
If you use the Centrify Group Policy Deployment files, you can both install and configure the registry on remote computers from a central location
without a separate software distribution product. However, you must configure the Windows agent registry settings in a file before deploying. See
Installing from a central location by using group policy for details.
Regardless of the deployment method you choose, you should first make sure that the computers where you plan to deploy meet all of the installation
prerequisites.
Verify Prerequisites
Before installing the Windows agent, verify the computer on which you plan to install meets the following requirements:
The computer is running a supported Windows operating system version.

The computer has sufficient processing power, memory, and disk space for the agent to use.
The computer has the .NET Framework, version 4.5.2 or later.
The computer has Windows Installer version 3.1, or later.
If you are installing interactively using the setup program, the setup program can check that the local computer meets these requirements and install any
missing software. If you are installing silently from the command line or by using a Group Policy Object, you should verify the computers where you plan to
install meet these requirements. If you are installing silently and a computer does not meet these requirements, the installation will fail.
Installing Interactively Using the Setup Program
If you select auditing when you install the Windows agent, the agent starts capturing user session activity immediately after it is installed. Therefore, you
should be sure that you have an installation, audit store database, and collector prepared and available before installing an agent. If the agent cannot connect
to an installation, it stores the captured session data locally and can quickly overload the local computer’s resources.
To install the agent on Windows using the setup program:
1. Log on to the computer and insert the CD or browse to the location where you have saved downloaded Centrify files.
If the Getting Started page is not displayed automatically, open the autorun.exe file.
2. On the Getting Started page, click Agent to start the setup program for the Windows agent.
5. Verify the location where files will be installed, then click Next.
If you want to install in a location other than the default location, click Browse, select a different location, then click Next.
6. Click Install.
7. Click Finish to complete the installation and start the agent configuration wizard.
8. In the Centrify Agent Configuration window, click Add Service.
9. In the dialog box that opens, select the Centrify Auditing and Monitoring Service option and click O K.
10. In the Enable session capture and replay window, select the auditing installation to which you want the agent on this computer to connect.
The Centrify Auditing and Monitoring Service is now listed as an enabled service.
11. Close the Agent configuration window and click Exit in the installer window.
Configuring the Agent Settings for Auditing
The agent configuration wizard automatically configures several default settings in the agent registry. If you want to view or change the agent settings for
auditing on a Windows computer after running the configuration wizard—or if you did not use the configuration wizard immediately after installation—you can
use the Agent Configuration Wizard.
To configure the agent settings for auditing:
1. Click Start > All Programs > Centrify Server Suite 2021.1 > Centrify Agent for Windows Configuration > Agent Configuration.
2. In the Centrify Agent Configuration window, locate the Centrify Auditing and Monitoring Service option, and click Settings.
The Centrify Auditing and Monitoring Service Settings window opens.
3. On the General tab, click Configure.
If your audit installation has video capture auditing enabled, you can configure the color depth of the sessions to control the size of data that must be
transferred over the network and stored in the database. A higher color depth increases the CPU overhead on audited computers but improves
resolution when the session is played back. A lower color depth decreases network traffic and database storage requirements, but reduces the
resolution of recorded sessions.
The default color quality is Low (8-bit).
5. Specify the offline data location and the maximum percentage of disk that the offline data file should be allowed to occupy, then click Next.
If the agent cannot connect to a collector, it saves session activity in the offline data location you specify until it can contact a collector.
The spool threshold defines the minimum percentage of disk space that should be available to continue auditing. It is intended to prevent audited
computers from running out of disk space if the agent is sending data to its offline data storage location because no collectors are available.
For example, if you set this threshold to 10%, auditing will continue while spooling data to the offline file location as long as there's at least 10% disk
space is available on the spool partition. When the disk space available reaches the threshold, auditing will stop until a collector is available.
The agent checks the spool disk space by periodically running a background process. By default, the background process runs every 15 seconds.
Because of the delay between background checks, it is possible for the actual disk space available to fall below the threshold setting. If this were to
occur, auditing would stop at the next interval. You can configure the interval for the background process to run by editing the
HKLM\Software\Centrify\DirectAudit\Agent\DiskCheckInterval registry setting.
6. Select the installation that the agent belongs to, then click Next.
7. If the computer where you’re configuring an agent belongs to multiple audit stores in the auditing installation, choose which audit store this agent will
connect to, then click Next.
8. In the Summary page, review your settings, then click Next.
The agent is now configured and enabled for auditing.
9. Click Finish to close the agent configuration wizard, then click Close to exit the Centrify Auditing and Monitoring Service Settings window.
Deciding to Install With or Without Joining the Computer to a Zone
Before you begin a silent installation, you should decide whether you will wait until later to join the computer to a zone, or join the computer to a zone as part
of the installation procedure.
If you install without joining a zone during installation:
See Installing silently by using the Microsoft Windows Installer for details about the registry settings that you can configure manually after the
installation finishes.
See Installing silently without joining a zone for details about performing the installation.
If you install and join a zone during installation:
You use a transform (MST) file that is provided with Server Suite to configure a default set of agent-specific registry keys during the silent installation.
You can optionally edit the MST file before performing the installation to customize agent-specific registry settings for your environment.
You can optionally use the agent configuration control panel or the registry editor to configure registry settings after the installation finishes.
See Installing silently by using the Microsoft Windows Installer for details about the registry settings that you can configure by editing the MST file.
See Installing silently by using the Microsoft Windows Installer for details about how to edit the MST file before you perform the installation.
See Installing and joining a zone silently for details about performing the installation.
Installing Silently Without Joining a Zone
This section describes how to install the agent silently without joining the computer to a zone. This procedure includes configuring registry settings manually
using the registry editor or a third-party tool.
Note:To install the agent and join the computer to a zone during installation, see Installing and joining a zone silently for more information.
1. Verify that the computers where you plan to install meet the prerequisites described in Verify prerequisites. If prerequisites are not met, the silent
2. If you are installing audit and monitoring service, verify that the following tasks have been completed:
3. Configured and applied the Centrify DirectAudit Settings group policy that specifies the installation name.
To install the Centrify Agent for Windows silently without joining the computer to a zone:
2. Run the installer for the Centrify Agent for Windows package. For example:
msiexec /qn /i "Centrify Agent for Windows64.msi"
By default, none of the services are enabled.
3. Use the registry editor or a configuration management product to configure the registry settings for each agent.
For example, under HKEY_LOCAL_MACHINE\Software\Centrify\DirectAudit\Agent, you could set the DiskCheckThreshold key to a value other than the
default value of 10%.
To install the Centrify Agent for Windows and add a computer to a zone during installation:
1. Prepare a computer account in the appropriate zone using Access Manager or the PowerShell command New-CdmManagedComputer.
2. You will use the default transform file Group Policy Deployment.mst in Step 3 to update the MSI installation file so that the computer is joined to the zone
in which it was pre-created in Step 1. You can optionally modify Group Policy Deployment.mst to change or add additional registry settings during
installation.
If you want to edit Group Policy Deployment.mst to change or add additional registry settings and have not yet done so, edit it now as described in
Installing silently by using the Microsoft Windows Installer.
In order for the computer to join the zone from Step 1, the Group Policy Deployment.mst file must specify the GPDeployment property with a value of 1.
msiexec /i "Centrify Agent for Windows64.msi" /qn TRANSFORMS="Group Policy Deployment.mst"
Installing and Joining a Zone Silently
This section describes how to install the agent and join the computer to a zone at the same time. The procedure described here includes the following steps in
addition to executing the MSI file:
You first prepare (pre-create) the Windows computer account in the appropriate zone.
You execute an MST file together with the MSI file to join the computer to a zone and configure registry settings during the installation.
Installing silently by Using the Microsoft Windows Installer
If you want to perform a “silent” (also called unattended) installation of the Centrify Agent for Windows, you can do so by specifying the appropriate
command line options and Microsoft Windows Installer (MSI) file to deploy. You must execute the commands on every Windows computer that you want to
audit.
You can also use silent installation commands to automate the installation or upgrade of the Windows agent on remote computers if you use a software
distribution product, such as Microsoft System Center Configuration Manager (SCCM), that enables you to run commands remotely to deploy software
packages. However, only the command-line instructions are covered in this guide.
Configuring Registry Settings
When you perform a silent installation, several registry settings specific to the agent are configured by the default MSI file. In addition, a default transform
(MST) file is provided for you to use if you join the computer to a zone as part of the installation procedure. When executed together, the default MSI and MST
files ensure that the computer is joined to a zone, and that a default set of agent-specific registry keys is configured.
If your environment requires different or additional registry settings, you can edit the MST file before performing an installation. Then, when you execute the
MSI and MST files to perform an installation, your customized registry settings are implemented. For details about how to edit the MST file, see Editing the
default transform (MST) file.
Note:If you do not join the computer to a zone during installation, you do not use the MST file. In this situation, you can create or edit registry keys
manually after the installation finishes by using the , or the registry editor.
The following table describes the agent-specific registry settings that are available for you to configure during installation (by using the MST file) or after
installation (by using the or the registry editor). Use the information in this table if you need to configure registry settings differently than how they are
configured by the default MSI and MST files. Keep the following in mind as you review the information in the table:
The default MSI file is named Centrify Agent for Windows64.msi, and is located in the Agent folder in the Centrify download location.
The default MST file is named Group Policy Deployment.mst, and is located in the Agent folder in the Centrify download location.
All of the settings in the following table are optional, although some are included in the default MSI and MST files so that they are configured when the
MSI and MST files execute during an installation.
Settings that are included in the default MSI and MST files are noted in the table.
Some settings are environment-specific, and therefore do not have a default value. Others are not environment-specific, and do have a default value.
The settings described in the table are located in the MSI file’s Property table.
The Setting column shows both the property name in the MSI file, and the name (in parentheses) of the registry key in the Windows registry.
Specifies the color depth of sessions recorded by the agent. The color depth affects the resolution of
the activity recorded and the size of the records stored in the audit store database when you have video
capture auditing enabled. You can set the color depth to one of the following values: 0 to use the native
Auditing and REG_MAX_FORMAT color depth on an audited computer. 1 for a low resolution with an 8-bit color depth 2 for medium
Monitoring (MaxFormat) resolution with a 16-bit color depth (default) 4 for highest resolution with a 32-bit color This setting
is included in the default MSI file. In the registry, this setting is specified by a numeral (for
example, 1). In the MSI file Property table, it is specified by the # character and a numeral (such as #1).
Specifies the minimum amount of disk space that must be available on the disk volume that contains
the offline data storage file. You can change the percentage required to be available by modifying this
registry key value. This setting is included in the default MSI file. In the registry, this setting is
Auditing and REG_DISK_CHECK_THRESHOLD
specified by a numeral (for example, 1). In the MSI file Property table, it is specified by the # character
Monitoring (DiskCheckThreshold)
and a numeral (such as #10). The default value is 10, meaning that at least 10% of the disk space on the
volume that contains the offline data storage file must be available. If this threshold is reached and
there are no collectors available, the agent stops spooling data and audit data is lost.
Specifies the offline data storage location. The folder location you specify will be where the agent
saves (“spools”) data when it cannot connect to a collector. This setting is not included in the
Auditing and
REG_SPOOL_DIR (SpoolDir) default MSI file. To use it, you must edit the default transform (MST) file so that it is processed
Monitoring
together with the MSI file during installation, or create it manually in the registry after the installation
finishes.
Specifies the unique global identifier (GUID) associated with the installation service connection point.
Auditing and REG_INSTALLATION_ID This setting is not included in the default MSI file. To use it, you must edit the default
Monitoring (InstallationId) transform (MST) file so that it is processed together with the MSI file during installation, or create it
manually in the registry after the installation finishes.
Auditing and Specifies what level of information, if any, is logged. Possible values are: off information warning error
REG_LOG_LEVEL_DA (LogLevel)
Monitoring verbose This setting is included in the default MSI file. The default value is information.
Specifies which users have rescue rights. Type user SID strings in a comma separated list. For
Authentication REG_RESCUEUSERSIDS example: user1SID,user2SID,usernSID This setting is not included in the default MSI file. To
& Privilege (RescueUserSids) use it, you must edit the default transform (MST) file so that the setting is processed together with the
MSI file during installation, or create it manually in the registry after the installation finishes.
Authentication REG_LOG_LEVEL_DZ Specifies what level of information, if any, is logged. Possible values are: off information warning error
& Privilege (LoggingLevel) verbose This setting is included in the default MSI file. The default value is information.
Specifies whether the computer is joined to the zone where the computer was pre-created. This
setting is used only during installation and does not have a corresponding registry key. Possible values
Authentication are: 0 - The computer is not joined to the zone. 1 - The computer is joined to the zone. This setting is
GPDeployment
& Privilege included in the default transform (MST) file. To use it, you must execute the MST file when you
execute the default MSI file. The default value is 1, meaning that the pre-created computer is joined to
the zone.
Editing the Default Transform (MST) File
The default transform file, Group Policy Deployment.mst, enables you to specify registry key settings that are different from the default settings that are
defined in the MSI file. You can use the Group Policy Deployment.mst file to customize a silent installation for a specific environment.
If you want to customize the agent settings for your environment, you should edit the Group Policy Deployment.mst file before executing the command to
perform a silent installation. If you want to use the default settings specified in the MSI file, you can skip this section and go directly to Installing silently from
the command line.
You must use the Orca MSI editor to edit the Group Policy Deployment.mst file. Orca is one of the tools available in the Windows SDK. If you do not have the
Windows SDK or Orca installed on your computer, you can download and install it from this location: http://msdn.microsoft.com/en-
us/library/aa370557(v=vs.85).aspx.
To edit the default MST file:
1. In the Agent folder in the Centrify download location, create a backup copy of the default Group Policy Deployment.mst file.
2. Open a Command Prompt window and execute the following command to launch Orca:
Orca.exe
3. In Orca, select File > Open and open the Centrify Agent for Windows64.msi file located in the Agent folder in the Centrify download location.
4. In Orca, select Transform > Apply Transform.
5. In Orca, navigate to the Agent folder in the Centrify download location and open Group Policy Deployment.mst. The file is now in transform edit mode,
and you can modify data rows in it.
6. In the Orca left pane, select the Property table. Notice that a green bar displays to the left of “Property” in the left pane. This indicates that the Property
table will be modified by the MST file. The right pane displays the properties that configure registry keys when you execute the command to install the
agent using the MSI file. Notice that the last property in the table, GPDeployment, is highlighted in a green box. This indicates that the GPDeployment
property will be added to the MSI file by the MST file.
7. In the right pane, edit or add properties as necessary to configure registry keys for your environment.
Property Description
Sets the MaxFormat registry key to specify the color depth of sessions recorded by the agent. The color depth
affects the resolution of the activity recorded and the size of the records stored in the audit store database when
you have video capture auditing enabled. In the MSI file Property table, you can set the color depth to one of the
REG_MAX_FORMAT
following values: #0 to use the native color depth on an audited computer. #1 for a low resolution with an 8-bit
color depth. #2 for medium resolution with a 16-bit color depth. #4 for highest resolution with a 32-bit color. The
default value is #1. To edit this property, double-click the Value column and type a new value.
Sets the DiskCheckThreshold registry key to specify the minimum amount of disk space that must be available on
the disk volume that contains the offline data storage file. In the MSI file Property table, the default value is #10,
REG_DISK_CHECK_THRESHOLD meaning that at least 10% of the disk space on the volume that contains the offline data storage file must be
available. You can change the percentage required to be available. To edit this property, double-click the Value
column and type a new value.
Sets the SpoolDir registry key to specify the offline data storage location. The folder location you specify will be
REG_SPOOL_DIR where the agent saves data when it cannot connect to a collector. To add a this property to the transform file,
right-click anywhere in the property table, then select Add Row.
Sets the InstallationId registry key to specify the unique global identifier (GUID) associated with the installation
service connection point. This property is not required if you are using the Installation group policy to identify the
REG_INSTALLATION_ID audit installation to use. If you are not using group policy to identify the audit installation, you can add a this
property to the transform file. Right-click anywhere in the property table, then select Add Row to add the
property and value to the file.
Sets the LogLevel registry key to specifies what level of information, if any, is logged. Possible values are: off
REG_LOG_LEVEL_DA information warning error verbose The default value is information. To edit this property, double-click the Value
column and type a new value.
8. After you have made the necessary modifications, select Transform > Generate Transform to save your modifications to the default MST file. Be
sure to save the MST file in the same folder as the MSI file. If the MST and MSI files are in different folders, the MST file will not execute when you
execute the MSI file.
The MST file is now ready to be used as described in Installing silently from the command line.
Installing Silently from the Command Line
If you want to perform a “silent” or unattended installation of the Centrify Agent for Windows, you can do so by specifying the appropriate command line
options and Microsoft Windows Installer (MSI) file to deploy.
Before running the installation command, you should verify the computers where you plan to install meet the prerequisites described in Verify prerequisites. If
the prerequisites are not met, the silent installation will fail. You should have also completed the following tasks:
Installed and configured the SQL Server management database and the SQL Server audit store database.
Installed and configured one or more collectors.
Configured and applied the Centrify DirectAudit Settings group policy that specifies the installation name.
You can use similar steps to install the Centrify Common Component using the Centrify Common Component64.msi file before you install the agent. If you
install the common component first, information about the agent installation is recorded in a log file for troubleshooting purposes. However, you are not
required to install the common component separately from the agent.
To install the Centrify Agent for Windows silently:
2. Run the installer for the Centrify Agent for Windows package for a 64-bit architecture with the appropriate command line options. For example, to install
the Centrify Common Component on a computer with 64-bit architecture, run the following command: msiexec /i "Centrify Common
Component64.msi" /qn If you want to enable both auditing and access control features on a computer with a 64bit operating system and use the values
defined in the Group Policy Deployment.mst file, you would run the following command: msiexec /i "Centrify Agent for Windows64.msi" /qn
TRANSFORMS="Group Policy Deployment.mst"
Installing from a Central Location by Using Group Policy
You can use a Group Policy Object (GPO) to automate the deployment of Centrify Agent for Windows. Because automated installation fails if all the
prerequisites are not met, be sure that all the computers on which you intend to install meet the requirements described in Verify prerequisites.
You can use similar steps to install the Centrify Common Component using the Centrify Common Component64.msi file before you install the agent. If you
install the common component first, information about the agent installation is recorded in a log file for troubleshooting purposes. However, you are not
required to install the common component separately from the agent.
In most cases, you can use the default agent settings defined in the Group Policy Deployment.mst transform file. If you want to modify the default settings
prior to installation, see the instructions in Installing silently by using the Microsoft Windows Installer.
To create a Group Policy Object for the deployment of Centrify Agents for Windows:
1. Copy the Centrify Agent for Windows64.msi and Group Policy Deployment.mst files to a shared folder on the domain controller or a location accessible
from the domain controller. When you select a folder for the files, right-click and select Share with > Specific people to verify that the folder is
shared with Everyone or with appropriate users and groups.
2. On the domain controller, click Start > Administrative Tools > Group Policy Management.
3. Select the domain or organizational unit that has the Windows computers where you want to deploy the Centrify Agent, right-click, then select Create
a GPO in this domain, and Link it here. For example, you might have an organizational unit specifically for Centrify-managed Windows computers.
You can create a group policy object and link it to that specific organizational unit.
4. Type a name for the new Group Policy Object, for example, Centrify Agent Deployment, and click O K.
5. Right-click the new Group Policy Object and click Edit.
6. Expand Computer Configuration > Policies > Software Settings.
7. Select Software installation, right-click, and select New > Package.
8. Navigate to the folder you selected in Step 1, select the Centrify Agent for Windows64.msi file, and click Open.
9. Select Advanced and click O K.
10. Click the Modifications tab and click A d d.
11. Select the Group Policy Deployment.mst file, click Open, and click O K.
12. Close the Group Policy Management Editor, right-click the Centrify Agent Deployment group policy object, and verify that Link Enabled is selected.
By default, when computers in the selected domain or organizational unit receive the next group policy update or are restarted, the agent will be deployed and
the computer will be automatically rebooted to complete the deployment of the agent.
If you want to test deployment or deploy immediately, you can open a Command Prompt window to log on to a Windows client as a domain administrator and
force group policies to be updated immediately by running the following command:
gpupdate /force
After installation, all of the registry settings that were specified in the MSI and MST files are configured. If you need to change any of the default agent
settings, open the DirectAudit Agent Control Panel or the Registry Editor.
For more information about how to configure and use Group Policy Objects, see the documentation on the Microsoft Windows website.
Enabling or Disabling Auditing on Windows Computers
You enable or disabling auditing for a Windows computer by adding or removing the audit and monitoring service from the agent configuration.
To enable auditing on a Windows computer:
Use the Agent Configuration wizard to configure the Centrify Agent for Windows to connect to the Centrify Audit & Monitoring Service.
The agent configuration wizard runs automatically after you've installed the Centrify Agent for Windows.
To disable auditing on a Windows computer:
In the Centrify Agent Configuration window, select Centrify Audit & Monitoring Service and click Remove.
To enable or disable video capture editing for an entire installation, see Enabling or disabling video capture auditing . To enable or disable auditing on a per-
user basis you can use a group policy and the audited user list and non-audited user lists. For details, see the Group Policy Guide.
Enabling or Disabling Auditing on Linux and UNIX Computers
After you install the agent, you can enable auditing with the dacontrol command. The dacontrol command links all shells to the cdash shell wrapper by way of
NSS. When a user opens a terminal, cdash is automatically loaded instead of the user’s shell, then cdash loads the appropriate shell for the user and begins
auditing the session.
You can also choose to enable video capture editing for an installation but disable it for specific computers. You disable or enable video capture auditing for a
specific computer or set of computers by using group policy settings or by modifying the agent.video.capture setting. For details, see the Group Policy Guide
or the Configuration and Tuning Reference Guide.
Shell or Terminal Window Auditing
To enable auditing on a Linux or UNIX computer:
1. Log on as a user with root privileges.
2. Run dacontrol with the -e option:
dacontrol -e
3. Run dacontrol again to verify that auditing has been enabled or run dainfo.
For example, the output of the dacontrol command shows something like this:
dacontrol --query
This machine has been configured through group policy to use installation 'DefaultInstallation'
DirectAudit NSS module: Active
DirectAudit is not configured to audit individual commands.
When you enable auditing, the NSS module shows as active. You can also see if auditing is enabled or not for a system in the Audit Manager console.
After you enable auditing on a Linux or UNIX computer, you can control whether the auditing of shell activity applies for all users or for selected users by using
role assignments. If auditing is enabled and the agent is not running, users with an active role assignment that requires logging are not allowed to log in.
For more information about configuring and assigning roles, see the Administrator’s Guide for Linux and UNIX.
To disable auditing on a Linux or UNIX computer:
2. Run dacontrol with the -d option or the --disable option:
dacontrol -d
dacontrol --disable
3. Run dacontrol again to verify that auditing has been disabled or run dainfo.
For example:
dacontrol --query
This machine has been configured through group policy to use installation 'DefaultInstallation'
DirectAudit NSS module: Inactive
DirectAudit is not configured to audit individual commands
When you disable auditing, the NSS module shows as inactive. You can also see if auditing is enabled or not for a system in the Audit Manager console.
Linux Desktop Auditing
In addition to shell auditing, for some Linux systems you can also enable desktop auditing. When desktop auditing is enabled, the user's entire screen is
continuously monitored to record all graphical interactions. More specifically, desktop auditing captures the following:
The application name and window title when the user switches the focus to that application. For example, if a user opens a web browser or a terminal
window.
Changes to the application window title that currently has focus. For example, if a user opens a web browser and goes to a new web page, desktop
auditing records the title of a web page.
The supported platforms for Linux desktop auditing are as follows:
RHEL 6, 7, and 8 with GNOME v3

CentOS 6, 7, and 8 with GNOME v3
Linux sessions must be running X as the primary display manager (not Wayland).
Linux desktop auditing requires shell session auditing.
To enable desktop auditing on a Linux computer:
2. Run dacontrol with the -x option or the --desktop-audit option:
dacontrol -x
dacontrol --desktop-audit
To enable both shell and desktop auditing at the same time, use both the -e and -x options:
dacontrol -e -x
3. Run dainfo to verify that desktop auditing has been enabled.
For example, the relevant information from the dainfo command looks like this:
Pinging adclient: adclient is available

Daemon status: Online
Current installation: 'DirectAudit' (configured locally)
Current collector: test.acme.com:5063:HOST/test.acme.com@acme.com
DirectAudit NSS module: Active
... DirectAudit desktop auditing: Enabled
User (root) audited status: Yes
When you enable auditing, the desktop auditing module shows as Enabled. You can also see if auditing is enabled or not for a system in the Audit
Manager console.
To disable desktop auditing on a Linux computer:
2. Run dacontrol with the -z option or the --no-desktop-audit option:
dacontrol -z
dacontrol --no-desktop-audit
3. Run dainfo to verify that desktop auditing has been disabled.
For example, the relevant information from the dainfo command looks like this:

Current installation: 'DirectAudit' (configured locally)

Current collector: test.acme.com:5063:HOST/test.acme.com@acme.com
DirectAudit NSS module: Inactive
... DirectAudit desktop auditing: Disabled
User (root) audited status: No
When you disable auditing, the desktop auditing module shows as Disabled. You can also see if auditing is enabled or not for a system in the Audit
Manager console.
Installing an Centrify Agent for Unix/Linux
You can install the auditing services for Linux or UNIX computers interactively the agent installation script, install.sh. If you want to run the installation script
silently or use a native package manager to install UNIX agents, see Installing the UNIX agent on remote computers.
The steps in this section describe how to install interactively using the install.sh script, which automatically installs platform specific software packages and
invokes the proper installation mechanism and options for a computer’s operating system.
To install the agent using the installation script:
2. Mount the cdrom device using the appropriate command for the local computer’s operating environment, if necessary.
Note:If you are not using the CD, verify the location and go on to the next step.
3. Change to the appropriate directory.
For example, to install on an AIX computer from the Centrify CD or ISO file, change to the UNIX directory:
cd Agent_Unix22
4. Run the installer and respond to its questions:
./install.sh
If there is an installation with the name DefaultInstallation, the UNIX agent uses it by default. If you are using an installation with a name other than
DefaultInstallation, you must identify the installation by using dacontrol or group policy after installing the agent. For more information, see Checking
the status of the UNIX agent.
5. After installing the package, use dainfo to verify that the agent is installed and running. You should see output similar to the following that indicates the
agent is Online:
Current installation: 'PistolasSF' (configured locally)
Current collector: DC2008r2-LG.pistolas.org:5063:HOST/dc2008r2-lg@PISTOLAS.ORG ...
If the output of dainfo indicates that the agent is Offline or that auditing is not enabled, verify your network connections and try restarting the auditing
service or run the command to enable auditing manually as described in Enabling or disabling auditing on Linux and UNIX computers.
You must adjust the disk space requirements higher if you allocate a large amount of offline storage to use when none of the collectors servicing the audit
store can be reached. This and other parameters are in a text file named centrifyda.conf in /etc/centrifyda on each audited computer that has the UNIX agent
installed. For more information about setting configuration parameters, see Configuring the UNIX agent off-line database. For information about all of the
configuration parameters available to customize auditing, see the Configuration and Tuning Reference Guide.
Enabling or Disabling Video Capture Auditing
In most cases, you decide whether to enable video capture auditing when you create a new installation. You can, however, choose to enable or disable video
capture auditing for an installation at any time. For example, you might enable full video capture auditing of user activity during your initial deployment and
later find that you are capturing user activity that is of no interest or requires too much database management to store. Conversely, you might initially decide
not to enable video capture and later discover that you want to record complete information about user activity when users run privileged commands or open
certain applications.
You can also choose to enable video capture editing for an installation but disable it for specific computers. You disable or enable video capture auditing for a
specific computer or set of computers by using group policy settings or by modifying the agent.video.capture setting. For details, see the Group Policy Guide
or the Configuration and Tuning Reference Guide.
For information about enabling or disabling auditing on Windows or Linux/UNIX computers, see Enabling or disabling auditing on Windows computers and
Enabling or disabling auditing on Linux and UNIX computers
To enable or disable video capture auditing for an installation:
1. In the Audit Manager console, right-click the installation name, then select Properties.
2. Click the Audit Options tab.
3. Select Enable video capture auditing of user activity if it is not selected to start capturing a visual record of all user activity when users perform
tasks using a role that is configured to be audited.
Deselect this option to stop all video capture auditing. If you disable video capture auditing, you will not be able to replay session activity.
4. Click O K or Apply.
Installing Additional Audit Manager or Audit Analyzer Consoles
If you need to make Audit Manager or Audit Analyzer consoles available to other users, you can install additional consoles on other computers. For example,
install Audit Analyzer on computers used by auditors in your organization.
Checklist for Auditing Systems Outside of Active Directory
Here is the overall process for auditing a computer that isn't joined to Active Directory, including links to documented procedures.
Step
Actions Details
#
Create the audit installation
For the audit store that includes the collector that you will enroll to the Privileged Access
Service, edit the audit store scope so that it includes the following: The site or subnet that the
1 Creating a new installation
collector is in The IP address or subnet of the system to be audited (the one that isn't in Active
Directory)
Add the audit installation to the Admin Portal and enable auditing
Install a connector on a Windows computer in the Active Directory domain Note: For now, do "How to install a connector" in the Privileged
2
not install a connector on the same computer as a collector. Access Service help (docs.centrify.com)
"Enabling auditing for remote sessions" in the

3 In the Admin Portal, enable auditing for the audit installation. Privileged Access Service help
(docs.centrify.com)
Verify the connector status in the Admin Portal.

Note: If your deployment is across multiple Active Directory forests or you have multiple
DirectAudit installations, your deployment will include multiple cloud connectors. In this kind
"Reference content - Connector configuration
of deployment, you should configure each non-Active Directory system to use only the cloud
4 program" in the Privileged Access Service help
connectors that are in the same Active Directory forest as the desired DirectAudit installation.
(docs.centrify.com)
You can configure which connectors should be used in the system's Connector settings in the
Admin Portal. For details, see the "Selecting the connectors to use" topic in the Privileged
Access Service help (docs.centrify.com).
Configure the collector
On the computer where the collector is or will be, install the Centrify Client and enroll the "Installing and using the Centrify Client for
5 computer in the Privileged Access Service. The collector needs to be joined to Active Directory Windows" in the Privileged Access Service help
and enrolled in the Privileged Access Service. (docs.centrify.com)
Install a new collector or reconfigure an existing collector so that the collector receives audit
6 Configure the audit collector service
data according to the cloud settings.
Configure the computer to be audited
"Installing and using the Centrify Client for

Windows" in the Privileged Access Service help
(docs.centrify.com) "Enrolling and managing
computers using Centrify Client for Linux" in the
7 In the Admin Portal, download the Centrify Client installers and get an enrollment code
Privileged Access Service help
(docs.centrify.com) "Enrolling a computer" in the
(docs.centrify.com)
"Admin Portal administrative rights" in the

In the Admin Portal, make sure that the user account you'll use to run the installer has the
8 Privileged Access Service help
permissions to enroll the system.
(docs.centrify.com)
On the computer to be audited, make sure that its
Step
Actions Details
#
On the computer to be audited, make sure that its DNS setting are set so that it can contact DNS settings are set so that it can contact the
9
and be contacted by the collector computer. collector computer by its fully qualified domain
name (FQDN).
"Installing and using the Centrify Client for

Windows" in the Privileged Access Service help
(docs.centrify.com) "Enrolling and managing
10 Install the client and enroll the computer in the Privileged Access Service.
computers using Centrify Client for Linux" in the
(docs.centrify.com)
In the Admin Portal, go to Resources > Systems to

11 In the Admin Portal, verify the enrollment.
verify the enrollment status.
"Downloading the audit packages for the Centrify

Install the audit client package(s): Windows: Install the Windows audit package. Linux: First
12 Clients" in the Privileged Access Service help
install the OpenSSL package, and then install the Linux audit package..
(docs.centrify.com)
13 In Audit Manager, verify that the computer is being audited. Managing audited computers and agents
Auditing Systems That are Inside a DMZ
If you have Windows or UNIX/Linux systems that are deployed inside of a networking DMZ, you can audit those systems without having to set up a separate
audit installation.
Organizations often use a DMZ to host a group of systems in a section of the corporate network in between the intranet and the public internet access.
Firewall settings define the perimeter of the DMZ; the firewall helps limit access to internal networks from the outside network.
In order to audit systems inside of a DMZ, the following must be true for your deployment:
All the Windows or UNIX/Linux systems in the DMZ are joined to the DMZ domain (for example, acme.dmz).
You've already set up the audit installation in your main domain for your organization (for example, acme.corp) and you're auditing systems in that
domain.
The SQL Server that hosts the audit databases is also joined to the main domain.
There's either no Active Directory trust between the main and DMZ domains or there's a one-way trust where the DMZ domain trusts the main domain
(for example, acme.dmz trusts acme.corp).
All the audit administrator and auditor accounts belong to the main domain.
Before you go to set up auditing on DMZ systems, be sure to do the following:
Deploy at least one audit collector on a system that's joined to the DMZ domain. This is because an audited system can only look for audit collectors in
its own forest.
Configure the SQL Server to use mixed-mode authentication. This is because a collector in a DMZ cannot authenticate with SQL Server in the main
domain using Windows authentication.
Configure the necessary firewall exceptions for the SQL Server deployed in the main domain so that the audit collector in the DMZ can connect to the
SQL Server. This includes the firewall exceptions for the SQL Server listener port as well as other ports, such as UDP 1434 (which is used by the SQL
browser service).
To audit systems in a DMZ:
1. Prepare the audit store:
1. Set up an audit store that contains the audited data for the systems in the DMZ. You can either create a new audit store or modify an existing one
so that the audit store scope includes the sites or subnets of the systems in the DMZ.
2. Add a new audit store database to the DMZ audit store and mark the database as active.
For more information, see Creating the first audit store.
2. Prepare the SQL authentication account:
1. In Audit Manager, right-click the audit store database that you just created and select Properties.
2. In the Advanced tab, under the Allowed incoming collectors, click A d d.
3. For the authentication, select SQL Server authentication. Select an existing account or click the list to create a new SQL Login account.
This SQL Login account is what the collectors in the DMZ domain will use to authentication with the SQL Server in the main domain. As a best practice,
it's recommended to create a dedicated incoming collector account for all collectors in the DMZ.
3. Publish the audit installation information to the DMZ domain:
If there's a one-way trust between the DMZ and main domains:

1. In Audit Manager, right click the installation name and click Properties.
2. In the Publication tab, click A d d.
3. Select an OU or container in the DMZ domain to which you'll publish the audit installation information. Click O K to continue, and click O K
again to close the dialog box and publish the audit installation information to the DMZ.
For more information, see Publishing installation information.
If there's no trust between the DMZ and main domains:

1. In Audit Manager, right-click the installation name and click Properties.
2. In the Publication tab, click Export to export the audit installation information to an LDIF file.
3. Provide the LDIF file to the Active Directory administrator of the DMZ domain and request that they manually import the file into an OU or
container in the DMZ domain. They can import the LDIF file using the LDIFDE.exe utility.
For more information, see Exporting installation information.
4. Install a collector on at least one Windows system in the DMZ:
1. Run the Collector Configuration wizard, and select the audit installation and specify the port number.
2. In the Authentication type screen, select SQL Server authentication and enter the credentials for the SQL authentication account that you
created earlier.
3. Click Test Connection to ensure that the credentials work and the SQL Server is reachable.
4. Finish the rest of the wizard. If there are any warnings when validating the permissions, you can safely ignore them.
If you login to the collector computer as a user from your DMZ domain, that user will most certainly not have the permissions to connect to the audit
installation and, as a result, the Collector Configuration wizard (which runs in context of the logged-in user) may fail to validate certain permissions and
show warning messages instead.
For details about configuring a collector, see Installing the audit collectors.
5. Install and configure the agent on the systems in the DMZ.
For details, see Installing the Centrify Agent for Windows.
Managing an Installation
This section describes how to secure and manage an audit installation after the initial deployment of Centrify software. It includes tasks that are done by
users assigned the Master Auditor role for an installation and users who are Microsoft SQL Server database administrators.
Topics available:
Securing an installation
Configuring selective auditing
Configuring agents to prefer collectors
Audit license enforcement
Enabling audit notification on Windows
Preventing users from reviewing or deleting sessions
Adding an installation
Publishing installation information
Removing or deleting an installation
Managing audit store databases
Managing audit stores
Managing the audit management database
Maintaining database indexes
Managing collectors
Managing audited computers and agents
Delegating administrative permissions
Managing audit roles
Securing an Installation
For production deployments, you can take the following steps to secure the installation:
Use the Installation group policy to specify which installation agents and collectors are part of. By enabling the Installation group policy you can prevent
local administrators from configuring a computer to be part of an unauthorized installation.
Configure a trusted group of collectors to prevent a hacker from creating a rogue collector to collect data from agents.
Configure a trusted group of agents to prevent a hacker from performing a Denial of Service attack on the collector and database by flooding a collector
with bogus audit data.
Encrypt all data sent from the collector to the database.
Before you can follow these steps to secure an installation, you must have access to an Active Directory user account with permission to create Active
Directory security groups, enable group policies, and edit Group Policy Objects.
To secure an installation using Windows group policy:

2. Expand the forest and domains to select the Default Domain Policy object.
4. Expand Computer Configuration > Policies > Centrify Audit Settings, then select Common Settings.
5. Double-click the Installation policy in the right pane.
8. Click O K to close the Installation properties.
Securing an Audit Store with Trusted Collectors and Agents
By default, audit stores are configured to trust all audited computers and collectors in the installation. Trusting all computers by default makes it easier to
deploy and test auditing in an evaluation or demonstration environment. For a production environment, however, you should secure the audit store by
explicitly defining the computers the audit store can trust.
You can define two lists of trusted computers:
Audited computers that can be trusted.

Collector computers that can be trusted.
To secure an audit store:
1. Open the Audit Manager console.
2. Expand the installation and Audit Stores nodes.
3. Select the audit store you want to secure, right-click, then select Properties.
5. Select Define trusted Collector list, then click A d d.
6. Select a domain, click O K, then search for and select the collectors to trust and click O K to add the selected computers to the list.
Only the collectors you add to the trusted list are allowed to connect to the audit store database. All other collectors are considered untrusted and
cannot write to the audit store database.
7. Select Define trusted Audited System list, then click A d d.
8. Select a domain, click O K, then search for and select the audited computers to trust and click O K to add the selected computers to the list.
Only the audited computers you add to the trusted list are allowed to connect to the trusted collectors. All other computers are considered untrusted
and cannot send audit data to trusted collectors.
9. Click O K to close the audit store properties dialog box.
The following example illustrates the configuration of trusted collectors and trusted audited computers.
In this example, the audit store trusts the computers represented by P, Q, and R.Those are the only computers that have been identified as trusted collectors
in the audit store Properties. list. The audit store has been configured to trust the audited computers represented by D, E, and F. As a result of this
configuration:
Audited computers D, E, and F only send audit data to the trusted collectors P, Q, and R.
Trusted collectors P, Q, and R only accept audit data from the trusted audited computers D, E, and F.
The audit store database only accepts data for its trusted collectors P, Q, and R, and therefore only stores audit data that originated on the trusted
audited computers D, E, and F.
Disabling a Trusted List
After you have added trusted collectors and audited computers to these lists, you can disable either one or both lists at any time to remove the security
restrictions. For example, if you decide to allow auditing data from all audited computers, you can open the audit store properties, click the Advanced tab, and
deselect the Define trusted Audited System list option. You don’t have to remove any computers from the list. The audit store continues to only accept
data from trusted collectors.
Using Security Groups to Define Trusted Computers
You can use Active Directory security groups to manage trusted computer accounts. For example, if you create a group for trusted audited computers and a
group for trusted collectors, you can use those groups to define the list of trusted collectors and audited computers for the audit store. Any time you add a
new computer to one of those groups, thereafter, it is automatically trusted, without requiring any update to the audit store properties.
https://delinea.com/

Server Suite 2022.x

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Server Suite 2022.x

Uploaded by

Copyright:

Available Formats

Server Suite

Welcome to Server Suite 253

Welcome to Server Suite 254

Install and Upgrade 255

Using this Planning and Deployment Guide 256

Planning Deployment for an Enterprise 257

Deployment Process Overview 270

Planning Organizational Units and Security Groups 278

Using a Native Package Installer 300

Installing the Agent on Solaris Systems 310

Planning to Use Server Suite Zones 315

Preparing To Migrate Existing Users And Groups 321

Provisioning New User and Group Profiles After Migration 339

Validating Operations After Deploying 350

Migrating And Managing Service Accounts 366

Planning to Deploy in a Demilitarized Zone (DMZ) 372

Managing and Evolving Operations After Deployment 375

Permissions Required for Administrative Tasks 390

Supplemental Installation Notes 416

Mounting CIFS Shares 419

Known Issues 424

Using this Licensing Guide 432

How Delinea Licenses are Managed 433

Delinea License Management Tools 433

Using Delinea Licenses in FIPS Environments 434

Installing the Delinea Licensing Service 435

Installing the Licensing Report Wizard 436

Managing Licenses with the Licensing Service 437

Monitoring Centrify license Usage 440

Configuring Licensing Service Settings 441

Configuring and Viewing Licensing Service Logs 443

Creating Licensing Reports with the Licensing Report Wizard 444

Permissions Required to Generate a Licensing Report 444

Information Required to Produce the Licensing Report 444

Preparing to run the Licensing Report wizard 445

Running the Licensing Report Wizard 445

Preparing For An Upgrade 462

Upgrading the Operating System 463

Upgrading Computers Accessed by Multiple Users 464

Compatibility Between Versions of Delinea Software 465

Disabling Command-line Auditing 467

Upgrading Delinea Management Services on Windows Computers 468

Updating Administrative Components 470

Upgrading Components Interactively 473

Upgrading Auditing Components Silently on Windows 474

Upgrading Auditing Infrastructure 475

Unsupported Configurations 478

Updating Auditing-Related Databases 479

Updating Agents Out of Sequence 480

Upgrading Managed Computers 483

Configuring install.sh to Run Without User Interaction 484

Using the install.sh Shell Script to Update Packages 485

Upgrading Managed Mac OS X Computers 493

Compatibility for CentrifyDC-nis Package 497

Compatibility for CentrifyDC-krb5 Package 498

Upgrading Version-Dependent Packages 502

Working with Classic Zones After an Upgrade 503

Remove and Re-install Agent Features 507

Known Issues 508

RunAsRole Issues 512

Desktop with Elevated Privileges Issues 513

Configuration and Tuning Reference Guide 518

Controlling agent operations 520

Basic syntax used in configuration files 521