I know this question has been asked and there currently is no commitment from the product development team to support this functionality in the future... but I have a question that is a different solution from the other methods that have been researched. Currently, the Active-X component calls the FIM Password Reset Client Proxy Service, running on the local machine via Named Pipes. Those data exchanges are processed by the Proxy and calls are made to the FIM Service over WCF. I have researched getting the example in the FIM Resource Management Client fully functional by sending the PWResetRequestData to the alternate endpoint, but hit the wall after sever days of getting the message properly formatted to perform the actual password reset. My next idea is to build a web part to be implemented on the portal site. By installing the FIM Password Reset Client Proxy Service on the server, I am able to establish the Named Pipe connectivity to the Proxy Service (it is a local connection at this point), send the proper commands, PipeMsgCmd.GETUSERACLEDNAMEDPIPE followed by a PipeMsgCmd.VALIDATEUSER message that contains the UserName and DomainName at the proper offsets... then the Pipe disconnects when I attempt to read the response back from the Named Pipe. So my question is, is the Named Pipe interface to the PwdMgmtProxy service documented anywhere? If not, is there any way to view the message data traversing over the named pipe so that I can duplicate the message structures that are being sent by the Active-X component? Thanks!

Have you checked Anthony Ho's Blog? http://blogs.technet.com/b/aho/ Can't remember seeing anything about the named pipe part, but his blog is probably the most complete resource describing how SSPR works...

namepipe traffic is not documented or supported. i am interested in where you get the info about "PipeMsgCmd.GETUSERACLEDNAMEDPIPE" (reflector i assume)? >>I have researched getting the example in the FIM Resource Management Client fully functional by sending the PWResetRequestData to the alternate endpoint, but hit the wall after sever days of getting the message properly formatted to perform the actual password reset. because you shouldn't send the PWResetRequestData to the alternate endpoint. now after you get the STS Token and Resume() the original request, you would receive an AnonymousInteractionRequiredFault which contains an InstanceId and EndPointAddress. Now construct a PWResetRequestData object and set the NewPassword. Then use the WsTransferFactoryClient to send a "Create" message (the PWResetRequestData object) to the endpoint (from the fault) and attach the STS token to the message. The message's header should contain the InstanceId attribute which comes from the fault.The FIM Password Reset Blog http://blogs.technet.com/aho/

Yes, Anthony's blog was helpful in dealing with the FIM Service and the FIM RM Client... Since this would be a replacement for the PW Reset/Registration executable, he does not go into great detail, other than it communicates to the proxy via named pipes and to the FIM Service over WCF... and that is the reason the executable cannot be used in an extranet to reset passwords. What I am proposing is to write a replacement to the executable, and host it on the portal server. This way multiple holes would not need to be punched through the firewall to support this.

i want to reiterate that the communication between GateFramework and Proxy is not public and is definitely subjected to change. You should treat both pieces as one black box.The FIM Password Reset Blog http://blogs.technet.com/aho/

Hey Anthony, Yes, most of my understanding of how the Proxy works is through reflector... Too bad the MSPwdRegistration.exe was not also written in .Net, that would have made this REALLY easy. I think I have figured out that my IO.Exception were cause by not using asynchronous callbacks to read in the server response messages... the server closes the pipe after every client message it receives. An async-callback method in the pipe.BeginWrite() method is the only way to catch the message before the server closes the pipe. === I will double check that this is the the same process I had last attempted. I know I had to modify the AnonymousInteractionRequiredFaultclass to expose the "instanceId" from the response header. I also had to define class level variables to retain the ContextualSecurityToken used in processing the QAGate. Much of that information falls out of scope, and is lost once the exception is caught, because it is processed through several layers of Puts(..). Thanks, your explanation gives me the desire to make another attempt at this method.

>> Much of that information falls out of scope, and is lost once the exception is caught, because it is processed through several layers of Puts(..). that's more about design problem but not technicality. i wouldn't recommend using the blogged client in production, but more of a reference on how to communicate with FIM through WS. And example will be... i believe it's the responsibility for the consumer of the client to understand each gate, but not the client itself. I also think the DefaultClient should be rather stateless and should pass back all the fault and STS tokens to the consumer of the client. It all boils down to how you design your clientThe FIM Password Reset Blog http://blogs.technet.com/aho/

Based on your explanation. After the AnonymousInteractionRequiredFault is caught... - Something like this... //Locate base address for activity endpoint string endpoint = exc.Detail.AnonymousInteractionEndpointAddress; EndpointAddress endPointAddress = new EndpointAddress(endpoint); // Get InstanceID from Exception string workflowInstanceId = exc.Detail.InstanceId; Guid workflowGuid = new Guid(workflowInstanceId); // Create NewPassword data for testing byte[] newPassword = System.Text.Encoding.Unicode.GetBytes("new_password"); // Add NewPassword data to PWResetRequestData PWResetRequestData data = new PWResetRequestData(); data.NewPassword = newPassword; // Create new message with PWResetRequestData Message pwResetRequest = Message.CreateMessage(MessageVersion.Default, Constants.WsTransfer.CreateAction, data, new ClientSerializer(typeof(PWResetRequestData))); // ToDo: Attach InstanceId from Fault to the Create Request message header // Maybe just a Message.Header.Add of a new ContextMessageProperty? // Create client for Create WsTransferFactoryClient wtfClient = new WsTransferFactoryClient("*", endPointAddress); // Attach the ContextualSecurityToken from QAGate to the Create Request wtfClient.Endpoint.Behaviors.Remove(typeof(System.ServiceModel.Description.ClientCredentials)); wtfClient.Endpoint.Behaviors.Add(new TokenAndClientCredentials(currentContextualSecurityToken) //Send the Create request Message PWResetResponse = wtfClient.Create(pwResetRequest); if (!PWResetResponse.IsFault) { setStatus = PasswordStatus.PWResetSuccess; } I'm not quite sure where/how to attach the InstanceId from the fault, and where I should get the ConfigurationName when constructing the WsTransferFactoryClient. It seems that using an "*" is the only thing that does not bark at me. Thanks!

it's the same way how you would create a normal WsTransferFactoryClient but with a different endpoint. Notice in the DefaultClient, there is already a this.wsTransferFactoryClient. one way to construct this new client is to do WsTransferFactoryClient client = new WsTransferFactoryClient( this.wsTransferFactoryClient.Endpoint.Binding, new EndpointAddress( new Uri(endpointAddress), this.wsTransferFactoryClient.Endpoint.Address.Identity, this.wsTransferFactoryClient.Endpoint.Address.Headers )); client.ClientCredentials.Windows.ClientCredential = this.wsTransferFactoryClient.ClientCredentials.Windows.ClientCredential; basically to clone the existing one as for how to set the context/instanceId, when you talk to the STS to do the challenge/response, and when you Resume the request, you need to set the instanceId too. It should be the same mechanism to do soThe FIM Password Reset Blog http://blogs.technet.com/aho/

Thanks, this was very helpful!