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

2015-10-08 Thread Alex Williams

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]


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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


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

2015-10-08 Thread 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



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project