Error: The authenticated user does not match the user requesting access to GroupWise [D092] User:username (username)

In the verbose POA, seeing multiple entries like the following:

Error: The authenticated user does not match the user requesting access to GroupWise [D092] User: username (username)

This error is thrown on the server when a user login contains Kerberos or NTLM credentials that are valid but do not identify the user that is attempting to login. This might be over-reported in the POA logs due to the following:

1. The client will always attempt to acquire and send along kerberos/ntlm login credentials for the current windows user. This is done because prior to logging in the client has no knowledge of the user's settings or directory identity in order to determine if SSO is enabled or if the user's directory identity matches the identity of the kerberos/ntlm token. So, the client just collects as much information as possible and sends it off to the server where it can be figured out after the user database is opened and the settings are read. The eDir (novell client) SSO works in the same fashion.

This could become exacerbated by the fact that in newer versions of windows users are almost always logged in to some directory often without knowing it (i.e. if you sign-in via a Microsoft account, you are logged into the Microsoft cloud directory).

2. Prior to HP1, the POA would process SSO authentication tokens prior to reading user settings. So, if the token was valid, it would set a flag that would later be checked against the user settings and if everything checked out then the user would be allowed in without a password. Again this was modeled after how we process SSO for eDir. However, unlike eDir, the processing of kerberos/ntlm tokens is a much more involved process that with many more opportunities for things to go wrong (especially if the SSO wasn't intended or fully configured in the first place). This leads to the POA logging error related to SSO even when SSO wasn't configured.

We don't want to stop logging errors about SSO because in the event that a customer is intending to set this up they need to be able to diagnose problems that they are encountering. However, it's unnecessary to log SSO errors for a user that is not configured for SSO. So, we moved the processing of the kerberos/ntlm token until after the user settings have been read and will skip any processing if the user is not enabled for SSO.

In either case, these errors are not fatal for user login. They are informational only and don't cause login failure. The worst impact is that the user will have to enter their password to login; which for a user that is not configured for SSO is the expected behavior anyway.