On ke, 16 loka 2019, Sven Ludwig via FreeIPA-users wrote:
Hi @audience,
I'd like to ask is there is a chance to continue using single label domains with freeipa. We learned the hard way that this feature was restricted to use. It cannot be bypassed by any command line option. I found that this all comes down to a check in the ipalib/util.py, which now counts the number of tokens in a list split by dots.
It's easy to patch, but I am asking myself for the reason to disallow this without being able to overwrite this in command-line?
Are there any further problems with using single label domains currently or in the future?
There are problems when using forest trust to Active Directory. AD simply doesn't support single label domains anymore.
The real problem is that you might not know whether you would need to integrate with AD at the time IPA is deployed. Realm cannot be changed afterwards, so if you'd stuck with single label domain, you stuck forever. With no reasonable migration path to export all data including hashed keys for Kerberos principals to a different deployment (with different realm), you would block yourself forever.
On ke, 16 loka 2019, Alexander Bokovoy via FreeIPA-users wrote:
On ke, 16 loka 2019, Sven Ludwig via FreeIPA-users wrote:
Hi @audience,
I'd like to ask is there is a chance to continue using single label domains with freeipa. We learned the hard way that this feature was restricted to use. It cannot be bypassed by any command line option. I found that this all comes down to a check in the ipalib/util.py, which now counts the number of tokens in a list split by dots.
It's easy to patch, but I am asking myself for the reason to disallow this without being able to overwrite this in command-line?
Are there any further problems with using single label domains currently or in the future?
There are problems when using forest trust to Active Directory. AD simply doesn't support single label domains anymore.
The real problem is that you might not know whether you would need to integrate with AD at the time IPA is deployed. Realm cannot be changed afterwards, so if you'd stuck with single label domain, you stuck forever. With no reasonable migration path to export all data including hashed keys for Kerberos principals to a different deployment (with different realm), you would block yourself forever.
Sent early. ;)
Another problem is that use of single label setup implies that you own DNS TLD domain for it. E.g., for EXAMPLE realm, you need to own .example. This is not going to work for all users unless they aren't really integrating with global DNS system. But then it breaks badly DNSSEC integrity as well as other DNS protection technologies. Although something might work today, it will be broken tomorrow with DNS-over-HTTPS, for example, where actual DNS name resolution is performed outside your environment for everything, including your internal hosts.
What is possible technically in an isolated environment is not something that should be promoted for general use. So we strongly discourage that.
Hi Alexander,
Thanks for the quick answer. As I am forced to use a non-email-product to write emails, please consider the following as "quoted properly" - i did my very best ;)
Are there any further problems with using single label domains currently or in the future?
There are problems when using forest trust to Active Directory. AD simply doesn't support single label domains anymore.
The real problem is that you might not know whether you would need to integrate with AD at the time IPA is deployed. Realm cannot be changed afterwards, so if you'd stuck with single label domain, you stuck forever. With no reasonable migration path to export all data including hashed keys for Kerberos principals to a different deployment (with different realm), you would block yourself forever.
This is always true if you decided to implement a certain thing on more then one instance. As you might already guessed, stuck is the situation I am in right now with thousands of clients deployed. We're stuck with centos ~7.6, where this check wasn't enforced to our environment or with continuously patching the package on our local mirrors.
Another problem is that use of single label setup implies that you own DNS TLD domain for it. E.g., for EXAMPLE realm, you need to own .example. This is not going to work for all users unless they aren't really integrating with global DNS system. But then it breaks badly DNSSEC integrity as well as other DNS protection technologies. Although something might work today, it will be broken tomorrow with DNS-over-HTTPS, for example, where actual DNS name resolution is performed outside your environment for everything, including your internal hosts.
What is possible technically in an isolated environment is not something that should be promoted for general use. So we strongly discourage that.
I totally get your point here. Because as thinking of the main driver into this, I'd rather expect a wizard which denies this option, but a proper work around using power shell or regedit. So from your point of you is patching the util.py the only way left to continue using your very own top level domain in isolated and non public environments?
Regards, Sven
freeipa-users@lists.fedorahosted.org