Is there a way to know the specific domain controller that has been used to perform an operation when using SPML?

I can't speak to SPML per se but I can tell you that the transaction payload (a.k.a $Request object) of every AD-centric action take by Active Roles contains a parameter LDAPServer.

In PoSh, you can obtain this value thus:

(This is an example of a script policy firing after an object is created)

Function OnPostCreate ($Request)

{

$LastTransactionDC = $Request.Parameter("ldapserver")

# Change the description of the user on the DC where they were created

Set-Qaduser -identity $Request.DN -Description "New user description" -Service $LastTransactionDC

}

Hope this helps.

I can't speak to SPML per se but I can tell you that the transaction payload (a.k.a $Request object) of every AD-centric action take by Active Roles contains a parameter LDAPServer.

In PoSh, you can obtain this value thus:

(This is an example of a script policy firing after an object is created)

Function OnPostCreate ($Request)

{

$LastTransactionDC = $Request.Parameter("ldapserver")

# Change the description of the user on the DC where they were created

Set-Qaduser -identity $Request.DN -Description "New user description" -Service $LastTransactionDC

}

Hope this helps.

Thanks Jonny, but alas this workload is SPML based and I can't change that. I can see now how to use this if its via POSH but still would like to see an equivalent ldapserver values from an SPML transaction.

So ideally, you would like the DC name in the SPML reply as it were?   I thought that might be the case.

I'm not very familiar with the SPML implementation so really don't know how practical it would be to deliver that information.  

In surfacing the existence of the information in the $Request object, I thought you might have an option to go and harvest it somehow after the fact.  FWIW, it's not stored in the Change History out of the box but it could be added easily by a Change Workflow reacting to the user create transaction and injecting the LDAPServer name into the OperationReason of the user create request.  You could then mine the Operation reason out of the Change History. 

There is an assumption I am making though is that when the transaction is initiated via SPML that the same option exists to intercept the $Request and modify it.

Food for thought anyway.

Hi glenn colville 

Its been a while since I've looked at SPML, however within the Active Roles solution guide document, there is information about outputting a controls.

In terms of the domain controller Active Roles (may) have used to perform an operation, this is usually found within the Controls of an operation, which as JohnnyQuest says, you get get that via powershell outside of the console/WI or SPML provider, IE:

Active Roles 7.4.5 - Solutions Guide (oneidentity.com) - Specifying controls to return to the SPML Provider client

Is essence, its saying to include a "controlsForoutput" element within your request, which specifies the controls you want to return (Like "OperationReason"), you could try requesting "LDAPServer" and/or "13" to be returned and see if you get the result you need.

You may need to specify returnData="everything" also in your request

Which should then be included in the Response

If for whatever reason 13 and/or LDAPServer controls are not returned, you could create your own control within the SPML request, then similar to the previous function JohnnyQuest  provided above, you could set the control you created to be $Request.Parameter("ldapserver")

Unfortunately I haven't got SPML available to me currently to test.

I tried adding these controls and controlsForOutput and haven't yet been able to see these in either search or modify SPML transactions. I do get data back - have had a few errors back but haven't seen additional fields yet.