Commit Error after upgrading to 6.1.1 from 6.0.1

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Commit Error after upgrading to 6.1.1 from 6.0.1

L1 Bithead
Operation Commit
Result Failed

Details vsys1

    Error: Duplicate user name 'OU=Students,DC=cadets,DC=cbchs,DC=org'

    Error: Failed to parse security policy

(Module: device)

If I revert to 6.0.1 it commits with no issues.

I've tried removing OU=Students,DC=cadets,DC=cbchs,DC=org' from the group include list on the group mapping settings and am still not able to commit after upgrading.

1 accepted solution

Accepted Solutions

This error - Error: Failed to parse security policy was clue for issue being with security policy.


Glad to know upgrade was successful.


Have a great day ahead!!

View solution in original post

9 REPLIES 9

L2 Linker

Hello Robertsa,

Is this HA pair and is the commit failing only on passive device ?

If so, then please make sure root CA certificate is not missing on the passive device. If its missing, then manually reconfigure it and then sync the devices and commit again.

Hope this helps

Hello Mystique,

This is indeed an HA pair but it is failing on both the passive and active devices.

Thank you,

Robertsa

Also the CA certificate is present and Status is "Valid" for both devices.

can you send output of below command from PA FW CLI active or passive device:

> show user group list

Sure! Message sent Smiley Happy

I can see the whole group name as below from cli command output

cn=all students,ou=groups,ou=students,dc=cadets,dc=cbchs,dc=org

Can you please try to delete the security rule in which this group name is being used and then commit. If commit is successful, then reconfigure the security rule again.

Hope this helps. If not then you might want to open a support case to further troubleshoot the issue live.

L2 Linker

Your best bet is just to remove the security policy rule and commit the changes. Then readd it.

Thanks to you both, Mystique and Parmas,

I had 7 rules applying to just our student users, in each I had users listed: cadets\all students, ou=students,dc=cadets,dc=cbchs,dc=org, and cadets\allstudents.

I first tested the effectiveness of the applicable policies using only ou=students,dc=cadets,dc=cbchs,dc=org, the policies still applied so I attempted upgrading our passive pan with the security policies updated.

The upgrade failed.

So I then tested the effectiveness of the applicable policies using only cadets\allstudents, the policies still applied so I attempted upgrading our passive pan with the security policies updated.

The upgrade was at  last successful.

My question is how did you both know to look at security policies and users being listed from the Duplicate user name error? Was vsys1 a clue for you?

Also when the upgrade was failing it was aborting on start up at "satd-config", "sslmgr-config-p1" etc. Why would security rules being ineffective cause start up processes to abort?

Thank you both again,

Robertsa

This error - Error: Failed to parse security policy was clue for issue being with security policy.


Glad to know upgrade was successful.


Have a great day ahead!!

  • 1 accepted solution
  • 5173 Views
  • 9 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!