I do not see any issues with Ambari treating usernames as case-insensitive values.
The argument where a collision between an internal "admin" account being compromised by an external "Admin" account is not valid since any account in Ambari can be set to have administrator privileges. Therefore if case sensitivity was turned back on and there was a local account with the username "JoeUser" that has administrative privileges, a remote account with the same username would compromise it.
Fortunately, Ambari keeps local and remote accounts separate so colliding usernames do not represent the same account in Ambari. This helps to prevent that admin/Admin and similar issues. However, I have to admit that I am not too keen on the current implementation since Ambari supports users from difference sources - LOCAL, LDAP, JWT (SSO) - where there may be an ambiguity in how to handle accounts with the same username but different sources. The most obvious issue is how the REST API works in relation to users. The API entry point for a user is
Notice there is no indication of source. So this call can return or set the wrong user's info if there are user accounts for the same username (case-sensitive or not) but different sources.
Back to the issue at hand and how this case-sensitivity issue affects PAM support (
AMBARI-12263). As you have indicated, some OSs are case sensitive and some are not. For example CentOS is, but Darwin (MacOS) is not. Also LDAP servers may or may not distinguish between accounts based on case - this is not consistent between LDAP server vendors. That said, if a system administrator creates user accounts with usernames differing only in case (rlevas vs. RLevas vs. etc...) expecting users to properly distinguish between them would be a big mistake and I have to assume that this is never done. However, I can imagine that there may be an issue when coming from Ambari if Ambari is storing the username as all lowercase but the OS has a user with one or more uppercase characters. This adds to the argument that the user account infrastructure needs to be reworked when it comes to the source of user authentication - which goes beyond just case-sensitivity.
I propose that we start a thread in the community to discuss a new user storage and authentication model. With more and more enterprise-level features being added to Ambari, we really need to address how to properly integrate with remote sources - including, but not limited to, LDAP, PAM, SSO/JWT, Kerberos, etc... Ultimately, user accounts should be identified by a unique user account identifier (userid) where each account may allow for one or more sources of authentication. Upon logging in to Ambari, the source of authentication must then be specified. I am not too sure how this will work when authenticating in a REST API call, but I think this may be the direction to investigate.
That said, for now, I still think Ambari itself should maintain case-insensitive usernames.
CC: Myroslav Papirkovskyi, Nahappan Somasundaram, Sumit Mohanty