I have a hypothetical situation where I want the same functionality that the PCNS service provides for connected AD domains but I want that functionality to work against an HR application. Are there any guides or anything on how to do this?

The service would need to detect when a password is changed in the application, get some ID of the user that changed their password and then the tricky part - replicate the PCNS behaviour, sending the password back to FIM using an SPN and RPC. Apart from that vague description, I don't really know where to start. Any ideas?

Hi Dan,

FIM is built under the assumption that password changes happen in AD - without fully understanding the implementation I'd say the best approach where possible would be to leverage password changes/resets via AD.

Having said that it could be possible to replicate the PCNS type functionality by using the WMI functions that FIM provides (see the link below). If there is a trigger on the HR system side you could make a call via WMI to FIM to search for the user and then reset/change their password - this would update it in AD and then flow back into FIM via PCNS.  I'd avoid doing it this way if you can - but the capability is there.

WMI reference --> http://msdn.microsoft.com/en-us/library/windows/desktop/ms697741(v=vs.100).aspx

Cheers,

Andrew.

Thanks Andrew. I had looked through the WMI methods but missed this one inside the MIIS_CSObject Class! This could be useful if I go down that route. I could either do remote WMI calls from the HR machine or set up an RPC server/client and run the WMI calls locally on the FIM box.

I was actually hoping that someone might know the details of the RPC server that FIM runs for PCNS already so that I could plug directly into that instead of re-writing it.

Yeah no idea how the PCNS operates under the covers in terms of its interactions with FIM sorry.

Hi Dan,

a possible solution would be to use both SSPR in conjunction with Password sync.

You can have the SSPR to set the AD Password and then you use the Password Sync functionality to grap the Password just set. Now you can use it in your custom Password sync Extension.

Henry

Hi Henry, I think you're missing my point. I want to write something that notifies FIM of a password change at a data source other than Active Directory. A Password sync Extension will let me send the password to the data source but not pick it up from there.

sorry, you are rigth.

But then I think it depends on your application. In case the aplication supports some kind of a Trigger that fires when a Password is set and is able to read the Password in clear text you could use it to send the Password to the Portal. By changing a newPWD field for the user you could start a workflow and set the Password in AD or where ever you need it. later this workflow should delete the value for the newPWD in the Portal that it is not stored.

I hope this time I understood better?

Henry  

Yeah, you got it this time. You're right about the problems I will have - the application needs to have some kind of trigger that fires when a password is set (or failing that a function or database I can poll) and I also have to be able to read the password from the application - not sure if either of these are possible.

Once I've gotten past that part, there are a few options but I don't think sending the password to the FIM Portal is a good option. I'd need to get the password in plain-text from the application but I wouldn't want to send it anywhere in plain text and wouldn't want to store it in plain-text in an attribute in the portal until a workflow has completed. On the plus side though, the portal is a ready-made end point with exposed wcf/soap functions I could call.

I think the best way to do it would be to run a remote powershell command from a service on the box with the application to the FIM server that makes a wmi call. Or I think there's also remote wmi, so could possibly run the script on the application server, not the FIM server. Or another option, which I like best but that might be biting off more than I can chew would be to write an RPC client and server, running the server on the FIM box and the client on the application box and running the wmi call from the RPC server. RPC Server/Clients are written in C++ as far as I know and I have almost nil experience developing in C++.

• Edited by Dan_Walters 2 hours 52 minutes ago

Yeah, you got it this time. You're right about the problems I will have - the application needs to have some kind of trigger that fires when a password is set (or failing that a function or database I can poll) and I also have to be able to read the password from the application - not sure if either of these are possible.

Once I've gotten past that part, there are a few options but I don't think sending the password to the FIM Portal is a good option. I'd need to get the password in plain-text from the application but I wouldn't want to send it anywhere in plain text and wouldn't want to store it in plain-text in an attribute in the portal until a workflow has completed. On the plus side though, the portal is a ready-made end point with exposed wcf/soap functions I could call.

I think the best way to do it would be to run a remote powershell command from a service on the box with the application to the FIM server that makes a wmi call. Or I think there's also remote wmi, so could possibly run the script on the application server, not the FIM server. Or another option, which I like best but that might be biting off more than I can chew would be to write an RPC client and server, running the server on the FIM box and the client on the application box and running the wmi call from the RPC server. RPC Server/Clients are written in C++ as far as I know and I have almost nil experience developing in C++.

• Edited by Dan_Walters Wednesday, April 09, 2014 8:03 AM

Yeah, you got it this time. You're right about the problems I will have - the application needs to have some kind of trigger that fires when a password is set (or failing that a function or database I can poll) and I also have to be able to read the password from the application - not sure if either of these are possible.

Once I've gotten past that part, there are a few options but I don't think sending the password to the FIM Portal is a good option. I'd need to get the password in plain-text from the application but I wouldn't want to send it anywhere in plain text and wouldn't want to store it in plain-text in an attribute in the portal until a workflow has completed. On the plus side though, the portal is a ready-made end point with exposed wcf/soap functions I could call.

I think the best way to do it would be to run a remote powershell command from a service on the box with the application to the FIM server that makes a wmi call. Or I think there's also remote wmi, so could possibly run the script on the application server, not the FIM server. Or another option, which I like best but that might be biting off more than I can chew would be to write an RPC client and server, running the server on the FIM box and the client on the application box and running the wmi call from the RPC server. RPC Server/Clients are written in C++ as far as I know and I have almost nil experience developing in C++.

• Edited by Dan_Walters Wednesday, April 09, 2014 8:03 AM

I have never tried pretending that I am a domain controller running the PCNS service and injecting a password change event into the Sync Engine. You might be able to get it to work, but it certainly wouldn't be supported. (It does sound like something fun to try however...)

What you can do however is use the WMI calls on the Sync Engine to apply password changes to specific Management Agents. You would have to:

• Securely get your password change to a process that has WMI access to the Sync Engine
• Have your process find the connector space object in each of the connector spaces for the Management Agents you want to set the password on
• Use WMI to set the password on the connector space object

The above has been mentioned by other posters, but I don't think it has been mentioned that there is sample code out there that does this...

Back in MIIS days there was a sample web application that did exactly the above - it was a poor man's help desk password reset and self serve password change sample application. You could probably use the same techniques to solve your problem. Here is the really old documentation that describes the sample that came with MIIS: http://technet.microsoft.com/en-us/library/cc720637%28v=ws.10%29.aspx

Note that if you do it this way, you won't get all of the password change history objects that the PCNS infrastructure maintains, you would have to create your own version of that. You also don't get the convenience of having the "source" and "target" checkboxes within Synchronization Manager that allows you to route where password changes go. This logic has to be in your own code.

Could you send the password from the HR system directly to AD and then let the normal PCNS infrastructure distribute the password to other targets?

Rex

• Edited by Rex Wheeler 9 hours 58 minutes ago

Thanks Rex. Yeah, it's more for the fun of it than fulfilling any current business need. I guess what I'd like to end up with is a sort of generic PCNS service that calls a few PowerShell scripts that can be re-written to grab password changes for any data source that it can.

Through WMI calls, I think it probably could use those tick boxes in the MA that define the password targets or, actually I think FIM might handle that part - the WMI call resets the pword in the CS object and the synchronisation goes from there. Also the password history is available through WMI too.

Yeah I suppose that is another option, sending the password to AD, but it doesn't seem as nice to me since it's edge to edge.

I have never tried pretending that I am a domain controller running the PCNS service and injecting a password change event into the Sync Engine. You might be able to get it to work, but it certainly wouldn't be supported. (It does sound like something fun to try however...)

What you can do however is use the WMI calls on the Sync Engine to apply password changes to specific Management Agents. You would have to:

• Securely get your password change to a process that has WMI access to the Sync Engine
• Have your process find the connector space object in each of the connector spaces for the Management Agents you want to set the password on
• Use WMI to set the password on the connector space object

The above has been mentioned by other posters, but I don't think it has been mentioned that there is sample code out there that does this...

Back in MIIS days there was a sample web application that did exactly the above - it was a poor man's help desk password reset and self serve password change sample application. You could probably use the same techniques to solve your problem. Here is the really old documentation that describes the sample that came with MIIS: http://technet.microsoft.com/en-us/library/cc720637%28v=ws.10%29.aspx

Note that if you do it this way, you won't get all of the password change history objects that the PCNS infrastructure maintains, you would have to create your own version of that. You also don't get the convenience of having the "source" and "target" checkboxes within Synchronization Manager that allows you to route where password changes go. This logic has to be in your own code.

Could you send the password from the HR system directly to AD and then let the normal PCNS infrastructure distribute the password to other targets?

Rex

• Edited by Rex Wheeler Saturday, April 12, 2014 12:53 AM

I have never tried pretending that I am a domain controller running the PCNS service and injecting a password change event into the Sync Engine. You might be able to get it to work, but it certainly wouldn't be supported. (It does sound like something fun to try however...)

What you can do however is use the WMI calls on the Sync Engine to apply password changes to specific Management Agents. You would have to:

• Securely get your password change to a process that has WMI access to the Sync Engine
• Have your process find the connector space object in each of the connector spaces for the Management Agents you want to set the password on
• Use WMI to set the password on the connector space object

The above has been mentioned by other posters, but I don't think it has been mentioned that there is sample code out there that does this...

Back in MIIS days there was a sample web application that did exactly the above - it was a poor man's help desk password reset and self serve password change sample application. You could probably use the same techniques to solve your problem. Here is the really old documentation that describes the sample that came with MIIS: http://technet.microsoft.com/en-us/library/cc720637%28v=ws.10%29.aspx

Note that if you do it this way, you won't get all of the password change history objects that the PCNS infrastructure maintains, you would have to create your own version of that. You also don't get the convenience of having the "source" and "target" checkboxes within Synchronization Manager that allows you to route where password changes go. This logic has to be in your own code.

Could you send the password from the HR system directly to AD and then let the normal PCNS infrastructure distribute the password to other targets?

Rex

• Edited by Rex Wheeler Saturday, April 12, 2014 12:53 AM