This bug is created as a clone of upstream ticket:
to migrate some users from a Micrsoft Active Directory to the ipa 389 directory i tried to establish a trust between both directories. after installing ipa-server-trust-ad and running ipa-adtrust-install i was not able to just remove the packages.
because the winbind service could not be started and generated alot of coredumps, i had to remove the ipa-server-trust-ad package from the server.
how i successfully removed the package:
# remove EXTID (winbind) and ADTRUST (smb) services from directory
ldapdelete -x -D 'cn=Directory Manager' -W "cn=EXTID,cn=<FQDN>,cn=masters,cn=ipa,cn=etc,dc=example,dc=org"
ldapdelete -x -D 'cn=Directory Manager' -W "cn=ADTRUST,cn=<FQDN>,cn=masters,cn=ipa,cn=etc,dc=example,dc=org"
# stop the ipa
# edit /etc/dirsrv/slapd-<domain>/dse.ldif and remove each complete block for the following entries:
# uninstall the samba and adtrust packages
yum remove ipa-server-trust-ad samba4-common samba4-winbind samba4 samba4-python
# start ipa again
Ticket was closed upstream given that the feature is not trivial and there isn't much demand for it.
That's interesting, especially if companies/users want to migrate away from Windows to Linux! There should be AT LEAST ONE method available for removing AD integration from the IdM, even if it removes ALL instances of trusted AD's. In the meantime, at least provide a workaround in the RHEL docs or, perhaps, even in this bug report.
Also for security/security scans (OpenSCAP server2 800-53/171) so that you have less services enabled, less ports opened, and less exceptions as smb and winbind are lo longer running. I have a RHEL8 servern that I need to remove adtrust on as it fails the scans and security rules say I do not need SMB/winbind so they should NOT be running and therefore you can get any exceptions for those like I can for httpd, using DEFAULT not FUTURE crypto policy, etc.
We are not planning to implement a removal of AD trust feature.
Early in RHEL IdM development a decision was made to not remove optional features from already deployed systems. This applies to any other features as well.
A workaround that already exists is to stand up a replacement replica without optional features and demote the one that contains features that you don't need anymore on that host.
The above solution did seem to work for me and is really not that complicated. Is there any issues with the above solution? Is it causing or could it cause any issues?
The main issue is consistency with other extensions which much harder to remove but there are other problems too.
- It does not address crypto waste that will be left around by leaving Kerberos principals and their keytabs
- it ignores the fact that since RHEL 8.6 we are configuring SID generation by default, so sidgen tasks cannot be removed (and since krb5 1.20 MIT Kerberos rejects tickets that do not have PAC structure -- to generate which we must have SIDs)
- it does not remove Samba databases
All of that is doable but inconsistency is a huge problem. RHEL IdM replicas are supposed to be handled as a single entity and you were supposed to design your deployment wisely. If certain features aren't required on a specific node, they should not be installed there.
I only have 2 IDM servers total right now and I added it thinking we would need AD trust and then found out that we need to keep AD and IDM 100% separate so there should not be any AD trust at all nor will there ever be.
I did remover these entries but does that not remove SID generation? Also really the only issue was just the ability to NOT run SMB and winbind. The rest is not important. Can you not just keep everything as is and just remove the SMB/WinBind from being started?
As I said all I am concerned with is the ability to not have addl services running and ports open. Honestly I think it may be easier to not have plugin installs and just do an EVERYTHING install so it's all there BUT you have the ability to shut SMB/winbind if not using ad trusts, Shut named if not using DNS, etc.
The goal as I said before is 800-53/800-171 audit compliance where no services /ports are running/open unless actually being used.
The OpenSCAP profile we use is "CIS Red Hat Enterprise Linux 8 Benchmark for Level 2 - Server". If we have additional services we do not need running they get flagged as FAILs on the OpenSCAP report (as does "update-crypto-policy" being set to DEFAULT instead of FUTURE but that's a whole different issue).