We are running Endpoint Encryption Manager 5.2.11 and have no issues with Endpoint Encryption Connection Manager with our 2003 AD servers (this has been working with EEM since 2009).
We have recently changed the Domain controller that Endpoint Encryption Connection Manager points to (to troubleshoot i've reverted back to our 2003 DC's). It is now on 2008 R2 but in 2003 native mode. Forest function level - Windows Server 2003 - Domain Function Level 2003.
The following is currently Working when we point our EE Connection Manager to our Server 2003 DC's - We have a security group setup to automatically create users in EEM that are added to a GG_Safeboot AD group. If a user is disabled or removed from AD their safeboot account is disabled. If a user is added back to the same GG_Safeboot group then their EEM account is Re-enabled.
The following is currently Working when we point our EE Connection Manager to our Server 2008 DC's - Users are automatically added to EEM when a user is added to our GG_Safeboot AD group. If a user is disabled or removed from AD their EEM account is disabled.
The following is currently Not Working when we point our EE Connection Manager to our Server 2008 DC's - If a user is added back to the same GG_Safeboot group then their EEM account is Not re-enabled (as it should do)
Can anyone point me in the direction of a fix?
Thanks for any help in advance
Do you have a connector log file showing the name of the user we can see?
Yes the user is called fsiadmin but it's the same with all users.
I've run the log when running the connection manager on the 2008 DC in 2003 mode. I've done an edit find on that account and pasted the log stuff related to it.
28/03/2013 15:10:57 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a group
28/03/2013 15:10:57 ldap reports = 0 (Success)
28/03/2013 15:11:00 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a user
28/03/2013 15:11:00 ldap reports = 0 (Success)
28/03/2013 15:11:04 Checking Endpoint Encryption User FSIAdmin
28/03/2013 15:11:04 ...change attribute older than current users: Ignoring other changes
28/03/2013 15:11:04 ...No changes needed.
That's what I needed, the change attribute issue means that the entry for the user in eem has a change number larger than the one in your domain (it's not synced between servers - it's a local domain server counter). Thus it won't sync changes until the value in the ad exceeds the one in eem.
To solve, you need to zero out the change values in eem for each user (in their bindings). You can do this with a script if you have a lot of users.
Ideally this would be a /= comparison rather than a<comparison, but it's not. The number in the ad has to exceed the number in eem for changes to be reflected.
Manually change it for that user and run the job again to prove this - I'm pretty sure it will work fine.
I've repeated the process of removing the security group, syncing, then adding back to the security group on Server 2003 DC's. This is the logs related to the account.
28/03/2013 15:19:33 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a group
28/03/2013 15:19:33 ldap reports = 0 (Success)
28/03/2013 15:19:42 Checking if dn 'CN=FSI Admin,OU=FSI,OU=Staff Users,DC=a4egroup,DC=co,DC=uk' is a user
28/03/2013 15:19:42 ldap reports = 0 (Success)
28/03/2013 15:19:57 Checking Endpoint Encryption User FSIAdmin
28/03/2013 15:19:57 ...updating user state.
I've done a quick search and have found this:
Yes. That's exactly what I just told you to do :-)
Sorry i'd not read your reply yet.
Would this be a one off script that would need to be run, or do you think this might re-occur?
I'm trying to understand what the difference is between our 2003 and 2008 servers and their change values.
It will reoccur if you chance servers again.
No difference,it's just the value is local to the server - it does not sync between them. You changed servers, thus the eem has the values from the old box, and that server has seen more changes than the new one.
Thanks i've reset the state change on that user and it's working now on the 2008 server.
- If you don't mind i've just got a few questions regarding this issue. Really appreciate your help, you've been great as usual!
- Do you know why it would only be affecting our 2008 server DC's? I've tried running the test on a number of 2008 server DC's and it fails on them all unless i 0 the change state. In addition im unsure why it's only the addition to the security group that it doesn't recognise, and yet it happily disables and generates new users?
- Can you see any side affects of running a script to change all the change states of 2000+ users. I'm just a little apprehensive and i don't want to break anything.
- We will be moving to native 2008 in the future, is 5.2.11 (moving shortly to 5.2.12) connection fully compatible?
1. It's nothing to do with the server version - it's simply because the change value for the user differs between servers, and in this case the server you moved to has lower change values than the server you moved from.
2. Whether it affects any particular user also depends on their respective change values - it depends on how many changes have been made to the user.
3. Resetting it for everyone will cause a one time glut in traffic as the connector resyncs them all - it would be better if you just mine the log for users with this error message and reset them only.
4. The connector talks to AD - it's not version specific so yes, everything is supported.