(imported topic written by SystemAdmin)
Attached is a screenshot of the problem. It is a login failure for one of our users.
Login Failed
“Server error: The user name … already exists in the database”
(imported comment written by NoahSalzman)
Did they have an account using the pre-LDAP user management scheme and now they are logging in with an LDAP/AD account that matches that older account name?
(imported comment written by SystemAdmin)
They did not…they have only had their LDAP account.
(imported comment written by SystemAdmin)
I encountered this error after redirecting the console cache location as per this article:
http://support.bigfix.com/cgi-bin/kbdirect.pl?id=445
It resulted from incorrect NTFS permissions on the console cache directory - in this case, I had given the relevant group Write instead of Modify, which allowed them to generate the initial directory and cache upong first login but then they could never login again… Perhaps obviously, granting them Modify fixed the issue.
I recognize this thread is a couple months old now so you’ve probably arrived at this conclusion yourself (assuming it is indeed the same issue), but hopefully this will help anyone else who might encounter this problem.
[thread bump]
Fast forward to 2015, and I’m experiencing this exact issue on my everyday operator account. It is and always has been an LDAP account, authenticating against our AD. I have another account that works fine, as does my coworker’s account.
In poking around, we noticed that my normal account didn’t have any sites attached, and did not have the Master Operator role.
Anyone else seen this?
Turns out this was likely caused by someone renaming the LDAP groups used to validate operator accounts. We put it together after that someone’s number of available machines dropped by 2/3. 
We rejiggered the LDAP group assignment, but at the moment my account is still misbehaving.
Can you log into both accounts on the WebReports?
The affected account can login to WebReports. No issues there.
Help. We are having this issue now on some of our Master Operator Accounts.
This fixed it: http://www-01.ibm.com/support/docview.wss?uid=swg21605241
There should be an APAR opened for this. IEM should be able to queryLDAP Group membership and not worry about the DN.
Yup, same here! I finally got around to filing a SR, and the rep immediately referred me to this document.
For any documentation folks, it would be very helpful if this document included the console’s error message.
(Tagging @ottumm )
@Doczilla, can you update http://www-01.ibm.com/support/docview.wss?uid=swg21605241 to include the relevant error message:
Server error: The user name <username> already exists in the database.
@Doczilla wins for best username. 
1 Like
Anyone know if this http://www-01.ibm.com/support/docview.wss?uid=swg21605241 is still the fix or is there a less intrusive way? I’ve currently been unable to work since yesterday afternoon due to this and we have a support ticket open, but haven’t received any call back yet.
Why is it even that this causes an issue like this? Isn’t there a sync of some sort between BigFix and Active Directory that maintains security regardless of where the console user’s account initially resided in AD versus where it resides after a move?
This showed up yesterday for me since my AD account was moved from one OU to another.
EDIT: The link posted still appears to do the trick. However, it would be great if there was a better method for correcting this behavior.