Webauth - No unambiguous match for user
We are doing a test upgrade of our Domino 6.5.4 server to Domino 7.0.2 FP2 . Most functions appear to be working fine, however we are running into issues with web user authentication.
I have set WebAuth_Verbose_Trace=1 in notes.ini, and receive the following result:
> 11/15/2007 01:50:18.30 PM [08D4:0014-0C64] WebAuth> LOOKUP in view ($Users) (user='username' org='')
11/15/2007 01:50:18.32 PM [08D4:0014-0C64] WebAuth> No unambiguous match for user='username' org=''
11/15/2007 01:50:18.32 PM [08D4:0014-0C64] WebAuth> User Anonymous found in group Cache!
If I open the $Users view in the address book and do a search for "username" it brings up the correct person document. These lookups work fine in 6.5.4, and I'm not sure what's changed in 7.
Any help would be hugely appreciated!
I have set WebAuth_Verbose_Trace=1 in notes.ini, and receive the following result:
> 11/15/2007 01:50:18.30 PM [08D4:0014-0C64] WebAuth> LOOKUP in view ($Users) (user='username' org='')
11/15/2007 01:50:18.32 PM [08D4:0014-0C64] WebAuth> No unambiguous match for user='username' org=''
11/15/2007 01:50:18.32 PM [08D4:0014-0C64] WebAuth> User Anonymous found in group Cache!
If I open the $Users view in the address book and do a search for "username" it brings up the correct person document. These lookups work fine in 6.5.4, and I'm not sure what's changed in 7.
Any help would be hugely appreciated!
ASKER
No go, have already done that and it didn't change anything. Thanks for the suggestion though.
ASKER
Solved it!!
The problem ended up being two fold:
1) The directory the user resides in was not enabled in Directory Assistance (I left the fact it was in a second directory out of my question due to the fact I had copied my test user into names.nsf).
2) The main cause of the problem must have been related to the full text index. I deleted the index and re-created, and voila, all users can log in!
So basically, from what I can see, the index must have been messed up when the upgrade to 7.0.2 from 6.5.4 was done.
The problem ended up being two fold:
1) The directory the user resides in was not enabled in Directory Assistance (I left the fact it was in a second directory out of my question due to the fact I had copied my test user into names.nsf).
2) The main cause of the problem must have been related to the full text index. I deleted the index and re-created, and voila, all users can log in!
So basically, from what I can see, the index must have been messed up when the upgrade to 7.0.2 from 6.5.4 was done.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm fairly new to Domino, so you may very well be correct. I went into the DB properties and deleted the index from there, then created it from there as well.
I know the DA inclusion was part of the problem, but that doesn't explain why when I copied the person document to the main directory that it still wouldn't authenticate, that's why I think there were two problems. That, and I had included my second directory in DA before I did the index deletion, and it didn't work until the indexes were re-created.
I know the DA inclusion was part of the problem, but that doesn't explain why when I copied the person document to the main directory that it still wouldn't authenticate, that's why I think there were two problems. That, and I had included my second directory in DA before I did the index deletion, and it didn't work until the indexes were re-created.
The second problem may have been a caching issue. If a user fails authentication due to a missing person doc, it can take a few minutes for Domino to recognize the new credentials. If you try doing something else between the failure (due to caching) and the later success (cache reset), you might think your additional change fixed the problem, when it is just incidental.
Or I could be all wet :)
Or I could be all wet :)
ASKER
That's a very good point, and was something I was afraid of while testing so I restarted the server between tries. The cache isn't maintained through a restart by any chance is it?
Hope that helps