PCNS (Password Change Notification Service) Setup and configuration can be a little confusing, so in this blog post I will run through some of the basics
This guide assumes that you have ILM (or FIM) working properly with your Live@edu (or O365 for Education) environment, since PCNS only delivers password changes to ILM, not directly to O365 for Education. ILM/FIM then delivers the change to the cloud. PASSWORD SYNC IS ONE WAY ---> from your AD to O365 for Education, there is NO sync from the cloud to your AD. At least not with the default configuration. ILM/FIM are highly customizable, however.
A lot of people overlook built in Help and documentation. Although you can find standalone PCNS documentation online, ILM comes with it’s own PCNS documentation which you can find by going to ILM/FIM > Help > Contents and Index > and typing in the keyword PCNS. You should get 5 topics that should cover most of what you need to know about how to configure PCNS. But…we’ll still go over these things here for those of you who are help file challenged!
Thank you to Tim Macaulay for referencing my blog post on his PCNS Resource Wiki:
The first thing you need to do is to install the proper version of PCNS on your domain controllers. There is a 64 bit version AND a 32 bit version and both can be downloaded here:
Before we begin, please keep in mind:
Note: The user who installs PCNS must be a member of the Domain Admins group.
Additionally, if the Active Directory® directory service schema must be updated to include object classes and attributes that PCNS requires, the user must be a member of the Schema Admins group. If you are not a member of the schema admins group, you need to log on with a schema admin account and run MSIEXEC.EXE /I "Password Change Notification Service.msi" SCHEMAONLY=TRUE, the log back on and rerun the PCNS install. Or for the x64 version, run 'Password Change Notification Service x64.msi SCHEMAONLY=TRUE'
So! Let’s get to installing PCNS on the DC’s. There isn’t much to the installation. Just click Next >
Now we are *almost* ready to add our PCNS targets. A PCNS target (typically the ILM server) is the server to which PCNS will deliver password changes.
Before we can configure a target with pcnscfg.exe, we need to add an SPN record for the target. This is done from the command line as well. If your DC is Windows 2008 you should already have setspn available and should be able to type it directly from the command prompt we have ready above.
In our case, our ILM server is named CANDAFIM2 and it uses a service account called ilmacct, so we’ll need to add an SPN record for our service account that links it to our ILM box.
Setspn.exe -A PCNSCLNT/CANDAFIM2.contoso.com contoso\ilmacct
Note: The SPN must be unique and cannot appear on any other service account. Otherwise, the Kerberos authentication fails and password change requests are not sent. Use setspn -x to help find duplicates!
*Thank you to Fernando Abrevaya for helping to clarify this section!
Now it’s time to add our PCNS targets (remember, a target is the actual ILM/FIM server). We will do this with the pcnscfg.exe command line utility. The following sample command contains the options I like to use and should work well for most deployments:
Note that the /S for the SPN must match the format in the Setspn command above. So if FQDN is used there, it should be used in your pcnscfg as well:
pcnscfg ADDTARGET /N:CANDAFIM2 /A:CANDAFIM2.contoso.com /S:PCNSCLNT/CANDAFIM2.contoso.com /FI:"Domain Users" /FE:"Domain Admins" /F:1 /I:600 /D:False /WL:20 /WI:60
Again You CAN have more than one target. PCNS will happily deliver changes to as many viable targets as you wish (some customers may have “test” environments setup, it is also possible to have ILM and FIM configured in the same environment). Again, these options can vary somewhat based on your deployment or prefereces. If your target is not configured exactly like this I wouledn't worry too much about it if you're not having issues.
IMPORTANT: If you have a multidomain environment, a PCNS target must be created in EVERY domain where user account passwords will need to be changed.
Note that there are other pcnscfg options, such as MODIFYTARGET, or DELETETARGET (with obvious uses!)
Settings within ILM/FIM
Now that we have our spn and our target setup, we can enable password synchronization from within ILM.
Step one, from the Identity Manager or Synchronization Service Console, select Tools > Options and enable password synchronization >
Next, select the OnPremise MA and select properties >
Select the Hosted MA, properties, and configure it as follows >
In the screenshot below, note that “Set only” is checked. I have seen customers check “Set and change” here, thinking that “Set only” will not process password changes. That is not the case and setting anything else here can cause password changes not to be synced with Live@edu.
When you click the “Settings” button circle above, you will get to a connection information screen where you will need to enter your galsync/olsync account information (this account should have been created when you were setting up Outlook Live Directory Sync), so you will enter something like this:
There is no need to actually run an ILM/FIM sync to get the password changes to sync. ILM/FIM will sync the password immediately (or as soon as it can!).
Let me start by answering a common PCNS question that come up. If you have pre-existing Active Directory objects that you are syncing with Live, PCNS will NOT sync the CURRENT Active Directory password, and there is no way to make it do so. The password MUST be CHANGED for PCNS to sync the password up to Live. This can be done by an admin or by the user themselves.
Password changes are synced ONE WAY, from AD to Live. Passwords changed in Live do NOT sync down to your AD.
To troubleshoot PCNS issues, you should start by checking the DC that processed the password change.
For PCNS, four logging levels are controlled by adding the EventLogLevel (REG_DWORD) entry to the following registry subkey:
· 0 = Minimal logging
· 1 = Normal logging (default)
· 2 = High logging
· 3 = Verbose logging
Once we turn up logging and check our event log, we see the following:
But, what does this mean? The most common reasons I see for this error are as follows:
The text of the 6025 error can differ depending on the problem. In the above example the problem was a duplicate spn, here is another example:
The problem here could be the following:
If you get an Event 2100 “The password notification has been delivered to all targets”, yet you are still unable to log into Live with the new password, then you have an issue with ILM/FIM, not PCNS.
Users who ARE, or who WERE, domain admins will not, by default, get synced by ILM. They will show up as a disconnector. ILM/FIM checks the admincount attribute on the user object in AD, and if it is equal to 1, the object will not get synced. If the account is no longer a member of a priveledged group the admincount attribute can safely be reset to null to allow the object to sync.
If the account IS still a domain admin, then you two choices. You can force ILM/FIM to sync domain admin accounts anyway (not recommended for general security purposes), or you can create a separate account for domain admin that is not a member of priviledged groups.
So you still want to sync domain admin accounts? At this time you will need top open a ticket with Live@edu support to obtain the instructions on syncing domain admin accounts. Please reference this blog post in your ticket.
* Many thanks to Kevyn, Linda, Jon, Dave, Ray, Kary, Tak, Denis and everyone else who has worked dilligently to provide FIRST CLASS service and support to our customers!
Awesome blog Kris, this article assisted me in walking right through the issue and getting my PCNS up and functional! Keep up the great blogging!