LDAP profile broken after upgrading to 5.0.10

[as-mg]

Hi,

I upgraded my firewalls to PANOS 5.0.10 yesterday, and after the upgrade the LDAP profile fails with "invalid credentials". I have tried resetting the password for the account used, but the error still persists.

Have anyone else encountered this issue? Experiencing the same issue both on PA-3020 and PA-200, and the error started occuring immediatly after the system was rebooted to running 5.0.10.

[VinceM]

Hi,

Done the upgrade yesterday and no issue ... on both PA500 and PA200.

V.

[as-mg]

I have reset password for the user, and confirmed that the user is able to connect to Active Directory properly from a Windows machine, so this should be OK.

Also did a reboot of one of the firewalls, as well as one of the DC's.

Entire forest is running at 2008 R2 level, and the issues started occuring immediatly after the systems had been rebooted with 5.0.10.

Authentication profile looks like this:

Tried using both using full DN, as well as username@domain.

[as-mg]

Seems like I got it working now (forgot to update the password in the agent setup under User mapping. Whoops!), but I'm still having issues with rules that allow users based on user group.

I still find it weird that the LDAP suddenly stopped working for each device after rebooting with 5.0.10.

EDIT: I think I found the error. If using the value of distinguishedName as the Bind DN in the LDAP profile, authentication will fail. This has been working fine in previous versions. Using user@domain works.

If I add the user directly, it works just fine. Do I have to wait for a synchronization to run in order for user groups to work properly again?

Did "show user group name "cn=group name,ou=groups,dc=domain,dc=local", and it seems like it should work.

All users are listed as domain\username.

However, if I do "show user ip-user-mapping ip 192.168.10.100", the Group(s) field only show one of the groups my user belongs to.

[as-mg · Accepted solution]

Bug found in 5.0.10:

I have solved this case. We are a Norwegian company, with a Scandinavian character in our name (ø), and this has been used for the OU containing most of our users, computers and groups.

To see if this could be an issue, I created a new group and moved it to "OU=Users,DC=domain,DC=local", and added it to the group mapping, along with the existing groups which were already present, and located under a OU with ø in it's name.

From CLI, doing "show user group-mapping state "Default groups", the new group was the only one shown, and number of groups was shown as 1, despite over ten groups being added to the group mapping.

Then, doing "show user group name ?", showed the lowercase ø being written as "ø", so all attempts to look up items located under this OU failed. Issue would also occur if the user group name contained the character.

I assume this also goes for other non-English characters, and it did work in all versions prior to 5.0.10 that I have run.

Now I only hope that someone from Palo Alto Networks actually sees this, and that it will be fixed in an upcoming version.

[as-mg]

The issue has been submitted to Palo Alto, and a fix is planned for PANOS 6.0.

[jochristian]

Hello as-mg..
Do you have the bug number for this issue?

[as-mg]

Unfortunately, no, as I never had direct contact with Palo Alto Networks, but went through a second company that handles support for us.

However, the issue has not been resolved in 5.0.11 which I installed tonight. Could not see anything in the release notes for PANOS 6.0.0 either, could anyone running this version confirm if it has been resolved or is still an issue?

[Sberbank]

Hi . We Have the same problems with Russian symbols.

At PanOS 6 issue was not solved =(

[Sberbank]

Answer from our integrators :

Solving of that problem expected in 5.0.12 and 6.0.2 releases. Release 5.0.12 expected in first part of May , but date may changed by developers team.

[panos]

we had the same problem today, downgraded to 5.0.9, and working fine.Hope 5.0.12 comes soon.

[as-mg]

The issue seems to have been adressed in 6.0.2, I will try upgrading one of my firewalls throughout the weekened to confirm this.

60673 — LDAP groups containing non-ASCII characters in their names could not be

processed by the firewall. Policies filtering on these groups were not working properly.

With this fix, groups are received by the firewall, regardless of the types of characters

used in their names.

[panos]

This is good news for 6.0.x

[as-mg]

Installed 6.0.2 on our lab box, and the group now shows up when doing "show user group-mapping state Group-name", but lowercase ø is still shown as Ã,.

I do not recall how this looked on 5.0.9, but this could just be a cosmetic issue.

Will have to do some further tests to see if the issue has been resolved or not.

Would like to hear from others who have upgraded to 6.0.2 as well.

EDIT: This fix has also been added to the new 5 release; 5.0.12.