#6405 unify domain level-specific mechanisms for replica's DS/HTTP keytab generation
Closed: Fixed Opened by mbabinsk.

Currently the mechanism by which DS and Apache get service keytabs during replica install differ in domain level 0 and 1, respectively (e.g. in DL1 directory server requests keytab from remote master, in DL0 KDC installer generates it).

This makes it hard to abstract domain-level specific behavior from the replica installer(s).

Both domain levels should have a common mechanism to request service keytabs so that amount of domain-level specific behavior is kept at minimum. This may require more substantial modifications in replica installation workflows.

Part of the installer refactoring effort.


master:

  • 6ca96b3db03d4f3c5dbf465ca3d36bd563771c47 Fix the naming of ipa-dnskeysyncd service principal

The related patches were pushed as part of #6392

master:

  • 7cd3b1bfa76c846b7ffec18e380b71a6617d97ec installutils: remove 'install_service_keytab' function
  • 73fc15556d28706b0b9a10480fee8d56b2be9ab7 domain-level agnostic keytab retrieval in httpinstance
  • 4e97a0171a862e20089863e4bf0ec88d0ba98a53 installers: restart DS after KDC is configured
  • 3129b874a2c222ff207f1302e5d85ae12df2eac9 dsinstance: use keytab retrieval method from parent class
  • 6181844c0ce62b8d7d35554032346396b20ad3c0 use DM credentials to retrieve service keytab only in DLO
  • 4286f3885b173da9ceeb2d13d66f90336b9ef094 Service: common method for service keytab requests
  • 32599987fdc998e104846e8a176f70399cca2af2 Turn Kerberos-related properties to Service class members
  • 81bf72dc350b9c7daab669aaa796e96aee6ecbb8 Make service user name a class member of Service
  • 15f282cf2c4a5315aa3e259bd923718685d88245 service installers: clean up the inheritance

Metadata Update from @mbabinsk:
- Issue assigned to mbabinsk
- Issue set to the milestone: FreeIPA 4.5

Metadata