none
SSPR not propogating RRS feed

  • Question

  • I have configured SSPR successfully.  and so far the bulk of my users can register and change their passwords using SSPR via portal as well as rich client.   However,  users located on one dc are complaining that password resets are not taking effect immediately.

    The obvious cause is due to delayed  propagation/replication of password changes.  However with all servers in my domain using 2008 ,  i has  assumed that failed authentication on a DC, would  result in the 'failing-up' to the PDCe.   How can I verify if this is the cause of the problem, or something else?

    Has anyone else experieince this issue?  additionally -  a co-worker is indicating that SSPR should be aware of the users primary DC..and that this would solve the problem.  Is this a function/feature that is even available?

    Friday, May 30, 2014 9:58 PM

Answers

  • Believe I discovered the issue.  The NTDS settings for that Site were not directly to the PDCe defined for the domain. This was done originally to *balance* replication to different core servers between different sites.

    A user who connected to the SSPR portal and successfully submitted a change. Then had the change immediately made by the Service on the PDCe in the Core Site. However then they attempted their *new* password at the workstation (in their Remote site). It failed against the wkst cache, then failed up to the site DC, Failed there as the change had not replicatted.  Then it "failed-up" to the NTDS server defined for their site... which was in the core but was not the PDCe... therefore their password was invalid for upto 15mins waiting for the next replication.

    • Marked as answer by ajmcc Friday, January 16, 2015 4:16 PM
    Wednesday, October 8, 2014 7:25 PM

All replies

  • Check the list of DCs listed in your AD MA in FIM sync on the "Configure Directory Partitions" tab.  Configure the list of preferred DCs and then click the select check box to only use this list.
    Tuesday, June 3, 2014 12:40 PM
  • Believe I discovered the issue.  The NTDS settings for that Site were not directly to the PDCe defined for the domain. This was done originally to *balance* replication to different core servers between different sites.

    A user who connected to the SSPR portal and successfully submitted a change. Then had the change immediately made by the Service on the PDCe in the Core Site. However then they attempted their *new* password at the workstation (in their Remote site). It failed against the wkst cache, then failed up to the site DC, Failed there as the change had not replicatted.  Then it "failed-up" to the NTDS server defined for their site... which was in the core but was not the PDCe... therefore their password was invalid for upto 15mins waiting for the next replication.

    • Marked as answer by ajmcc Friday, January 16, 2015 4:16 PM
    Wednesday, October 8, 2014 7:25 PM