Is it possible to dynamically set a user attribute based on membership in a group or does one really have to manually change all existing users and have a template with the attribute set to account for new users?
As in, if John is member of Pet Owners then treat John's (custom-)attribute hasPets set.
The (very specific) problem at hand is this:
We are using Sonicwall's (now DELL's) SRA appliance as VPN solution which integrates with AD. The appliance supports sending out one-time passwords via email but it only supports two ways of specifying where the email address it uses comes from:
- Let it dynamically assemble the address from the user's username and domain which were used to log into the appliance (
user@domain). - Specify an AD attribute to use which holds the email address, which can be one of a few pre-specified (e.g.
mail,pager, etc.) or a custom attribute.
Somewhere down the pipe those mails are eventually processed and the OTP gets sent out via SMS to the user trying to login to the system.
Earlier we used option 1) and let the appliance send the OTP emails to user@domain but with upgrading to a new appliance model and backend changes on our side all OTP emails should be sent to the very same email address.
What is not possible is to set a global email address directly inside the appliance, so it seems we have to use 2) and set an AD attribute to this new email address. Since VPN access is tied to an AD group I was hoping this could be done dynamically only for users who are members of those groups, or at least for all users in the domain.
Best Answer
The only approach I can think of would be to run a script to periodically scan your Active Directory and update the attribute you're interested in, based on the group membership of the account.
It's relatively easy to do with PowerShell, and you could run it as a scheduled task to keep things current.
The Scripting Guy has a blog entry that's pretty topical - Use the PowerShell AD Provider to modify user attributes. Use that to form the core of your script, slap some logic around it, and you're good to go.
In his example, he's fiddling with the
physicaldeliveryofficenameattribute, and uses theSet-ItemPropertycmdlet, combined with aFilterto switch the value of that attribute between Charlotte and Raleigh. You would probably not take that approach, but instead just use theSet-ItemPropertycmdlet to set to the attribute your Sonicwall/Dell checks to something, based on what group the user's in.