mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
3692a1c57f
When ipa-getkeytab is used to fetch trusted domain object credentials, the fetched entry has always kvno 1. ipa-getkeytab always adds a key to keytab which means older key versions will be in the SSSD keytab and will confuse libkrb5 ccache initialization code as all kvno values are equal to 1. Wrong key is picked up then and kinit fails. To solve this problem, always remove existing /var/lib/sss/keytabs/forest.keytab before retrieving a new one. To make sure script's input cannot be used to define what should be removed (by passing a relative path), make sure we retrieve trusted forest name from LDAP. If it is not possible to retrieve, the script will issue an exception and quit. If abrtd is running, this will be recorded as a 'crash' and an attempt to use script by malicious user would be recorded as well in the abrtd journal. Additionally, as com.redhat.idm.trust-fetch-domains will create ID ranges for the domains of the trusted forest if they don't exist, it needs permissions to do so. The permission should be granted only to cifs/ipa.master@IPA.REALM services which means they must have krbprincipalname=cifs/*@IPA.REALM,cn=services,... DN and be members of cn=adtrust agents,cn=sysaccounts,... group. Solves https://bugzilla.redhat.com/show_bug.cgi?id=1250190 Ticket https://fedorahosted.org/freeipa/ticket/5182 Reviewed-By: Tomas Babej <tbabej@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| conf | ||
| ffextension | ||
| html | ||
| migration | ||
| oddjob | ||
| po | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| configure.ac | ||
| Makefile.am | ||
| README.schema | ||
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.