Disabling SN account swhen AD account is moved to the disabled user OU

daniellethomson
Tera Expert

The OoB functionality to disable SN accounts if the corresponding AD user account is disabled works perfectly, except in our environment. Our current process is to move the accounts to another OU=disabled users. I looked at other options such as tracking the last refresh time of the account but we need a more immediate option. Is there a way the OoB script can be modified to disable the SN user account if the OU changes/if the account is no longer visible in the user OU?

1 ACCEPTED SOLUTION

Danielle,



I have a data source for each OU that I need to import even though they're all pulling the same attributes. In our environment, a user can move from one to another depending on their job role so, I need to capture all of this, right? The terms hit their own OU during that process and have to remain there for X amount of days based on corporate policy. So, I just pull that termed OU as it's own source and then run the script above.



When you do the imports this way, you can also get granular reporting on just that data source and you're also able to troubleshoot specific users and groups more effectively than doing one giant pull.


View solution in original post

18 REPLIES 18

That's correct. I do the import on that OU as normal and then let my script do the dirty work, or the cleanup work as it were.


Thanks I will try it out with our disabled user OU.


Mark Laucus
Giga Guru

I have the same challenge in disabling users



What I was planning on doing was creating another LDAP OU Definition using the OU where I have the disabled users.   Then I will create a separate data source utilizing the new LDAP definition utilizing the script such as mentioned above.  


Mark- Are you excluding the disabled user OU in your initial filter? Just want to understand the reasoning behind creating a separate OU definition and data source.


Danielle,



I have a data source for each OU that I need to import even though they're all pulling the same attributes. In our environment, a user can move from one to another depending on their job role so, I need to capture all of this, right? The terms hit their own OU during that process and have to remain there for X amount of days based on corporate policy. So, I just pull that termed OU as it's own source and then run the script above.



When you do the imports this way, you can also get granular reporting on just that data source and you're also able to troubleshoot specific users and groups more effectively than doing one giant pull.