Linux – Find if linux machine is domain joined

active-directorylinuxsaltstack

We're joining our Linux machines to our Active Directory using adcli join. Now we start doing this as part of our saltstack setup, but we cannot figure out how to determine if the machine is already joined to the domain? It seems nothing breaks by doing multiple joins, but it does take some time and seems a bit unclean. What can we look at to find if the machine is already joined? Nothing in the adcli suite seems to do the trick.

Linux distro used is CentOS (both 6.6 and 7), domain is 2008R2 functional level.

EDIT: I've seen some people checking for the existence of /etc/krb5.keytab, but it seems to me that that is only indicative if the machine has ever been joined. If I remove the machine account from the AD, the file will still be there, but the machine is in fact no longer joined.

Best Answer

A successful kinit -k host/$(hostname -f) should be sufficient.

This checks to see both if the keytab exists and is valid.

Related Solutions

Local User Context on AD-Joined Machine – Domain vs Local Account

Your question is not stated very clearly... howewer, here's how it basically works:

Each process running on a Windows machine runs in the context of a user account; this can be one of the three machine accounts (more on this later), a local user account or a domain user account.
A process can be started either by a logged on user, or as a service.
A process started by a logged on user inherits the user's security context, and it can interact with the user's session (keyboard/mouse/screen or RDP).
A service is a process that runs in background without direct user interaction; it can be started automatically when the system starts. A service, too, runs in the security context of a user account, just like any interactive process; this can be a local or domain user account, or a system account. A service can't interact directly with user sessions.
A process running in the context of a local user account can only access resources on the local machine (if allowed); it has no valid credentials to log on to other systems, and it can connect to network resources only by supplying another set of credentials, either those of a domain user account or of a local user account on the remote server.
A process running in the context of a domain user account can access local resources (if allowed) and network resources (if allowed) on other domain joined computers.
A process running in the system context can use one of three system accounts: Local System, Local Service and Network Service. These are built-in to every Windows computer since XP/2003 (before that only Local System existed).
A process running as Local System has full privileges on the system; a process running as Local Service has lower privileges (same as a standard user accounts) and can't connect to network resources; a process running as Network Service has the same local privileges as Local Service, but can access the network.
In either case, when a process running in one of the three system contexts connects to a network resources (so this is only true for Local System and Network Service, as Local Service just can't do that), it authenticates against remote system using the computer's machine account in the domain.

To sum it up:

If the process runs as a local user account, it doesn't have valid logon credentials on remote systems.
If the process runs as a domain user account, this user account is used for logging on to remote systems.
If the process runs either as Local System or Network Service, it logs on to remote systems using the computer's machine account in the domain.

Update:

There's not a single account under which "the machine is booted". When you are at the logon screen, there are lots of things running on the system: basic system services, the programs which actually manage the logon screen itself, and possibly plenty of application services if the system is a server. Each one of these processes can run under a different user account. Most system services, anyway, run using one of the three system accounts (Local System, Local Service, Network Service). You can see which account a service runs as in the Services MMC (and/or in the Task Manager).

The machine SID, as stated by that article and many others, is not actually needed or used for anything, besides being a "prefix" for the SIDs of local user accounts (which, as such, are never seen nor referenced outside the system itself); network authentication on behalf of the system uses the computer's domain account.

Linux – Apache SSO through Kerberos using Machine Account

I don't have extended experience setting up kerberos delegation in Apache, but I'm pretty sure the service name defined in apache needs to match the service name in the keytab file.

Set the service name explicitly like this:

<Location /secured>
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbAuthRealms DOMAIN.COM
Krb5KeyTab /etc/krb5.keytab
KrbLocalUserMapping On
KrbServiceName HTTP/apache_server.DOMAIN.com
require valid-user
</Location>

The machines account in AD will need to have the HTTP/apache_server.DOMAIN.com SPN set, but it sounds like you already have this in place

Best Answer

Related Solutions

Local User Context on AD-Joined Machine – Domain vs Local Account

Update:

Linux – Apache SSO through Kerberos using Machine Account

Related Topic