Your computers and servers are completely unaware of the identity store. So even though you might be using AAD Connect to sync your on-premises Active Directory users, groups and contacts to AAD, we still can’t use those accounts to sign into a server or workstation. It doesn’t matter if you’re syncing WSAD to AAD. But there are no computer accounts, no Group Policy, and no domain controllers. You can’t join computer accounts to Azure Active Directory in the way we are used to and then use AAD accounts to sign into those computers. When Microsoft introduced Azure Active Directory, they specifically left out Domain Services from the name because it isn’t domain services at all. It is an identity solution that allows us to store users with their passwords and other settings, groups, and contacts. This has been the case for quite some time. It is the DS role that provides the Active Directory database and feature-set that we have come to know and love (or like or hate I don’t judge). If you want an Active Directory domain in your network, you would install the Active Directory Domain Service role and applicable features on your server(s). A very common misconception about Azure Active Directory is that it can replace your on-premises Windows Server Active Directory (WSAD). To be fair, the fact that the words “Active Directory” are in the title is probably what causes the most confusion. However, even in WSAD, saying Active Directory is not descriptive enough anymore. Think of WSAD or Active Directory as just the umbrella for the actual services running beneath it like Domain Services (DS), Federation Services, Certificate Services, and so on.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |