[GitHub] zeppelin issue #986: [Zeppelin 946] Permissions not honoring group
Github user ChrisMcVey commented on the issue: https://github.com/apache/zeppelin/pull/986 Well... I'm back again. :) Apparently, Office 365 requires that userPrincipalName be changed to the user's routable email address in order for it to be used in any cloud environments. Company-wide I have found that where I am currently working, no sAMAccountNames match userPrincipalNames. Further, no usernames match the new userPrincipalNames set for compliance with Office 365. So, the current design of the provider will implicitly not work with AD going forward. https://blogs.technet.microsoft.com/askpfeplat/2013/09/01/office-365-single-sign-on-how-to-handle-different-userprincipalname-upn-values/ --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] zeppelin issue #986: [Zeppelin 946] Permissions not honoring group
Github user ChrisMcVey commented on the issue: https://github.com/apache/zeppelin/pull/986 Well through some more testing, I've found that it it will accept logins as _either_ the userPrincipalName (without the realm) _or_ the sAMAccountName. This true if the principal suffix is NOT set in shiro. I.E. If the object has these two defined in AD: sAMAccountName=userexample userPrincipalName=userex/hostname1.domain@realm.com AND shiro.ini does not have the principal suffix: #activeDirectoryRealm.principalSuffix = @REALM.COM Then I am able to login to the UI with either userexample or userex/hostname1.domain.com as the username. If the principal suffix is enabled: activeDirectoryRealm.principalSuffix = @REALM.COM Then, I cannot login to the UI with any form of userex/hostname1.domain.com but I can login with userexample. Logging in with userexample is useless because userexam...@realm.com will not be found for group mappings by the UPN search filter. Adding all this for clarity... Zeppelin ActiveDirectoryGroupRealm does not explicity authentication the user using sAMAccountName but it does permit it. It will also accept UPN. In most cases, these match. In some cases, they may not. The more I look at this, it is becoming apparent that as an AD provider and not an LDAP provider, they are assuming that running ktpass for a keytab as we have done is not a valid user for this provider. Hopefully, this info is at least helpful if someone else has this same odd config! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] zeppelin issue #986: [Zeppelin 946] Permissions not honoring group
Github user ChrisMcVey commented on the issue: https://github.com/apache/zeppelin/pull/986 FYI... I have been having similar issues and above and until reading this thread in detail did I realize it is searching against userPrincipalName and not sAMAccountName which is a better option. Above it is mentioned the builtin user filter/subsearch is "(&(objectClass=*)(userPrincipalName=user1))" However, if a user ever runs ktpass on AD to export a keytab with a different principal name, the userPrincipalName can end up differing from sAMAccountName. It does not make sense to authenticate users via sAMAccountName successfully, then search for them again using a *different* AD property userPrincipalName... especially when these can differ. userPrincipalName is set for Kerberos which is not always gonna to be consistent with LDAP logins which is what AD provider is doing. Spent a lot of time scratching my head! Thanks for the detailed post above about the search filter. I'm quite certain my case where sAMAccountName differs from UPN is the exception to the rule but there is no reason not to match these up just in case. Best Regards --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
