Reporter LDAP authentication issues

[Deactivated User]

Blue Coat Experts,

A couple of questions regarding the Reporter so I can understand a LDAP Authentication issue we are experiencing. We have two users defined in Active Director with identical group membership. One user can successfully access Reporter but the other cannot.

Firstly is there anyway to enable verbose logging in order to see why the LDAP authentication attempt is failing? Also there is a file called `ldap_users.cfg` within the 'settings' folder, how is this generated? I stopped the Reporter service and then removed this file and it seems to have been restored from a cache / back up as it contains LDAP users account who previously had access but no longer do. I cannot even modify this file as any changes are automatically reverted. How is the LDAP_<hash> string derived. Is this an attribute from AD, or an arbitrary value assigned by Reporter?

Finally we have found that LDAP users have to enter their userid in UPPER case in order for authentication to succeed. This seems to only affect Reporter, our Management Center, ProxySG and Content Analysis will accept the userid with case insensitivity.

Thanks in advance for your insights.

Regards,
Mick

[Slava]

Mick,

Thank you for question.

The best way to log LDAP failures is to utilize Wireshark to generate a .pcap trace of the LDAP transaction (unless you are using secure LDAP, which would all be encrypted).
If so, you will want to disable that if possible in order to review the full LDAP transaction. Within the .pcap trace, you will see in clear text, what the failure is and why.
There is also logging that takes place into the bcr-journal.txt files. Even though this will show the LDAP failure, its not as clear as to why it is failing. It will normally only indicate the base_DN for the user attempting authentication, and an 'Authentication Failure' message. This is why .pcap traces are more useful in troubleshooting these issues. If you have access to your LDAP server and have verbose logging enabled on it, you may also gain some valuable information as well.

As for the ldap_users.cfg file. This file is generated utilizing a LDAP standard query ping from Reporter using your base_DN and group_DN configuration. It will take the configured users on your Reporter and run them against your LDAP server. LDAP will return any groups and or nestedgroups they are associated with. The results of returned from the LDAP server are populated into the ldap_users.cfg file.

As for the UPPER case usernames, I am not familiar with that and have not had any Reports on this. What version of Reporter are you running by chance?

I hope this helps.

Slava V

[Deactivated User]

Slava,

Thanks for your response, very insightful. As suggested I ran a packet capture on our reporter server and ran the following scenarios:

1. Logged in with UPPER case userid and valid password - successful authentication reflected in pcap.
2. Attempted to login with UPPER case userid and invalid password - failed authentication reflected in pcap
3. Attempted to login with lower case userid and valid password - no LDAP traffic captured
4. Attempted to login with another valid LDAP account with same group membership as userid in test 1 - no LDAP traffic captured

I'm at a loss at to why test cases #3 & #4 did not result in an LDAP queries being performed.​​ The corresponding entries from the Journal is below for each test case. Any guidance is appreciated.

<134>1 2020-07-27T00:20:01.0Z SPWBCR0101 Reporter 3036 USR001 - User XXXX( Admin User (Admin) ) ( ldapuser_150d9fe44ea58a011d0b0524a4ea4761 ) logged in from IP 127.0.0.1

<134>1 2020-07-26T22:47:59.0Z SPWBCR0101 Reporter 3036 USR003 - User XXXX failed login from IP 127.0.0.1

<134>1 2020-07-27T00:19:34.0Z SPWBCR0101 Reporter 3036 USR003 - User xxxx failed login from IP 127.0.0.1

<134>1 2020-07-27T00:19:47.0Z SPWBCR0101 Reporter 3036 USR003 - User YYYY failed login from IP 127.0.0.1

In terms of the `ldap_users.cfg` file I still don't understand how this is populated. As per my first post I removed this file completely with the Blue Coat Reporter service stopped. On restarting the service the file is recreated, however the content is stale as there are users re-populated that are no longer present in any of the groups we have in our source LDAP directory.

We are a few versions behind on release 9.5.4.1.

Thanks again for your time, I really appreciate your assistance.

[Slava]

Hello Mick, 

Thank you for the detailed response, it does look like you may be hitting a sort of an Auth Bug, seeing how there is no indication of LDAP traffic initiated from the RP.
Taking in consideration the RP version 9.5.4.1 that has been at the End of Life for over a year now(and its more than a doze versions behind), i would say its safe to say that this is a bug and would highly recommend upgrading to the latest version of the RP that is 10.5.2.2.
If planing to upgrade please review the release notes starting with for 10.3.1.1 trough and including 10.5.1.1 for the upgrade path as this is not a direct upgrade from 9.5 to 10.5, and also for more detail.
Once the RP is on the latest version and if you have experiencing the same issue , let us know.
Unfortunately there is nothing that can be done for an EOL version of OS at this time

Slava

[Deactivated User]

Thanks for your reply Slava. We are running the Reporter service on a Windows 2k8 server. As I understand this deployment method is no longer supported under release 10.5.x. Are there any other options available that you are aware of?

[Jacob Miles]

Hi Mick,

You are correct that Reporter 10 doesn't run on Windows 2008 Server. It will not be possible to do a straight upgrade. Basically, you will need to deploy a 10.5 instance, and then perform a Clone Migration. Your options for what to you can run 10.5 on will be in the Reporter 10.5 Release Notes.

Thanks!

[Complex Dino]

This is a very informative blog for me. I am very much benefited after reading this blog. Keep sharing.