Turns out that there is also an attribute called "userPrincipalName" with values of the form:
user@domain The "user" in this case has the same value as the sAMAccountName attribute. Thus if I configure my application with a default domain I can construct the userPrincipalName attribute and have the authentication work. Still would be nice if the ActiveDirectoryRealm was more configurable - similar to Spring Acegi that I've been using before. In Acegi it is possible to specify exactly what attribute to match when searching for a user to authenticate. Some documentation regarding what user names can be used would be very useful. From what I have seen so far the following works: - The FQDN (CN=Smith John, OU=..., OU=..., DC=..., DC=...) - Only the CN (Smith John) - The userPrincipal name attribute (josmith@mydomain) /Bengt /Bengt 2012/1/10 Bengt Rodehav <[email protected]> > Actually it also work with the following user name: > > Smith John > > I don't have to specify the FQDN, the DN is enough. But I still have the > same problem. I don't want to match the DN but the aSAMAcccountName > attribute. > > /Bengt > > > 2012/1/10 Bengt Rodehav <[email protected]> > >> I'm using Shiro 1.1.0. I have problems using the ActiveDirectoryRealm. >> >> I manage to get authentication to work if I specify a user's FQDN as >> follows: >> >> CN=Smith John,OU=...,OU=...,DC=...,DC=... >> >> However, the user name to be authenticated should be the sAMAccountName >> attribute. This is what the user normally enters as his/her user name when >> logging in. E g in our organization the sAMAccountName for the above user >> would be josmith. >> >> How can I instruct Shiro to match the sAMAccountName attribute and not >> the FQDN? This must be a very common request since the login process in >> Windows (using active directory) always uses the sAMAccountName (as far as >> I know anyway). >> >> Any help is appreciated, >> >> /Bengt >> >> >> >
