Unable to disable AD account, alternates that can be used

[ts_fpatterson (Fred Patterson)]

A customer has restrictions where various apps have issues or complexities when an account is disabled. Rather than having the account disable in a pre-hire or a termination lifecycle state, they needed ways to prevent user authentications.

One approach is to set the userWorkstations attribute in Active Directory to a workstation name that does not exist. Example a value of “NONE-PREHIRE”. By having this attribute set with one value of a workstation that shouldn’t ever exist, the user would be enabled so that various applications or processes may be able to aid in provisioning the account with various devices, etc, but the account would not be able to authenticate.

Another approach is to set an account expiration date in AD. Below is a transform example that sets the account expiration towards the end of the day of a specified date. It is from a static transform showing the variable for the expriationDate.

"expirationDate": {
            "type": "dateFormat",
            "attributes": {
                "inputFormat": "yyyy-MM-dd'T'hh:mm",
                "outputFormat": "EPOCH_TIME_WIN32",
                "input": {
                    "attributes": {
                        "input": {
                            "attributes": {
                                "input": {
                                    "attributes": {
                                        "values": [
                                            {
                                                "attributes": {
                                                    "attributeName": "TERMINATION_DT",
                                                    "sourceName": "PeopleSoft "
                                                },
                                                "type": "accountAttribute"
                                            },
                                            {
                                                "attributes": {
                                                    "value": "12/30/2099"
                                                },
                                                "type": "static"
                                            }
                                        ]
                                    },
                                    "type": "firstValid"
                                },
                                "inputFormat": "MM/dd/yyyy",
                                "outputFormat": "ISO8601"
                            },
                            "type": "dateFormat"
                        },
                        "expression": "+29h/h",
                        "roundUp": false
                    },
                    "type": "dateMath"
                }
            }
        },

A velocity script would be needed to exclude the default value if the date is not set in the source. As seen below, the 1574 starting date would be around November of 2099.

!$expirationDate.startsWith('1574')

One other method would be to move the User to an OU with a Deny Logon Policy. Moving the user to an Organizational Unit (OU) that has a Group Policy Object (GPO) denying logon rights by creating a GPO with settings that deny logon locally and via Remote Desktop Services, and link it to an OU. Move the user to that OU.

While these are alternatives, my preference would be to find ways where accounts could be set to disabled or have multiple combinations of the above. Not only does SailPoint handle this logic built into lifecycles. It also allows for a SailPoint administrator to easily enable an account or disable it manually where needed.

[agutschow (Alicia Gutschow)]

We have done things like this before. Sometimes we have had requirements to set and unset values like this automatically. We have used transforms to calculate identity attributes which we updated with attribute sync to active directory. We have set/unset the values through before provisioning rules. Another idea we have done is set an extension attribute with the lifecycle state, then we could use after modify PowerShell to write custom logic needed for state changes.