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 <[email protected]> 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 <[email protected]>
> 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`
>>
>> https://github.com/apache/shiro/blob/master/core/src/main/java/org/apache/shiro/realm/activedirectory/ActiveDirectoryRealm.java#L158-L203
>>
>> On Tue, Jul 30, 2019 at 9:32 AM Andreas Reichel <
>> [email protected]> 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.
>>> [email protected]
>>>
>>> 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 [email protected]), 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 via email to