Kerberos is for Authentication NOT for Authorization

What Kerberos does is to make sure that something is really who it says to be. Here "something" could be anything like a user, or a service.

The "something" aforementioned is called a "principle" in Kerberos. Let's take ssh service as an example.

First, a user principle is to be added into KDC.
[root@server1]# kadmin -p root/admin
kadmin:  addprinc testuser
WARNING: no policy specified for testuser@SMALLSTRONG.LOCAL; defaulting to no policy
Enter password for principal "testuser@SMALLSTRONG.LOCAL": 
Re-enter password for principal "testuser@SMALLSTRONG.LOCAL": 

Principal "testuser@SMALLSTRONG.LOCAL" created.

Kerberos has two main kinds of principles, user and service.

• username@REALMNAME
• serverice_name/host_FQDN@REALMNAME

[root@server1 ~]# kinit testuser

Password for testuser@SMALLSTRONG.LOCAL: 

[root@server1 ~]# klist

Ticket cache: KEYRING:persistent:0:krb_ccache_TlCksdz

Default principal: testuser@SMALLSTRONG.LOCAL

Valid starting     Expires            Service principal

01/09/19 17:04:01  02/09/19 17:04:01  krbtgt/SMALLSTRONG.LOCAL@SMALLSTRONG.LOCAL

Please note that, if the current login user is called "testuser", we don't need to add any args to kinit as it will assume the principal with the same name as the current login name.

Now, we got a TGT for principle "testuser@SMALLSTRONG.LOCAL".

This TGT ticket is the proof to other service princples that the owner of this TGT is really "testuser" principle.

Now, let look at the Kerberized sshd service. The sshd service uses a host principle.

[root@server2 ~]# kadmin

kadmin:  addprinc -randkey host/server2.smallstrong.local

WARNING: no policy specified for host/server2.smallstrong.local@SMALLSTRONG.LOCAL; defaulting to no policy

Principal "host/server2.smallstrong.local@SMALLSTRONG.LOCAL" created.

Now, the sshd on server2.smallstrong.local trusts (through pam_krb5 on linux) the TGT of "testuser@SMALLSTRONG.LOCAL". Which means sshd believes the session sending TGT is really representing "testuser@SMALLSTRONG.LOCAL".

But that doesn't mean sshd allows "testuser" to log in the server2.

Whether sshd permits "testuser@SMALLSTRONG.LOCAL" to login server2 is determined by:

• If a user called "testuser" exists on servers, that is, getent passwd testuser. The user can be stored in local /etc/passwd, LDAP, or NIS.
• The user 'testuser' has a profile which allows it to login, like a valid login shell.
• Other local policy

All the above steps belong to "Authorization", which has nothing to do anymore with Kerberos.

Here we can see some default mapping between local user and Kerberos user principal.

testuser@server1.smallstrong.local --------(kinit)----------testuser@SMALLSTRONG.LOCAL

testuser@SMALLSTRONG.LOCAL------(sshd)----------testuser@server2.smallstrong.local

Of course these 'testuser' users can be stored in different places. e.g.

[root@server1] # useradd testuser

[root@server2] # useradd testuser

kadmin: addprinc testuser

So they may have a different local password, login shell, etc. This can cause many security issues.

It's best practice to let them share the same profile, which can be achieved via LDAP. 

Actually, Microsft AD combines LDAP and Kerberos KDC together as one product.

Another confusion about AD is LDAP also supports "authentication" called "bind" but it's rarely used as it lacks many features of Kerberos.