IT environments have a structure. The systems in them are arranged with a purpose. Integrating two separate infrastructures requires an assessment of the purpose of each of those environments and an understanding of how and where they interact.
1.1. Defining Windows Integration
Windows integration can mean very different things, depending on the desired interaction between the Linux environment and the Windows environment. It could mean that individual Linux systems are enrolled into a Windows domain, it could mean that a Linux domain is configured to be a peer to the Windows domain, or it could simply mean that information is copied between environments.
There are several points of contact between a Windows domain and Linux systems. Each of these points revolve around identifying different domain objects (users, groups, systems, services) and the services which are used in that identification.
User Identities and Authentication
Where are user accounts located; in a central authentication system running on Windows (AD domain) or in a central identity and authentication server running on Linux?
How are users authenticated on a Linux system; through a local Linux authentication system or a central authentication system running on Windows?
How is group membership configured for users? How is that group membership determined?
Will users authenticate using a user name/password pair, Kerberos tickets, certificates, or a combination of methods?
POSIX attributes are required to access services on Linux machines. How are these attributes stored: are they set in the Windows domain, configured locally on the Linux system, or dynamically mapped (for UID/GID numbers and Windows SIDs)?
What users will be accessing what resources? Will Windows-defined users access Linux resources? Will Linux-defined users access Windows resources?
In most environments, the Active Directory domain is the central hub for user information, which means that there needs to be some way for Linux systems to access that user information for authentication requests. The real question then is how to obtain that user information and how much of that information is available to external systems. There also needs to be a balance between information required for Linux systems (POSIX attributes) and Linux users (certain application administrators) and how that information is managed.
Host and Service Principals
What resources will be accessed?
What authentication protocols are required?
How will Kerberos tickets be obtained? How will SSL certificates be requested or verified?
Will users need access to a single domain or to both Linux and Windows domains?
DNS Domains, Queries, and Name Resolution
What will be the DNS configuration?
Is there a single DNS domain? Are there subdomains?
How will system host names be resolved?
How will service discovery be configured?
How frequently are systems added to the domain?
If the underlying configuration for something related to Windows integration is changed, for example the DNS service, how are those changes propagated?
Is configuration maintained through domain-related tools or a provisioning system?
Does the integration path require additional applications or configuration on the Windows server?
As important as which elements in the domains are integrated, is how that integration is maintained. If a particular instrument of integration is heavily manual, yet the environment has a large number of systems which are frequently updated, then that one instrument may not work for that environment from a maintenance standpoint.
The following sections outline the main scenarios for integration with Windows. In direct integration, Linux systems are connected to Active Directory without any additional intermediaries. Indirect integration, on the other hand, involves an identity server that centrally manages Linux systems and connects the whole environment to Active Directory of the server-to-server level.