viewpoint-particle

Author Topic: Confirming AD Group Modifications  (Read 3142 times)

Chris.Kubiak

  • Newbie
  • *
  • Posts: 5
Confirming AD Group Modifications
« on: March 07, 2014, 07:16:17 am »
Creating a script that controls membership of several AD groups.  This script uses the dsAddToGrp and dsRemFromGrp functions in the ADSI Extender.  The issue I have is that these functions always return 0 so I don't get confirmation that it was successful or not. 

I was thinking about following up the group modification with a dsIsMemberGrp check but was unsure if the lag in domain replication would cause issues. 

Any suggestions?

ChuckC

  • Sr. Member
  • ****
  • Posts: 435
Re: Confirming AD Group Modifications
« Reply #1 on: March 07, 2014, 07:55:18 am »
A call to dsIsMemberGrp() is the standard way of verifying that the member was actually added to the group.

And, yes, replication of changes in AD between different DCs in the domain can sometimes be an issue.  However, if you specify a DC in the LDAP ADSI path value for both the group and user, then you can ensure that the operation that adds the user to the group and the query to test the user's membership in the group are both directed to the same DC.  When examining the sample code in the help topic for dsIsMemberGrp(), note the domain name of "win2000", and replace it with the DNS FQDN of a DC in your domain when you build up your LDAP ADSI path value.  Doing so allows you to override the "serverless binding" functionality of ADSI, which can result in different LDAP bind operations actually connecting to different DCs in your domain while your script executes.  In general, you want "serverless binding" to be used for higher reliability of ADSI, but in this particular case, binding to a specific DC is desirable.

td

  • Tech Support
  • *****
  • Posts: 4444
    • WinBatch
Re: Confirming AD Group Modifications
« Reply #2 on: March 07, 2014, 08:02:37 am »
Like most ADSI extender functions the dsAddToGrp and dsRemFromGrp function error on failure so it is safe to assume the operation was successful, if you don't get an error.

Because of the way WIL terminates processing as part of error handling there is absolutely no reason to ever test the return value of either of these functions.  This would be the case even if the functions returned 1, 42, the largest prime less than a maximum 4 byte unsigned integer, or whatever. In fact, it would lead to an invalid conclusion about the success or failure of the function.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

Chris.Kubiak

  • Newbie
  • *
  • Posts: 5
Re: Confirming AD Group Modifications
« Reply #3 on: March 12, 2014, 04:39:34 am »
Thanks,

I was previously setting error mode to off thus suppressing the minor error generated by things like insufficient rights.

td

  • Tech Support
  • *****
  • Posts: 4444
    • WinBatch
Re: Confirming AD Group Modifications
« Reply #4 on: March 12, 2014, 10:05:47 am »
If you want to continue to use ErrorMode, take a look at using the LastError function to identify  errors.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade