[Freeipa-users] Upgrade of schema has broken permissions and now no one can authenticate if they have certain permissions

[Martin Basti]

On 10/08/2015 03:23 PM, Alex Williams wrote:
> Hi folks,
>
> this one is becoming a bit of a major issue now. We upgraded one of 
> our IPA3.0.0 servers to use the new dogtag schema over the last few 
> days, then created an IPA4 replica from it successfully, upgraded the 
> schema on a few more of the IPA3.0.0 servers and joined them into the 
> mix and everything appeared to go ok. Unfortunately, the IPA3 replica 
> schemas did not appear to get updated automatically, as the redhat 
> upgrade documentation suggests it will, so we had to do them manually. 
> One last server needed doing this morning and it was manually updated 
> earlier today, a force-sync from one of the other servers was done to 
> ensure it was up to date and Immediately after the sync finished, 
> everyone was then refused authentication for SSH, logging into the web 
> UI for IPA and ultimately, our VPN, which is an OpenVPN server on the 
> IPA realm, using PAM to authenticate users. We've narrowed this down 
> to permission issues by tailing the /var/log/sssd/sssd_OUR_DOMAIN.log, 
> after increasing sssd's debug level. We discovered lines like below on 
> a server we were attempting to ssh into:
>
> (Thu Oct 8 13:51:16 2015) [sssd[be[domain-replaced.com]]] 
> [hbac_eval_user_element] (0x0080): Parse error on [cn=add 
> krbprincipalname to a 
> host+nsuniqueid=1e4b0d05-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com]
> (Thu Oct 8 14:01:45 2015) [sssd[be[domain-replaced.com]]] 
> [hbac_eval_user_element] (0x0080): Parse error on [cn=add sudo 
> command+nsuniqueid=1e4b0d0a-6da311e5-a41fad84-67fe4d65,cn=permissions,cn=pbac,dc=domain-replaced,dc=com]
IMHO the entries above have replication conflict

Please follow: 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

Martin

>
> If we remove all of a users roles, that user is able to authenticate 
> and the SSH session continues unhindered. Of course a user with no 
> roles, therefore no permissions, is not really able to do anything, so 
> we have to add permissions back in. Unfortunately, there seems to be 
> rather a lot of them that are broken.
>
> Any help would be hugely appreciated, as this was a production 
> upgrade, after much planning, which somehow seems to have ended up 
> broken.
>
> Kind Regards
>
> Alex Williams
>