Kerberos impersonation and delegation in Samba

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Kerberos impersonation and delegation in Samba

Krishna Ganugapati
I'm investigating three problems. They are all around winbind and not the smb daemon or nmbd.

1) When an AD join is performed - the machine (say it is SAMBA$) stores its machine password in secrets.tdb and also generates the kerberos keytab information. Thus any Samba machine process that is running as root is also the kerberos principal - SAMBA$.ADDOMAIN.COM

2) These processes can receive a  session ticket from a client machine and determine the identity of the machine. My kerberos knowledge is rusty but if the ticket is PROXIABLE that implies the  service can use that ticket on behalf of the calling client to request a session ticket to third server as that particular client. The service is considered to have delegation privileges.

Question is this supported in today's Samba enabled processes - (presumably this is just smbd - can smbd do the equivalent of impersonating a client and call an RPC request  - that underneath the covers calls the kdc receives a session ticket to a third server and make a call to the third server? The impersonate client is presumably done as a setuid and setgid (change the effective gid and uid) in the process. Will pam-winbind recognize this - do the mapping of the uid and gid to the client kerberos session ticket and use that for the next set of calls and  will the underlying dce-rpc mechanism make use of this change in uid,gid

3) Can other processes access the keytab for SAMBA$ and do the same thing as 2). For example if Apache is running as root can Apache processes support delegated credentials?

4) How do you run a daemon process under the identity of a AD principal? At some point, the password of the service principal needs to be provided and stored to generate the daemon's TGT

Best regards,

Krishna
Reply | Threaded
Open this post in threaded view
|

Re: Kerberos impersonation and delegation in Samba

Andrew Bartlett
On Fri, 2005-11-11 at 16:41 -0800, Krishna Ganugapati wrote:
> I'm investigating three problems. They are all around winbind and not the smb daemon or nmbd.
>
> 1) When an AD join is performed - the machine (say it is SAMBA$) stores its
> machine password in secrets.tdb and also generates the kerberos keytab
> information. Thus any Samba machine process that is running as root is
> also the kerberos principal - SAMBA$.ADDOMAIN.COM

samba$@addomain.com

> 2) These processes can receive a  session ticket from a client machine
> and determine the identity of the machine. My kerberos knowledge is
> rusty but if the ticket is PROXIABLE that implies the  service can
> use that ticket on behalf of the calling client to request a session
> ticket to third server as that particular client. The service is
> considered to have delegation privileges.

If the right flag (trusted for delgation) is set, yes.

> Question is this supported in today's Samba enabled processes -
> (presumably this is just smbd - can smbd do the equivalent of
> impersonating a client and call an RPC request  - that underneath
> the covers calls the kdc receives a session ticket to a third server
> and make a call to the third server? The impersonate client is
> presumably done as a setuid and setgid (change the effective gid
> and uid) in the process. Will pam-winbind recognize this - do the
> mapping of the uid and gid to the client kerberos session ticket
> and use that for the next set of calls and  will the underlying
> dce-rpc mechanism make use of this change in uid,gid
I'm not sure what you are really getting at, but in Samba4 we support
delegation.  This is unsupported in Samba3 (we don't have enough of
gssapi to do this in samba3).

In Samba4, we acquire delegated credentials into an in-memory ccache,
and pass these around in our credentials abstraction.  A part of the
Samba4 RPC server (such an ldap client, for connection to a remote LDAP
server) can then use the delegated credentials.

> 3) Can other processes access the keytab for SAMBA$ and do the
> same thing as 2). For example if Apache is running as root can
> Apache processes support delegated credentials?

This is a bit different.  If we had exported a keytab, and
mod_auth_kerberos were running, presumably it could use delegated
credentials in the way traditional to gssapi.

> 4) How do you run a daemon process under the identity of a AD
> principal? At some point, the password of the service principal
> needs to be provided and stored to generate the daemon's TGT

You could export the secrets into a keytab, and then have that deamon do
a kinit from that keytab.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment