There are two drawbacks to how CMS works. The first one I have already written about, so I won’t cover that in this post. You can read about it in the following post:
How to add your CMS server to a group
The second one can be a pain in large companies with multiple environments, but we will be able to see that there is some security merit behind this restriction.
All registered server connections in the CMS can only use Windows authentication. This means you can only add servers to your CMS that are in the same domain or a trusted domain. You will not be able to add standalone servers that are not in a domain. We generally see this in a DMZ scenario where the SQL Server hosts data for a public facing web server. Along those lines, we typically see that test and development environments are hosted in separate untrusted domains. You will not be able to add these servers either. In these scenarios, you will need a separate CMS in each untrusted domain.
The inability to use SQL authentication can seem like quite a setback in large companies with multiple environments. Although this restriction can be a hindrance in many environments, you have to think about the security risks if it were allowed. Allowing SQL authentication would mean having connections with stored usernames and passwords. Anyone allowed to connect to the CMS could use that connection to access a server with another set of credentials. This would make it impossible to have user and group based access controls to your data. You would also not be able to audit or track access to your server and identify an offending user.