freeipa

#9303 Remove integration of SID configuration into base IPA installers
Closed: invalid by abbra. Opened by dbbabcock.

Closed: invalid
Reopen Issue

Request for enhancement

Remove integration of SID configuration in the base IPA installers and require users to execute ipa-adtrust-install to achieve trust. In other words, undo issue 8995.

Issue

As a result of issue 8995, integrate SID config into base IPA installers, joining a Windows client to FreeIPA can no longer connect to a local account (ksetup /mapuser * *) as specified in https://www.freeipa.org/page/Windows_authentication_against_FreeIPA. When the Windows client is joined, the user logs in, and whoami is executed, the result is domain\user and not localhost\user. While this may be the goal, it actually breaks the capability to manage local policy for the users on the windows machine using gpedit--which is not wanted in compliance and regulatory fields. In order to manage policy for users of domain\user, policy must be pushed from a policy server such as Active Directory, which IPA cannot push. To manage policy for users of localhost\user, local group policy (gpedit) is effective and works. IPA v4.9.7 works as advertised at the link for Windows platforms, but v4.9.8 with issue 8995 applied, trust configuration pushes the NetBIOS name to the client which prevents ANY local user level policy from being implemented on the user.

Steps to Reproduce

  1. Complete fresh install of FreeIPA Server 4.9.8 or higher
  2. Add Windows client using steps listed here: https://www.freeipa.org/page/Windows_authentication_against_FreeIPA
  3. Login to windows client, open a command prompt, and execute whoami

Actual behavior

User can login to the IPA Realm on the Windows client, but local machine cannot enforce policy on the user because they are not a local user.

Expected behavior

User to login to the IPA Realm on a windows client and local user policy enforcement on the user.

Version/Release/Distribution

FreeIPA v4.9.8

Additional info:

Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.

Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html
Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting

The wiki page you cite includes:

Note also that the described configuration is not supported by FreeIPA development team
and also is not supported by Red Hat Enterprise Linux Identity Management product.

There may be a workaround that doesn't involve backing out the SID changes so leaving this open for now.

I truly appreciate your attention to this issue. I understand it is not a supported feature, but for compliance/regulatory isolated LAN systems, this capability has been immeasurably helpful in deploying and managing heterogeneous environments (Lin-Win) within the security boundaries and requirements of many of my customers. Even adding in a CLI switch option for ipa-server-install (such as --disable-sids) to disable the automatic SID generation and NetBIOS integration subroutine at run-time would be helpful. If SID integration is later needed, ipa-adtrust-install can always add it when necessary. Happy to answer any additional questions if needed.

SIDs are now required to issue PACs and PACs are required to prevent a numerous sets of attacks on Kerberos authentication and use of Kerberos identifies in environments which include mixed identity mapping. This is why FreeIPA doubled down on them, as well as Samba AD and Microsoft's Active Directory implementation. Kerberos without MS-PAC buffers and recent fixed is prone for security exploitation.

A solution to you problem is to enroll Windows machines into Active Directory implementation like Samba AD if you're not using Microsoft products. FreeIPA is not going to support standalone windows systems. We do not want to redo the work and effort of two decades of Samba Team investigations.

I'm closing this issue because there's nothing to do on our side. Windows systems expect a certain arrangement for Kerberos environments and Active Directory is what Microsoft tests and supports against.

Metadata Update from @abbra:
- Issue close_status updated to: invalid
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.