Case sensitive username/principal when using the Active Directory Realm

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Case sensitive username/principal when using the Active Directory Realm

Andreas Reichel
Dear All,

first of all, thank you a lot for providing Shiro, which we use to authenticate and authorize against Active Directory.

Unfortunately one of our clients uses case sensitive spelling for the definition of the MAIL attribute, e.g.

When the user logs-on to our application with exactly that spelling, we will confirm all the assigned roles according to the MEMBEROF attribute.

However, when any different upper-case or lower-case spelling is used (like [hidden email]), we can authenticate the user, but we fail to get the roles.

What looks like a minor issue is a maintenance nightmare, because the user did everything correct (username/password has been accepted), the AD admins did everything correct, we do not see any error -- but still the user does not get authorized.

Is there any way to:
a) switch of case-sensitivity for the authorization and/or (role will be found case-insensitive)
b) make it consistent with the authentication (either case sensitive or case-insensitive).

Thank you all in advance and cheers
Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Brian Demers
Hey Andreas,

Sounds like the easiest option would be to fix the case sensitivity of that field.  Email addresses are _generally_ considered case insensitive.

If that doesn't work (I'm guessing you already tried that route), You can extend the ActiveDirectoryRealm, and replace the `getRoleNamesForUser`

On Tue, Jul 30, 2019 at 9:32 AM Andreas Reichel <[hidden email]> wrote:
Dear All,

first of all, thank you a lot for providing Shiro, which we use to authenticate and authorize against Active Directory.

Unfortunately one of our clients uses case sensitive spelling for the definition of the MAIL attribute, e.g.

When the user logs-on to our application with exactly that spelling, we will confirm all the assigned roles according to the MEMBEROF attribute.

However, when any different upper-case or lower-case spelling is used (like [hidden email]), we can authenticate the user, but we fail to get the roles.

What looks like a minor issue is a maintenance nightmare, because the user did everything correct (username/password has been accepted), the AD admins did everything correct, we do not see any error -- but still the user does not get authorized.

Is there any way to:
a) switch of case-sensitivity for the authorization and/or (role will be found case-insensitive)
b) make it consistent with the authentication (either case sensitive or case-insensitive).

Thank you all in advance and cheers
Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Brian Demers
I hit send/enter too fast :)

If you do find a way to make this work, grabbing please let us know, maybe it is something generic enough to add back in.
The problem with LDAP is everybody uses LDAP differently, ActiveDirectly has less variation, so a generic ActiveDirectory solution _might_ be possible, though this all depends on how your groups are mapped.

On Tue, Jul 30, 2019 at 9:52 AM Brian Demers <[hidden email]> wrote:
Hey Andreas,

Sounds like the easiest option would be to fix the case sensitivity of that field.  Email addresses are _generally_ considered case insensitive.

If that doesn't work (I'm guessing you already tried that route), You can extend the ActiveDirectoryRealm, and replace the `getRoleNamesForUser`

On Tue, Jul 30, 2019 at 9:32 AM Andreas Reichel <[hidden email]> wrote:
Dear All,

first of all, thank you a lot for providing Shiro, which we use to authenticate and authorize against Active Directory.

Unfortunately one of our clients uses case sensitive spelling for the definition of the MAIL attribute, e.g.

When the user logs-on to our application with exactly that spelling, we will confirm all the assigned roles according to the MEMBEROF attribute.

However, when any different upper-case or lower-case spelling is used (like [hidden email]), we can authenticate the user, but we fail to get the roles.

What looks like a minor issue is a maintenance nightmare, because the user did everything correct (username/password has been accepted), the AD admins did everything correct, we do not see any error -- but still the user does not get authorized.

Is there any way to:
a) switch of case-sensitivity for the authorization and/or (role will be found case-insensitive)
b) make it consistent with the authentication (either case sensitive or case-insensitive).

Thank you all in advance and cheers
Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Brian Demers
Still early, one more edit...
`grabbing` -> I was going to say maybe you could grab the email address from the record instead of taking the user input and use that for the query

/me searching for my morning caffeine 

On Tue, Jul 30, 2019 at 9:57 AM Brian Demers <[hidden email]> wrote:
I hit send/enter too fast :)

If you do find a way to make this work, grabbing please let us know, maybe it is something generic enough to add back in.
The problem with LDAP is everybody uses LDAP differently, ActiveDirectly has less variation, so a generic ActiveDirectory solution _might_ be possible, though this all depends on how your groups are mapped.

On Tue, Jul 30, 2019 at 9:52 AM Brian Demers <[hidden email]> wrote:
Hey Andreas,

Sounds like the easiest option would be to fix the case sensitivity of that field.  Email addresses are _generally_ considered case insensitive.

If that doesn't work (I'm guessing you already tried that route), You can extend the ActiveDirectoryRealm, and replace the `getRoleNamesForUser`

On Tue, Jul 30, 2019 at 9:32 AM Andreas Reichel <[hidden email]> wrote:
Dear All,

first of all, thank you a lot for providing Shiro, which we use to authenticate and authorize against Active Directory.

Unfortunately one of our clients uses case sensitive spelling for the definition of the MAIL attribute, e.g.

When the user logs-on to our application with exactly that spelling, we will confirm all the assigned roles according to the MEMBEROF attribute.

However, when any different upper-case or lower-case spelling is used (like [hidden email]), we can authenticate the user, but we fail to get the roles.

What looks like a minor issue is a maintenance nightmare, because the user did everything correct (username/password has been accepted), the AD admins did everything correct, we do not see any error -- but still the user does not get authorized.

Is there any way to:
a) switch of case-sensitivity for the authorization and/or (role will be found case-insensitive)
b) make it consistent with the authentication (either case sensitive or case-insensitive).

Thank you all in advance and cheers
Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Andreas Reichel
In reply to this post by Brian Demers
Brian,

thank you so much.

On Tue, 2019-07-30 at 09:52 -0400, Brian Demers wrote:

Sounds like the easiest option would be to fix the case sensitivity of that field.  Email addresses are _generally_ considered case insensitive.

We are software vendors in emerging markets. Zero chance to tell our clients how to administrate their AD, especially no in large banks with 10'000 employees.
Also, from an engineering point of view, I tend to disagree: while the email-attribute should be interpreted/read case in-sensitive, the AD obviously is not restricting to lower-case values. For that reason, I believe the standard behaviour of Shiro should be to read/interprete case-insensitive (perhaps with an option to enforce case-sensitivity). Instead Shiro right now seems to read/interprete case-sensitive (without any option).


If that doesn't work (I'm guessing you already tried that route), You can extend the ActiveDirectoryRealm, and replace the `getRoleNamesForUser`

Yes, I am looking into that too although that unchartered ground for me and will take a while.
Would you consider a PR in the (unlikely) case I could come up with something useful?

Cheers and thank you again!
Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Brian Demers

Yes, I am looking into that too although that unchartered ground for me and will take a while.
Would you consider a PR in the (unlikely) case I could come up with something useful?

Absolutely! 

If you can provide a couple of example records that would be helpful too, I'm assuming groups have references to user emails? (instead of a user record containing the list of groups)
Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Andreas Reichel
In reply to this post by Brian Demers

On Tue, 2019-07-30 at 09:59 -0400, Brian Demers wrote:
`grabbing` -> I was going to say maybe you could grab the email address from the record instead of taking the user input and use that for the query

Great idea, I will look into that first.
How can I spend you the well deserved coffee please?

Cheers!
Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Andreas Reichel
In reply to this post by Brian Demers

On Tue, 2019-07-30 at 09:59 -0400, Brian Demers wrote:
`grabbing` -> I was going to say maybe you could grab the email address from the record instead of taking the user input and use that for the query

Brian,

sorry for asking again. I believe, the relevant line is:
/home/are/data/src/shiro/core/src/main/java/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.java
158     protected Set<String> getRoleNamesForUser(String username, LdapContext ldapContext) throws NamingException {
159         Set<String> roleNames;
160         roleNames = new LinkedHashSet<String>();
161 
162         SearchControls searchCtls = new SearchControls();
163         searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
164 
165         String userPrincipalName = username;
166         if (principalSuffix != null) {
167             userPrincipalName += principalSuffix;
168         }
169 
170         Object[] searchArguments = new Object[]{userPrincipalName};
171 
172         NamingEnumeration answer = ldapContext.search(searchBase, searchFilter, searchArguments, searchCtls);
173 
174         while (answer.hasMoreElements()) {
175             SearchResult sr = (SearchResult) answer.next();
176 
177             if (log.isDebugEnabled()) {
178                 log.debug("Retrieving group names for user [" + sr.getName() + "]");
179             }
180 
181             Attributes attrs = sr.getAttributes();

With
	protected String searchFilter = "(&(objectClass=*)(userPrincipalName={0}))";

In my limited understanding, would it not be possible/sufficient to modify that SEARCHFILTER and use one of the many like "(&(objectClass=*)(email -eq [hidden email]))" or "(&(objectClass=*)(email -like [hidden email]))"?
Can we set SEARCHFILTER in shiro.ini?

Thanks for your patience and best regards
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Case sensitive username/principal when using the Active Directory Realm

Andreas Reichel
All,

On Tue, 2019-07-30 at 22:49 +0700, Andreas Reichel wrote:
In my limited understanding, would it not be possible/sufficient to modify that SEARCHFILTER and use one of the many like "(&(objectClass=*)(email -eq [hidden email]))" or "(&(objectClass=*)(email -like [hidden email]))"?
Can we set SEARCHFILTER in shiro.ini?

I actually believe, that could work. I defined it in the shiro.ini:

realm1 = org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm
realm1.ldapContextFactory = $contextFactory
realm1.searchBase = ...
realm1.groupRolesMap = ...
realm1.searchFilter = (&(objectClass=*)(userPrincipalName={0}))

And I was able to authenticate and to authorize same as before.

Although I got an InvalidSearchFilterException when I changed it to

realm1.searchFilter = (&(objectClass=*)(userPrincipalName -eq {0}))

Oracle states[1]:

"RFC 2254 defines certain operators for the filter, including substring matches, equality, approximate match, greater than, less than. These operators are mapped to operators with corresponding semantics in the underlying directory. For example, for the equals operator, suppose the directory has a matching rule defining "equality" of the attributes in the filter. This rule would be used for checking equality of the attributes specified in the filter with the attributes of objects in the directory. Similarly, if the directory has a matching rule for ordering, this rule would be used for making "greater than" and "less than" comparisons.

Not all of the operators defined in RFC 2254 are applicable to all attributes. When an operator is not applicable, the exception InvalidSearchFilterException is thrown."

Does anyone have an idea, WHICH operators are supported? My search-filter above was given as an example for PowerShell and should work?

Cheers,
Andreas