(imported topic written by michael_degroat91)
I’m having a problem adding and LDAP/AD user to my console. I’m able to query and add the user to the BES Console, but when I try to log in with that user I’m getting an unknown/username password error. I’m able to query LDAP and such correctly, add the user, etc., but just running into this snag. I know it’s not a password issue (I’m logged into AD with the same user). Does any one have any troubleshooting suggestions?
(imported comment written by cstoneba)
do you have an existing local bigfix user account that has the same name as the ldap account you are trying to login as?
(imported comment written by michael_degroat91)
Yes but the local login is userxyz and the LDAP/AD login registers as userxyz@domainname
(imported comment written by SystemAdmin)
I am experiencing the same deal (I created my TEM accounts with the same name as thier respective AD accounts, now trying to have them log in using AD password and it fails). The AD account doesnt work, and I assume it is because it is the same logon name as the existing TEM account (pvk file account). How does one handle this?
(imported comment written by SystemAdmin)
Have you tried logging in with the full email address of the AD account? So instead of bob, try bob@mydomain.com.
(imported comment written by SystemAdmin)
Yes, we did try this as well.
Before 8.2 and LDAP, I would create my users in TEM with the same logon name as thier LDAP accounts. I fear that this is where the confusion is within TEM and how it handles the two accounts with the same logon name. However I am unable to find any information yet on how to handle this, or other customer experiences.
I have a PMR open, but hope someone on here has ideas I can try while waiting for the PMR process.
(imported comment written by SystemAdmin)
When I created accounts I did a very similiar thing where I create the accounts to be the same name as the users Active Directory account. I now have 70+ Local users that I am going to migrate to LDAP users and my initial test using the right click “convert to LDAP Operator” have been relatively successful. The one big issue that I am seeing is that it appears BigFix queries to AD look for the EXACT way the account appear in Active Directory. So if a users account in Active Directory is setup as Dave.Thomas and the user attempts to login as dave.thomas it will fail with a message about “Communication Link Failure”. If they try again with the exact name in AD they are able to log in
Is there something that I am missing that will allow logins without doing a case sensitive check for the username?
(imported comment written by SystemAdmin)
Tom,
Did you ever get any answers on this? Today I had a few LDAP users that have been using TEM for months tell me that as of today that were getting the ever you were seeing. I told them to try typing their usernames as they appear in AD and that worked. What I can’t understand is these users have been logging in for close to a year with all lowercase usernames, then as of today that changed. Now some users including myself can still login using lowercase credentials.
Let me know if you’ve heard anything about this please.
-Andrew
(imported comment written by SystemAdmin)
So my problem seems to be getting worse.
At first it was just a few LDAP users that were experiencing this issue, now more users seem to be getting this error AND as of this morning a local user has this problem too.
Here are the details and some background information of specifically what I am seeing:
On Monday October 29, 2012 I upgraded our TEM infrastructure from 8.2.1093.0 to 8.2.1312.0. The first LDAP user experienced the “Communication Link Failure” error Friday November 2, 2012. The second LDAP user I am aware of experienced this issue Monday November 5, 2012. As of this morning, Tuesday November 3, 2012, more LDAP users are starting to experience the issue along with one Local user.
I am one of the users affected as of this morning. Here is what I have noticed with the logins:
I was able to login this morning with my userid in all lowercase: a-jm15
A few hours later I started noticing console errors so I logged out and attempted to log back in. When logging back in I experienced the error above.
I then tried my userid with all uppercase: A-JM15
This worked. So I decided to log back out and try another combination.
I then tried all the following which were all successful: A-jm15, a-Jm15, a-jM15, A-jM15, a-JM15
So it seems any case combination ID except for the one experiencing the problem originally is working. Why would my lowercase ID start giving me the “Communication Link Failure” error? I also tried all the random case combinations with the local user and they all work except for the ID that originally received the error.
(imported comment written by MikeOttum)
Hi Andrew_TEM, “Communication Link Failure” is an error that SQL Server generates. Therefore it seems likely that the issue is an intermittent network problem between your root server and SQL Server. Are those components on the same machine? If not, I would suggest that you look into whether there are any network configuration problems that might cause this.
(imported comment written by SystemAdmin)
They are on different machines. Not really sure where to start looking. These servers sit right next to each other on the network, meaning same subnet and vlan.