6

I am confused about whether Linux servers using Active Directory (AD) and Kerberos need computer accounts created?
Does the Linux server as a machine need to join an AD domain and in doing so have a computer account to have authentication/authorization services from AD?

Here are some requirements:

  • Ability to do user and group membership based authentication using AD from Linux servers.
  • Ability to map local linux UID/GID numbers to AD user and group names (today we are using a non AD LDAP server and we reserve UID/GID numbers for user and group accounts. Ideally, I'd like to continue that practice).
  • Ability to map linux Sudoer permissions to AD groups.
  • Use open source or community tools/plugins like SSSD rather than a paid commercial offering like Centrify.

I'm concerned about the pain of creating/deleting loads of linux computer accounts in AD for private cloud based servers that will likely not be around that long; but I'd like the benefits of a central user account store using AD.

Notes: I am using RHEL and Centos 6-7 linux servers and Windows Server 2012 with AD at 2008R2 functional level.

Padge
  • 85
  • 1
  • 5

3 Answers3

3

Yes, they need computer accounts. These are created through the act of "joining" the domain.

(Think Centrify, Powerbroker, etc., though specific product recommendations here are off limits.)

Active Directory in particular will not allow you to authenticate under any circumstances if you do not have an account there, regardless of whether you are a computer or a user.

Edit: Just wanted to clarify - if you intend to authenticate the servers themselves, then they need computer accounts. If you intend to only authenticate users who log on to those servers, then you could theoretically only have user accounts, if your PAM was configured in such a way as to only allow users who presented a username and password that passed a check against AD to log in.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • I just intend to authenticate end user and service accounts logging into the server(s) interactively or via scripts. I don't need to authenticate the server instances themselves. For clarification, what is the advantage of authenticating the server itself? Proof of server identity for kerberos or other? Is there some functionality within AD I lose? – Padge Feb 20 '16 at 21:59
3

With SSSD it depends on the configuration. With id_provider=ad yes, you need to join the domain with realmd. But if you don't want to join the domain, there's nothing preventing you from using id_provider=ldap. Even ID mapping would work, if you configure the SID yourself.

jhrozek
  • 1,320
  • 6
  • 5
1

There are two different considerations here:
1) authentication (password validation)
2) authorization (identity mapping/group memberships, etc)

For clients:
You can do authentication (password checking) via Kerberos from an anonymous client (no domain-join/host-creds). However you lose the ability to do GSSAPI SSO and KDC validation with out host-creds (/etc/krb5.keytab).

For authorization you need to be able to do LDAP binds/lookups to the AD-DCs. In general AD does not allow anonymous LDAP binds, so you need some kind of client side credentials. Either an explicitly created & maintained service account OR host-creds (created/maintained by domain join).

In your ldap.conf or sssd.conf files you can list explicit service account creds or tell it to use the host-creds. If you have host-creds and use the 'ad' id_provider in sssd you gain advantages such as automatic host-cred maintenance.

Note that if you want to use AD for your authorization service you'll need to add rfc2307 style info (EG uidNumber, gidNumber, etc) to every user account that you want to use on the Unix/Linux clients.

For servers:
If they're going to provide any Kerberized/GSSAPI based services, then they -must- have host-creds (be domain joined) and have valid UPN/SPN records in the computer account in AD. Think of AD as providing the Kerberos KDC functionality.

For example:
If you have a Kerberized NFSv4 fileserver, there needs to be not only a "host/F.Q.D.N" SPN there needs to be a "nfs/F.Q.D.N" SPN in the account & in the krb5.keytab file on the server.

Dave Funk
  • 26
  • 2