locked
PCNS Different Forests

    Question

  • I am trying to configure PCNS to work between forest a (foresta.net) to forest b (forestb.root.net). ILM 2007 SP 1 is sitting in forest b. The users are in forest a. I have a management agent set up and i reads forest a users and populates to forest b.

     

    I have a two way forest trust setup. All firewalls are turned off.

     

    The creation of a SPN in forest a

     

    setspn -A PCNS-ILM/ilm.forestb.net forestb\s-ad-ilm

    returns

     

    Failed to assign SPN on account 'CN=s-AD-ILM,OU=Users,DC=forestb,DC=root,DC=net', error 0x2098/8344 -> Insufficient access rights to perform the operation.

     

    I ran the same setspn on a server in forestb and the SPN was created. I then configured pcns as follows:

     

    pcnscfg addtarget /nStick out tongueCNS-ILM /a:ilm.forestb.root.net PCNS-ILM/ilm.foresta.root.net /fi:"Domain Users" /f:3

     

    I get the following:

    Warning: The Service Principal Name you specified could not be found on any
    accounts in this domain. This target configuration will not be able to deliver
    passwords if the Service Principle Name is not configured properly.

     

    This is because the SPN in on the user in forest b.

     

    I then changed a password in forest a and received the following error message on forest a domain controller:

     

    PCNSSVC
    Error 6025

    Password Change Notification Service received an RPC exception attempting to deliver a notification.

    The password change notification target could not be contacted.

    User Action:
    The target server may not be running. Verify that the target server is running.

     

    I have not found anywhere how to configure this type of scenario. All ILM/MIIS documentation assumes that the ILM server is in the same domain as the user password that is changing. In my scenario, the ILM/MIIS server is in a different forest.

     

    Any help will be greatly appreciated.
    Monday, December 08, 2008 5:42 AM

Answers

  • The error you pointed out above, 'Warning: The Service Principal Name you specified could not be found on any accounts in this domain. This target configuration will not be able to deliver passwords if the Service Principle Name is not  onfigured properly.' does not actually indicate any error.  When using spn for an account in a different domain, this message is expected.

     

    There is a similar thread here, which reports similar issues to what you're facing, but doesn't actually indicate if the issues were ever resolved.  I offered this advice:

    As to why the password sync is failing - It could be for a number of reasons, but most likely that something is wrong with the SPN.  SPN is just an attribute on an AD user - ServicePrincipleName.  You should use a tool like 'adsi edit' to verify that the attribute has been set properly on the user you intended it to be set on (the MIIS service account), and that it was not set on any other users.  Also, I think that in some cases, the fully qualified domain name must be used when setting the SPN, so make sure you are using that.

    Also, please double check that you have enabled password sync on the MIIS Server (Tools->Options->Enable Password Syncronization).

     

     

     

    Tuesday, December 09, 2008 10:30 PM

All replies

  • I think you will need the /s argument in the pcnscfg command to point it to the SPN you registered.

    Monday, December 08, 2008 10:51 AM
  • Sorry bad copy and paste. The /s: option was there:

    old typo:

    Code Snippet

    pcnscfg addtarget /n:PCNS-ILM /a:ilm.forestb.root.net PCNS-ILM/ilm.foresta.root.net /fi:"Domain Users" /f:3

     

     

     

    correct:

     

    Code Snippet

    pcnscfg addtarget /n:PCNS-ILM /a:ilm.forestb.root.net /s:PCNS-ILM/dilm.forestb.root.net /fi:"Domain Users" /f:3

     

     

     

    Monday, December 08, 2008 1:21 PM
  • If you're sure there are no typos, I would use my sniffer to see what is going on on the wire ... Also, if you are sure you did a copy paste, is the "dilm.forestb.root.net" correct (mind the initial "d")?

     

    Monday, December 08, 2008 2:19 PM
  • I modified server names for this post as I can't use the real names.

     

    Basically what I'm looking for is how to set up:

     

    authoritative users in forest A (windows 2003 forest mode)

    ILM and target users in forest B (windows 2008 forest mode)

     

    It looks like the SPN is not resolving to forest B on the forest A domain controller even though I have a bidirectional forest trust setup

    Monday, December 08, 2008 2:29 PM
  • The error you pointed out above, 'Warning: The Service Principal Name you specified could not be found on any accounts in this domain. This target configuration will not be able to deliver passwords if the Service Principle Name is not  onfigured properly.' does not actually indicate any error.  When using spn for an account in a different domain, this message is expected.

     

    There is a similar thread here, which reports similar issues to what you're facing, but doesn't actually indicate if the issues were ever resolved.  I offered this advice:

    As to why the password sync is failing - It could be for a number of reasons, but most likely that something is wrong with the SPN.  SPN is just an attribute on an AD user - ServicePrincipleName.  You should use a tool like 'adsi edit' to verify that the attribute has been set properly on the user you intended it to be set on (the MIIS service account), and that it was not set on any other users.  Also, I think that in some cases, the fully qualified domain name must be used when setting the SPN, so make sure you are using that.

    Also, please double check that you have enabled password sync on the MIIS Server (Tools->Options->Enable Password Syncronization).

     

     

     

    Tuesday, December 09, 2008 10:30 PM
  •  

    One thing I noticed in your PCSNCFG Addtarget command in previous responde is that the friendly name (/n parameter) and the SPN value start with same name. Try making your friendly name different, such as MIISDEMO. I have seen issues in the past when the friendly name is same as server short name. I hope this helps!

     

    Glenn Zuckerman

    Microsoft Developer Support

    Wednesday, December 10, 2008 12:29 AM