none
Invalid Namespace error when attempting to reset password via SSPR RRS feed

  • Question

  • Hello,

    I'm currently running across a problem when a user is attempting to reset their password via either the client or the portal. They are able to authenticate against the phone gate we have in place, but when resetting their password they are presented with the following error page:

    An error has occurred. Please try again, and if the problem persists, contact your help desk or system administrator. (Error 3000)
    Go to Self-Service Password Reset home page

    On the server running the MIM Service, the event log error is showing:

    System.Management: System.Management.ManagementException: Invalid namespace 
       at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
       at System.Management.ManagementScope.InitializeGuts(Object o)
       at System.Management.ManagementScope.Initialize()
       at System.Management.ManagementObjectSearcher.Initialize()
       at System.Management.ManagementObjectSearcher.Get()
       at Microsoft.ResourceManagement.PasswordReset.ResetPassword.ResetPasswordHelper(String domainName, String userName, String newPasswordText)

    I've worked through the configuration outlined in the document i've pasted a link to at the bottom (as i apparently can't post links yet). So as far as i am aware shouldn't be any issues with permissions. The event log error seems to indicate an issue communicating to the WMI on the server running the Sync Service, but i'm struggling to see why.

    Has anyone else come across this before?

    Document: https://docs.microsoft.com/en-us/previous-versions/mim/ee534892(v=ws.10)

    Friday, December 7, 2018 12:08 PM

Answers

  • The MIM Service executes the password reset by making a WMI call to the MIM Sync engine. It calls the SetPassword Method on the MIIS_CSObject Class in the MicrosoftIdentityIntegrationServer Namespace. The SetPassword Method provides a sample VBscript that I'll include here to help you troubleshoot:

    Option Explicit
    on Error Resume Next
    Dim Service
    Dim CsObjects
    Dim CsObject
    
    Set  Service = GetObject("winmgmts:root\MicrosoftIdentityIntegrationServer")
    Set CsObjects = Service.ExecQuery("Select * from MIIS_CSObject where domain='main' and account='Jeff'")
    
    For Each CsObject in CsObjects
       WScript.Echo "SetPassword returns " & CsObject.SetPassword("NewPassword")
    Next
    
    

    On the line where it says: GetObject("winmgmts:root\MicrosoftIdentityIntegrationServer")

    Is the equivalent place in the process where you are encountering the error. It can't find the Namespace the MIM uses. 

    I would download the PowerShell based WMI Explorer and run it from the location of the Sync Engine. If you can see the MicrosoftIdentityIntegrationServer namespace from there then that means that the issue is firewall or permissions and not a corruption of the WBEM on the Sync Engine. 

    If that was successful then go to the box running the MIM Service, and as the MIM Service user, see if you can browse to the MicrosoftIdentityIntegrationServer namespace. If you can't then it is probably a firewall issue, either Windows Firewall on one of the two servers or a firewall in between them.


    David Lundell, Twitter | Work | FIM Best Practices book | How to Be an MVP in Life book

    Friday, December 7, 2018 10:04 PM
  • I've also noticed that in the file Microsoft.ResourceManagement.Service.exe.config

    add key="synchronizationServerName" value="Server B"

    where server B is the name of the box running the FIM Portal Service and not the FIM Sync Service. Could this be causing SSPR to look at Server B for the WMI namespace instead of going to Server A, which actually has the namespace configured?

    So, i took a chance and reconfigured the Value for this key to server A and SSPR is now working as expected! I can only assume that when the MIM portal was being configured, the value was input incorrectly. 

    Hopefully, this will be the last of my SSPR woes (although i'm doubtful).

    Monday, December 10, 2018 3:31 PM

All replies

  • The MIM Service executes the password reset by making a WMI call to the MIM Sync engine. It calls the SetPassword Method on the MIIS_CSObject Class in the MicrosoftIdentityIntegrationServer Namespace. The SetPassword Method provides a sample VBscript that I'll include here to help you troubleshoot:

    Option Explicit
    on Error Resume Next
    Dim Service
    Dim CsObjects
    Dim CsObject
    
    Set  Service = GetObject("winmgmts:root\MicrosoftIdentityIntegrationServer")
    Set CsObjects = Service.ExecQuery("Select * from MIIS_CSObject where domain='main' and account='Jeff'")
    
    For Each CsObject in CsObjects
       WScript.Echo "SetPassword returns " & CsObject.SetPassword("NewPassword")
    Next
    
    

    On the line where it says: GetObject("winmgmts:root\MicrosoftIdentityIntegrationServer")

    Is the equivalent place in the process where you are encountering the error. It can't find the Namespace the MIM uses. 

    I would download the PowerShell based WMI Explorer and run it from the location of the Sync Engine. If you can see the MicrosoftIdentityIntegrationServer namespace from there then that means that the issue is firewall or permissions and not a corruption of the WBEM on the Sync Engine. 

    If that was successful then go to the box running the MIM Service, and as the MIM Service user, see if you can browse to the MicrosoftIdentityIntegrationServer namespace. If you can't then it is probably a firewall issue, either Windows Firewall on one of the two servers or a firewall in between them.


    David Lundell, Twitter | Work | FIM Best Practices book | How to Be an MVP in Life book

    Friday, December 7, 2018 10:04 PM
  • If the WMI Namespace is the issue check out this article

    David Lundell, Twitter | Hire Identity Managed | FIM Best Practices book | How to Be an MVP in Life book

    Saturday, December 8, 2018 6:03 AM
  • Hi David,

    Using the WMI Explorer I am able to browse to the MicrosoftIdentityIntegrationServer namespace from both my box running the Sync engine and the box running the MIM service. I was logged in on both boxes as the MIM Service user when testing.

    WMI Explorer shows the correct path ...\ROOT\MicrosoftIdentityIntegrationServer and it has 72 Classes. 

    I had double checked the permissions prior to my original post, but could this still be a permissions issue? 

    I have noticed that when the servers were configured i have different accounts running the MIM Service and the MIM Sync Service, could this be an issue?

    Thanks


    Monday, December 10, 2018 9:06 AM
  • Just to expand on my configuration.

    Server A: Running MIM Sync Service
    Server B: Running MIM Service

    Server A:

    FIM Sync Service being run as: MIMSync
    ADMA account for connecting to the domain: MIMADA

    WMI Security:

    \root : MIMSync, MIMSyncPasswordReset (group), MIMService - all have Execute, Enable Account and Remote Enable set as Allow. For 'This namespace and subnamespaces'

    \root\CIMV2 : MIMSync, MIMSyncPasswordReset (group), MIMService - all have Execute, Enable Account and Remote Enable set as Allow. For 'This namespace and subnamespaces'

    \root\MicrosoftIdentityIntegrationServer : MIMSync, MIMSyncPasswordReset (group), MIMService - all have Execute, Enable Account and Remote Enable set as Allow. For 'This namespace and subnamespaces'

    Component Services:

    Access Permissions - 

    Limits: MIMSync, MIMSyncPasswordReset (group), MIMService - all have Local Access and Remote Acces set to Allow.
    Default: MIMSync, MIMSyncPasswordReset (group), MIMService - all have Local Access and Remote Acces set to Allow.

    Launch and Activation Permissions -

    Limits: MIMSync, MIMSyncPasswordReset (group), MIMService - all have Local Launch, Remote Launch, Local Activation and Remote Activation set to Allow.
    Default: MIMSync, MIMSyncPasswordReset (group), MIMService - all have Local Launch, Remote Launch, Local Activation and Remote Activation set to Allow.

    Windows Firewall:

    Windows Firewall is off, but the following rules are configured.

    Inbound:

    WMI (DCOM-In) = Allow
    WMI (WMI-In) = Allow

    Outbound:

    WMI (WMI-Out) = Allow

    Server B 

    FIM Service running as: MIMService

    Windows Firewall 

    WMI (DCOM-In) = Allow
    WMI (WMI-In) = Allow

    Outbound:

    WMI (WMI-Out) = Allow
    WMI (WMI-Out) = Allow (These are the same rule as far as i can see, but are listed twice).

    Happy to provide more information if needed.

    Monday, December 10, 2018 11:15 AM
  • I've also noticed that in the file Microsoft.ResourceManagement.Service.exe.config

    add key="synchronizationServerName" value="Server B"

    where server B is the name of the box running the FIM Portal Service and not the FIM Sync Service. Could this be causing SSPR to look at Server B for the WMI namespace instead of going to Server A, which actually has the namespace configured?

    Also, in the registry i can see that the FIMService\PasswordResetEndpointAddress has the value as "ResourceManagementService/Alternate", but in the Microsoft.ResourceManagement.Service.exe.config file i can't see any reference to this. Is it possible that there is a problem with the underlying config of the FIMService that i need to correct or am i just chasing red herrings here?

    Thanks

    Monday, December 10, 2018 2:15 PM
  • I've also noticed that in the file Microsoft.ResourceManagement.Service.exe.config

    add key="synchronizationServerName" value="Server B"

    where server B is the name of the box running the FIM Portal Service and not the FIM Sync Service. Could this be causing SSPR to look at Server B for the WMI namespace instead of going to Server A, which actually has the namespace configured?

    So, i took a chance and reconfigured the Value for this key to server A and SSPR is now working as expected! I can only assume that when the MIM portal was being configured, the value was input incorrectly. 

    Hopefully, this will be the last of my SSPR woes (although i'm doubtful).

    Monday, December 10, 2018 3:31 PM
  • Good I am glad that you got it working -- I was about to say that the mistake in the config file is probably the issue. Please mark all responses that helped you get to the answer.

    David Lundell, Twitter | Hire Identity Managed | FIM Best Practices book | How to Be an MVP in Life book


    Monday, December 10, 2018 3:43 PM