One Time Password (OTP) behavior with SEE 8.0.0
I am getting ready to roll out SEE to all our laptop users. I am just going through the various ways to do SSO & OTP. I have 8 different configuration possibilities. Just thought I'd see what other people thought of my findings and if it sounds correct or not. I am brand new to this software, so any input is appreciated.
I am using a test account that is registered with SEE successfully on two different machines - one machine with SSO, one without.
3 variables: Offline or Online, SSO or no SSO, and active domain network connection or not
1) Online + SSO + network: This is the configuration that works best. It prompts the user to create a new password when they get into Windows
2) Online + SSO + no network: They get into Windows but aren't prompted to reset pw because they have no domain connection. Sounds about right. I assume you have to use the offline method when you have no domain connection. However, it says when they connect to the domain and Windows starts, they will be prompted to change password. This never happens. I plugged the network cable back in, rebooted twice, waited half an hour, did a Check In Now from the User Client, no force password change ever happened. I made sure the AD sync was working in the Configuration Mgr. I ran thru the OTP two more times to test this and for whatever reason, it never forces any password changes. Not a huge deal since they can just call the Help Desk and get their domain pw changed.
3) Online + no SSO + network: SEE has them pick a new password. It works for SEE fine, but what about when they get to the Windows logon? Their domain password is still the one that they forgot. They call the Help Desk and get their password reset. No big deal. SEE will sync with AD after they reset it.
4) Online + no SSO + no network: SEE has them pick a new password. It works for SEE fine, but what about when they get to the Windows logon? Their cached domain password is the one that they forgot. No way to get that reset with them connecting to the domain network. OK, so this is definitely not the method to use.
5) Offline + SSO + network: Works well. Same as when using Online method (see #1)
6) Offline + SSO + no network: Doesn't work too well. Same as when using Online method (see #2). The fact that you're choosing Offline doesn't seem to change how it works with the cached domain credentials. That is, it never updates any passwords - not SEE, not cached domain, so the user has to do the OTP process every time they reboot. Once they get back onto the domain network, just like when doing this in Online mode, it never prompts the user to update passwords when they are on the domain. The have to call the Help Desk to get it reset. Pretty inconvenient but it's the user's fault so I don't feel too bad.
7) Offline + no SSO + network: Same as Online mode (see #3)
8) Offline + no SSO + no network: Same as Online mode (see #4). This is unfortunate. Basically it means that we can't put the non-SSO version on laptops because there is no way to get into Windows if you forget your password.
In conclusion, I believe offline mode is only needed if SEE never did a successful check-in. It doesn't have anything to do with their connection to the domain network.
Also, we can't put non-SSO version on laptops because there is no way to get into Windows when you're offsite. Gladly, this is okay for us. We only need to put non-SSO version on some specialized desktops that should have a network connection to the domain 24/7.
For laptop users that are offsite, we will do online + SSO to help them get into Windows. We'll inform them that they can't reboot or they'll have to do the OTP process again. I just thought of another test I need to do: locking & unlocking the laptop. We have a 20 min auto-lock set up on all machines. *Update* I looked over at my test machine with SSO and the screen-saver is going. Moved the mouse, sure enough, it's at the login screen. What's my password? I don't know because I had to do OTP. The user won't be able to unlock the workstation. Hmm, that will be really crappy for them. I am imagining an important employee going to training for a week and forgetting their SEE password because they haven't used their travel laptop in 5 months. Of course they didn't try logging in before getting on that plane to Denver. We go through OTP to get them in. Maybe they can manage to not let the laptop be idle for 20 minutes until lunch, but that might be hard/impossible during lunch. Also, when they walk away from the laptop to get a drink of water, they should lock it, but they can't. They are either stuck at the laptop or have to violate policy and not lock it when walking away, or they'll just have to reboot and do OTP with the Help Desk again. Then, at the end of the day, the laptop will surely be idle for 20 min. So I'm thinking at least 2 times a day they will have to do OTP with our Help Desk. Probably more like 5 times. Painful.
I was thinking we could have one generic back-up/just-in-case account on laptops for this type of scenario. It wouldn't have to be a local account - it could be domain. When we stage the laptop initially, we'll just have to register SEE with a generic account. Our stricter-than-strict policies dictate that we cannot have a generic account on a laptop, so this might be an issue with the security guys. Also, using a generic account won't be too great because they won't have access to anything on their normal account (desktop, favorites, my docs).
Has anyone out there had to deal with a situation like this? No local accounts, just domain accounts on a laptop. User offsite, can't access the domain, forgot their pw, has to do OTP, has SSO enabled, and has to lock workstation voluntarily or involuntarily.
OK my head hurts now. I'll have some more fun with this tomorrow. Thanks for reading!