Article

fweigert's picture
article
Reads:

6062

Score:
4.142855
4.1
7
 
Comments:

0

Backup, remove and restore group memberships or copy them between users with an IDM loopback policy

(View Disclaimer)

Two policies I came up with to make some of our daily admin tasks easier.

Policy 1:

Backup, remove and restore group memberships when accounts are disabled/enabled.

In our organization user accounts have to be kept around in connected systems for several months (in the IDV forever), either because of pending investigations
or for the chance the employee/consultant returns. In the meantime even though disabled the user remains in email distribution lists (creating bounced messages)
and security groups (raising eye browses with auditors).Simply removing all group memberships is a piece of cake with IDM but what if the employee’s replacement 4 weeks later needs to be modeled after the departed user and all Group memberships are gone?

In order to simplify this process I created a policy that upon a user being disabled copies all the user's group memberships to a backup attribute. This can be any existing multi valued attribute with case ignore syntax or a new one, in this example the attribute is called pgwIDVGroupBackup. Once the memberships are copied the policy wipes out the user's Group Membership and security equals attributes for these groups.

The user is now removed from all groups and distribution lists, even in MS Exchange if you synch your groups with AD.

Whoever has to create a new account to be modeled after this user can now simply look at the backup attribute to see what groups the former employee belonged to. We use eGuide for this (fastest eDirectory lookup tool on the planet) but ConsoleOne or iManager will do also.

If for whatever reason the user is being enabled again the policy does the reverse. It looks at the backup attribute and restores all the group memberships.

In our environment this policy runs in the subscriber event transform of our loopback driver on the IDV, naturally "login disabled" needs to be added to the driver filter.

Here is the policy:

<?xml version="1.0" encoding="UTF-8"?><policy>
	<rule notrace="true">
		<description>Backup Groupmemberships and remove them</description>
		<conditions>
			<or notrace="true">
				<if-op-attr mode="nocase" name="Login Disabled" notrace="true" op="changing-to">TRUE</if-op-attr>
			</or>
		</conditions>
		<actions>
			<do-set-local-variable name="pgwmembership" notrace="true" scope="policy">
				<arg-node-set>
					<token-src-attr class-name="User" name="Group Membership" notrace="true"/>
				</arg-node-set>
			</do-set-local-variable>
			<do-for-each notrace="true">
				<arg-node-set>
					<token-local-variable name="pgwmembership" notrace="true"/>
				</arg-node-set>
				<arg-actions>
					<do-add-src-attr-value class-name="User" name="pgwIDVGroupBackup" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-add-src-attr-value>
					<do-remove-src-attr-value class-name="User" name="Group Membership" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-remove-src-attr-value>
					<do-remove-src-attr-value class-name="User" name="Security Equals" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-remove-src-attr-value>
				</arg-actions>
			</do-for-each>
		</actions>
	</rule>
	<rule notrace="true">
		<description>Restore Group Memberships</description>
		<conditions>
			<and notrace="true">
				<if-op-attr mode="nocase" name="Login Disabled" notrace="true" op="changing-to">FALSE</if-op-attr>
			</and>
		</conditions>
		<actions>
			<do-set-local-variable name="pgwmembership" notrace="true" scope="policy">
				<arg-node-set>
					<token-src-attr class-name="User" name="pgwIDVGroupBackup" notrace="true"/>
				</arg-node-set>
			</do-set-local-variable>
			<do-for-each notrace="true">
				<arg-node-set>
					<token-local-variable name="pgwmembership" notrace="true"/>
				</arg-node-set>
				<arg-actions>
					<do-add-src-attr-value class-name="User" name="Group Membership" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-add-src-attr-value>
					<do-add-src-attr-value class-name="User" name="Security Equals" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-add-src-attr-value>
					<do-remove-src-attr-value class-name="User" name="pgwIDVGroupBackup" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-remove-src-attr-value>
				</arg-actions>
			</do-for-each>
		</actions>
	</rule>
</policy>


Policy 2:

Model employee after existing employee.

Now that we know how to copy group memberships between attributes it should be a piece of cake to do the same thing between different objects, right?
Modeling a new user after an existing user can be a painful process, especially if the existing user is in 50+ groups and you have to add these groups
to the new employee in Consoleone :-).

The next policy uses the same logic as Policy 1, it will look at the group membership of the selected existing user and then simply add group membership and security equals for all the groups it finds to the target user. It will not alter already existing group memberships on the target user.

In order to do this we need one more attribute (dn syntax), in our case called pgwModeledAfter. Again, this should be added to an aux class associated with your users

I simply built an iManager property book page that allows an Admin to add an existing user to the pgwModeledAfter attribute on a new user, the IDM policy does the rest.
Now a 10-20 minute task takes seconds and there is less of a chance for user (admin) error.

Here is the policy:

<?xml version="1.0" encoding="UTF-8"?><policy>
	<rule notrace="true">
		<description>Model Group Memberships after existing user</description>
		<conditions>
			<and notrace="true">
				<if-op-attr name="pgwModeledAfter" notrace="true" op="available"/>
				<if-op-attr name="pgwModeledAfter" notrace="true" op="changing"/>
			</and>
		</conditions>
		<actions>
			<do-set-local-variable name="pgwmembership" notrace="true" scope="policy">
				<arg-node-set>
					<token-src-attr class-name="User" name="Group Membership" notrace="true">
						<arg-dn>
							<token-op-attr name="pgwModeledAfter" notrace="true"/>
						</arg-dn>
					</token-src-attr>
				</arg-node-set>
			</do-set-local-variable>
			<do-for-each notrace="true">
				<arg-node-set>
					<token-local-variable name="pgwmembership" notrace="true"/>
				</arg-node-set>
				<arg-actions>
					<do-add-src-attr-value class-name="User" name="Group Membership" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-add-src-attr-value>
					<do-add-src-attr-value class-name="User" name="Security Equals" notrace="true">
						<arg-value>
							<token-local-variable name="current-node" notrace="true"/>
						</arg-value>
					</do-add-src-attr-value>
				</arg-actions>
			</do-for-each>
		</actions>
	</rule>
</policy>


We also run this policy in the Subscriber Event Transform of our IDV Loopback driver. "pgwModeledAfter" or whatever you name it needs to be added to the driver filter

Hope somebody might find this useful, our admins love it.

Cheers

Frank Weigert


Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.




User Comments

© 2013 Novell