[inopinatus]

No. Absolutely not I'd say - because the purpose of an infrastructure domain isn't obscurity. That is simply a minor side-effect. The #1 reason is to assist in separation of concerns for the control plane, especially given the human factors in managing trust relationships between devices. The name should a) be instantly and recognisably distinct, b) easy and quick to type, and c) not creating risks of fuzzing a trust boundary due to misunderstood hierarchical naming.

Also, no-one should be using AD for SaaS infrastructure. It is a pretty good product for your enterprise internal services, but cannot handle the rather different needs of a SaaS system directory.

[lykron]

I'm not saying to use AD for a SaaS product, I'm saying the advice on having an obscure domain is a bad one. The SaaS product is saas.com, the company domain is company.com, and the IPA or AD Domain is domain.company.com. I don't see any good reason to have a 3rd domain floating around for directory services. If anything it is another thing to manage and keep track of.

[programd]

So what should be used for SaaS directory infrastructure?

[inopinatus]

That's a damn fine question. There's probably a book in it.

Briefly, though, keep it federated; layering integrity is super important for systematic consistency and quality, so wherever possible, entities should register using the tools provided by the PaaS/IaaS layers that the SaaS is inevitably running on. This includes any home-grown PaaS/IaaS, which are pretty common in SaaS at scale. I like to delegate a DNS subdomain to each subsystem, which is then served either natively from that subsystem (e.g. because its control plane used etcd) or using script-generated zones served by nsd. The only central aspect I want is the meta-directory that contains, ideally, nothing but delegations under the infrastructure domain name.