If you have implemented MEE 5.2.3 or generally 5.x, could you pls. give your suggestions on the following:
How are you addressing the problem of password resets. I'm getting lot of heat on the length of the challenge response (esp. response, which the user has to type with 4 lines of code). I have set the recovery key size to 128 to have a balance between security and functionality. Do your users "really" have patience to type the four lines of code while being on call with tech support?
When you're syncing AD users do you generally sync to a controlled user group/ uncontrolled user group. I would think that certain attributes like logon hours, password expiry or account validity etc., will be different for different users though they are in one AD group. So obviously if I drop them in a controlled group, I would expect them to 'loose' these values and inherit group's property, which is a no-no. However if I want to configure number of password attempts or timeouts I cannot congfigure that to each and every user in a uncontrolled group. So how do you tackle this scenario?
What is the use of have a password reset option in the web help desk or even in the endpoint encryption manager for users that have SSO enabled?. Yesterday I had UserA reset his password (for ex: passwordxyz) via web help desk and strangely enough after the reset at the Preboot, I was expecting the UserA to be stopped at Windows interactive logon (as the new preboot password passwordxyz would not match his regular windows password). However UserA was not stopped and it went all the way through loading the desktop. I had asked UserA to do a sync, reboot and try it again. The UserA typed his new preboot password -- passwordxyz and whola, the SSO happened again without any problem. So now in that device where the user reset his preboot password, he is able to login with his preboot password multiple times and does not have any problems at SSO. How does this happen?
Thanks very much
1. 128bit is usually ok, but check with your security people whether this key length is acceptable
2. users created by the connector get the group properties on creation, so all users will initially assume the configuration you set for the group. The connector actually pays no attention to "controlness", so if it moves users, they will keep their unique attributes
3. Because the SSO details for windows are NOT the pre-boot credentials, they are entirely separate. They may be the same, but there's no requirement for that.
"..users created by the connector get the group properties on creation, so all users will initially assume the configuration you set for the group. The connector actually pays no attention to "controlness", so if it moves users, they will keep their unique attributes.."
So should i first create a group in EEM (for ex HRManagers and configure the properties (for ex "prevent password change" or timeout for incorrect passwords and password invalidation etc and then I go to the AD connector map the HR Manager AD group and sync to EEM HRManagers group (which is basically an uncontrolled group)?
"...3. Because the SSO details for windows are NOT the pre-boot credentials, they are entirely separate. They may be the same, but there's no requirement for that."
This is where my confusion is. So what you're saying is there is no point in allowing the user to change password at preboot in a SSO environment, as there is no sync that is going to happen between the Preboot password and windows password. As I understand whatever I type during my windows authentication is what gets hashed and stored locally and sent to Central object directory?
2 - you could do? You should bring this up when you get your professional services people on site, there's a lot to discuss, a lot of options to consider.
3 - what you say is true, but remember, windows creds are not the same as pre-boot, they are entirely separate Also certain Windows password events can force a change of the pre-boot password, if you turn them on. Again, something to discuss with whoever comes to help with your deployment plan.