PIV Card Constraint-Multiple User Login Constraint
DISCRIPTION OF PROBLEM:
User #1 successfully logs onto laptop which has SEE FD and SSO with PIV enabled. In addition, our required Windows domain policy requires that ALL users authenticate with PIV cards only into Windows. SEE will allow you to register and login with your PIV card without issue. However, if User #1’s PIV card/ token is updated at a PIV card station and the user returns to their workstation to login; this user will receive a bad token error and will not be able to by-pass the PBA without a local administrator. As we have more than 200,000 users, we’d like a painless process to mitigate this constraint.
Based on our investigation, this occurs because SEE only leverages the UUID field out of all fields on a token. Thus, once your token is updated or modified and you attempt to log back into your system; you will receive a bad token error message.
User #1 logs onto a laptop successfully and registers their PIV card without being constrained. User #2 has a profile on the same system but receives a bad token error when they attempt to register their PIV card in the Symantec User Client Console. If the laptop is restarted and User #2 inserts their card in the card reader and enters their credentials; User #2 receives a bad token error when they attempt to login. However; if you delete User #1, User #2 can register without error.
Reason: As the content in the UUID field is the same for both users, SEE gives the second user a bad token error, as the first users UUID information is cached, and is the same as the second user, though other fields on the PIV card have unique data.
Note: The UUID content is the same for each user at our organization, as we leverage the UUID to be distinct between offices and not individual users. Other vendor application that utilize a PIV/token access cards, leverage multiple fields, such as FASC-N data on each PIV card which is collective unique.
Create a fix which allows an office to update a PIV card/recognize a token by leveraging more than a single field in a token. I’d recommend using FASC-N data fields which is innate in most PIV cards. In addition, this is where the user name fields reside. In our environment, the UUID field is only used to make each office unique, and not each card holder. Generating a fix for this would be greatly appreciated.