Re: Centrify profile de-provisioning & orphaned object removal - Part 2

Centrify profile de-provisioning & orphaned object removal - Part 2

By Centrify Contributor II on ‎02-02-2016 07:42 PM

Cleaning up orphaned profiles

While the various profile de-provisioning methods have been detailed in Part 1 of the article series, it cannot always be guaranteed that they have been followed when a user or group object with a UNIX profile is deleted from Active Directory.

 

For example, a user may be deleted using a console that does not have the Centrify Profile property page extension installed, or someone may have scripted a mass-pruning of objects without taking into account the de-provisioning of Centrify Zone objects relating to these users.

 

As a result, after having deployed Centrify in a production environment, chances are that some of the de-provisioned Active Directory users and groups have left behind their UNIX profiles in Centrify Zones; these profiles have in effect become orphaned. The SID that is referenced in the serviceConnectionPoint no longer exists in Active Directory, and as a result, the profile will no longer show up on any UNIX server where it originally was visible.

One may be tempted to conclude that all is well at this point; however, these orphan profiles can still cause problems: they will hinder attempts to provision new UNIX profiles that wish to use the UNIX login name or group name, that already has been claimed by an orphaned profile in the same Zone or Managed Computer. Orphaned profiles also increase the size of your Active Directory.

 

As in most scenarios, orphaned profiles no longer serve any purpose, you may want to get rid of them. The following methods exist to clean up orphaned UNIX profiles in Centrify Zones:

 

Detect and remove orphaned profiles using the Centrify DirectManage Access console

 

This method consists of several manual actions, and is therefor relatively time-consuming and not very scalable; This is best used for small environments where the volume of (de-)provisioning is low.

To manually detect and remove orphan profiles:

  • Open the Centrify DirectManage Access Manager
  • In the console window, right-click on the DirectManage Access Manager node in the left window pane, and select the Analyze... option from the context menu:
  • DMAM_Analyze.png
  • The Analyze Wizard will now appear. Check the box for the option named Orphan zone data objects and invalid data links. Optionally, you can also check Orphan role assignments if you've deleted users or groups that that were target of a Role Assignment in a zone, managed computer or computer role. Click Next to start the analysis.DMAM_Analyze_options.png
  • A progress indicator will appear. Wait until it has finished, and the Result Analysis window appears. Once finished, the Analyze Summary window will show you how many orphaned objects have been detected in Active Directory. Click on Finish to close the Analyze Wizard.
  • DMAM_Analyze_finished.png
  • Any detected orphan objects will be visible in the Analysis Results node in the left pane of the DirectManage Access Manager console. By right-clicking an orphaned object in this section, you can delete the object with Remove orphan profile, or to select Properties to see more details on the detected object, such as the location of the orphaned serviceConnectionPoint object in Active Directory.
  • DMAM_Analyze_Results.png

Note to be careful when removing profiles that have been identified as orphan from the Centrify Console, when the user or group object resides in a different Active Directory domain or forest. There's a time-out value when the DirectManage Access Manager console tries to resolve the user object referenced in a profile; once this timeout expires, and no domain controller in that domain that holds the user or group has been able to respond, the object may appear as orphaned. In these situations, it's important to double-check that the referenced user or group object really has been removed, and that this is not merely a communication issue between domain controllers in different domains/forests.

 

Script detection of orphaned profiles using PowerShell on Windows  

Centrify provides various toolboxes for larger environments, where a need exists to automate the task of detecting orphaned profiles.

 

To automate this task on Windows, Centrify provides a DirectControl PowerShell module, which is included on the installation media for the Centrify Server Suite consoles, and is an optional component during installation of DirectManage.

 

The Get-CdmUserProfile and Get-CdmGroupProfile CMDlets, part of the DirectControl PowerShell module, return objects, that have a property called IsOrphan with a Boolean as attribute value, and can thus be leveraged to identify stale UNIX profiles in a Centrify Zone or Managed Computer object.

 

For example, the following simplified script will enumerate all user profiles in a zone named "global", and print the UNIX login name if the profile is orphaned.

 

Import-Module Centrify.DirectControl.PowerShell
Import-Module ActiveDirectory
$CdmSourceZone = get-CdmZone -name "global"
[System.Collections.ArrayList]$arrayCdmUserProfiles = Get-CdmUserProfile -Zone $CdmSourceZone
# Process each user profiles in the array
foreach ($userProfile in $arrayCdmUserProfiles)
{
	if ( $userProfile.IsOrphan -eq $True) {
		$userLoginName = $userProfile.Name
		Write-Host ("Orphaned profile for login name {0} has been identified" -f $userLoginName )
	}
}

 

Any action to take can then be added to the script, for example remove the object, or email a zone administrator about the detected anomaly requiring further attention.

 

Note that Get-CdmUserProfile and Get-CdmGroupProfile will not time out as quickly as the console, and will result in much reduced chances of false positives for referenced user/group objects residing in other domains or forests.

 

Note further that the Security Identifier shows up as value of the .User.SID and .Group.SID attributes of CdmUserProfile and CdmGroupProfile objects respectively, but is not returned for orphaned profiles with these CMDlets.

 

Script detection of orphaned profiles using ADEdit on *NIX

To automate the task of detecting orphaned profiles on *NIX platform, Centrify provides the ADEdit command-line interface utility, that primarily is targeted for managing Centrify Zone objects in Active Directory.

 

As an example of how to perform a similar process as we did in the previous example on *NIX, the following simplified ADEdit script will enumerate all user profiles in a zone named "Global" that is stored in the Centrify OU of a domain named contoso.com, and prints the UNIX login name and SID values of any orphaned user profiles that it finds:

 

#!/bin/env adedit
package require ade_lib
set domain contoso.com
set zone_dn "CN=Global,CN=Zones,OU=Centrify,DC=contoso,DC=com"
bind $domain
proc find_orphan_users {zone_dn} {
	select_zone $zone_dn
	foreach ZONE_USER [get_zone_users] {
		select_zone_user $ZONE_USER
		set USER_SCP_DN [get_zone_user_field dn]
		select_object $USER_SCP_DN
		foreach keyword [get_object_field keywords] {
			set bits [split $keyword ':']
			if {[lindex $bits 0] == "parentLink"} {
				set USER_SID [lindex $bits 1]
			}
		}
		if { [catch {principal_from_sid $USER_SID}] } {
			set USER_LOGIN [get_zone_user_field uname]
			puts "Orphaned user profile detected with login name: $USER_LOGIN and SID: $USER_SID"
		}
	}
}
find_orphan_users $zoneDN

 

Compared to the PowerShell script, ADEdit provides a more low-level access to the Centrify Zone data; this becomes obvious when we look at how many extra steps are required to achieve the same results as with PowerShell:

 

To find out if a user profile is orphaned, the DistinguishedName of the serviceConnectionPoint object is first retrieved. The values of the keywords attribute of this object are read; if it contains any occurrence of parentLink, the accompanying SID value is stored in the variable USER_SID. The principal_from_sid function in ADEdit will normally retrieve the sAMAccountName@ActiveDirectoryDomainName value of the user object referenced with the SID.

When the user object with the specified SID can not be found, it will return an error. By placing it in a catch {} block, a more 'exit-code'-like behaviour is achieved: The result will be "0" if no error was encountered by principal_from_sid, and "1" if an error was found. These values are then used in an if condition to show output only if the user profile is orphaned.

 

Note that like the PowerShell script, the above snippet of ADEdit code only works on RFC2307 and Standard type zones, and contrary to the PowerShell script, is not multi-domain/forest aware.

To extend the above snippet of code to a production environment, all orphan user and group profiles in the entire domain or forest would need to be detected. This can be done by first enumerating all Zones in the domain or forest, and in each found zone, all managed computer objects would need to be enumerated. Each managed computer object in the zone should then be checked for orphaned user and group profiles, as well as each zone that was found.

 

If the action needs to be performed in an environment where multiple domains/forests are present, then the code will need to be modified accordingly, to be multi-forest/domain aware.

 

Conclusion

In small environments with a low user (de-)provisioning volume, manual profile de-provisioning is feasible. In bigger environments, automation is a must; clients usually chose UNIX or Windows platform for running scripts, based on the preference of their personnel.

As the above examples show, managing Centrify objects in PowerShell takes (in most cases) less steps than in ADEdit, which usually translates into needing less time to write the PowerShell script.

Also note that orphaned zone objects can be a real issue, that should not be ignored when (re-)designing the de-provisioning process.

 

The examples in this article should give you a fairly good impression on what options there are to detect orphan user profiles, and how to code automatic detection of these orphan profiles. The code snippets can form a solid basis for extension and adaptation in a production environment.

 

More comprehensive documentation on the DirectControl PowerShell CMDlets and ADEdit scripting tool is provided on the Centrify Server Suite DirectManage installation media.

 

Finally, Centrify Professional Services can be contracted for any custom scripting needs, when dealing with more complex, exotic or legacy deployments, for example advise when automating UNIX profile provisioning with Identity Lifecycle Management software products.

Comments
By Centrify Guru I
on ‎01-23-2019 11:55 AM

There's now a sample Powershell script provided when the Centrify PowerShell module is installed called RemoveAllOrphans located in C:\Program Files\Centrify\PowerShell\Centrify.DirectControl.PowerShell\Samples, that customers can run.  The script can be executed as a scheduled task to automate this task.

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel