Difference between revisions of "Samba4 Port: iptables Remapping"
From K5Wiki
(New page: Q: background: i was hired by RH to port Samba4 (an OSS replacement for active directory) from heimdal-krb to mit-krb. Q: the samba4 people have built their AD-surrogate server (cal...) |
|||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | Q: background: i was hired by RH to port Samba4 (an OSS replacement |
||
+ | <pre> |
||
− | + | Q: Background problem: to port Samba4 from Heimdal-krb to MIT-krb. |
|
− | + | Samba4 is an open-source replacement for Active Directory. |
|
− | + | ||
− | + | Foreground problem: |
|
− | the |
+ | * Samba, the AD-surrogate server, uses the Heimdal KDC via a |
− | + | library interface, so that the KDC runs in the same process |
|
− | + | as all of the other AD services (SMB, netlogon, cifs, samr, |
|
− | + | etc). |
|
− | + | * The Samba4 people repeatedly insist that they won't accept |
|
− | + | an MIT integration that doesn't work in exactly the same way. |
|
− | + | * The MIT-krb people respond that spec'ing such a libkdc |
|
− | + | interface, getting approval from the krbdev community, and |
|
− | + | building the libkdc interface will take "a long time". |
|
− | + | ||
− | + | Part of the technical disagreement is two conflicting realities: |
|
− | + | * Unix deployments of MIT-krb take it for granted that you don't |
|
− | + | run non-kdc services on the same box that hosts a kdc; while |
|
− | + | * Samba4 people know that Windows clients inflexibly expect that |
|
− | + | kdc, cifs, netlogon, ntlm, samr, etc all have to be served |
|
− | + | from the same ip-address. |
|
− | + | ||
− | + | So, I'm looking for a better solution. |
|
− | + | Specifically, I believe the Samba4 people are more devoted to |
|
− | + | uniformity than to their libkdc approach; they might accept |
|
− | + | an alternate solution, as long as both MIT-krb & Heimdal kdc |
|
− | + | will work identically with that one solution. So, here's what |
|
− | + | I'm hoping can be made to work: |
|
− | + | * I want to keep the Samba4 kdc (Heimdal or MIT's) in a |
|
− | + | separate process on the Samba-server host; |
|
+ | * When the Samba server catches a client request for AD-style |
||
+ | krb-service, I want the Samba server to pretend that it is |
||
+ | tunnelling the client request to the kdc, via an IPC connection. |
||
+ | * The kdc needs to receive the krb-protocol packets with the |
||
+ | client's source-address intact. in unix krb deployments, |
||
+ | the kdc ignores the client's IP-address for authentication |
||
+ | purposes, but for AD, the kdc usually enforces access-control |
||
+ | on the client's IP-address. |
||
+ | Is there some way to make this pseudo-tunnelled approach work, |
||
without reimplementing the TCP/IP stack? |
without reimplementing the TCP/IP stack? |
||
− | + | I'm told that tun/tap kernel modules might help, but I dunno. |
|
− | + | One asset in my favor: the kdc knows how to deliver krb service |
|
− | via |
+ | via UDP; though AD clients use only TCP-mediated krb-service. |
− | + | ||
− | A: |
+ | A: How about: |
− | + | * iptables redirection: iptables can take a port & redirect it. |
|
− | + | * IPSec can tunnel between machines. |
|
− | + | * xinetd can do redirection and tunneling |
|
− | + | * sshd or stunnel can do it (stunnel might be better than sshd). |
|
− | + | Q: So you're saying, the samba4 server catches (readrecv()) the |
|
− | Q: so you're saying, the samba4 server catches (readrecv()) the |
||
client's kdc-request, and the samba4 server can then tunnel |
client's kdc-request, and the samba4 server can then tunnel |
||
the client's request to the kdc, inside some other IPC- |
the client's request to the kdc, inside some other IPC- |
||
connection protocol, so that the client & the kdc don't know |
connection protocol, so that the client & the kdc don't know |
||
− | about the tunnel? |
+ | about the tunnel? is this easy to set up? |
− | + | A: I was thinking iptables could probably do the proxy work and |
|
− | A: i was thinking iptables could probably do the proxy work and |
||
send the packet to another machine. |
send the packet to another machine. |
||
if that doesn't work, then xinetd might be possible |
if that doesn't work, then xinetd might be possible |
||
− | Q: |
+ | Q: The Samba4 people really-really want everything on one host; |
ease-of-administration is one of their selling-points. |
ease-of-administration is one of their selling-points. |
||
− | A: |
+ | A: The only issue with doing it in iptables is that you have to |
make sure not to delete tha NAT rules when locking down the |
make sure not to delete tha NAT rules when locking down the |
||
system |
system |
||
− | Q: |
+ | Q: But having a host-to-host tunnel solution available for |
krb-admins who want it, would be good from MIT's POV, and |
krb-admins who want it, would be good from MIT's POV, and |
||
might be acceptable to the samba4 people, as non-default |
might be acceptable to the samba4 people, as non-default |
||
behavior. |
behavior. |
||
− | A: |
+ | A: Would the traffic be something you wouldn't want 3rd parties |
to see? in other words, clear text or encrypted? |
to see? in other words, clear text or encrypted? |
||
− | Q: |
+ | Q: Doesn't matter; the krb protocol is GRAS (generally recognized |
as safe). |
as safe). |
||
− | Q: a curlicue is that in unix krb deployments, the kdc ignores |
||
⚫ | |||
− | the client's ip-address for authentication purposes, but for |
||
⚫ | |||
− | AD, the kdc usually enforces access-control on the client's |
||
− | IP-address. this means that the tunnel needs to present the |
||
− | krb-protocol packets to the kdc, with the client's source- |
||
− | address intact. |
||
⚫ | |||
⚫ | |||
deployments; AD users typically deply 1 AD-server per subnet |
deployments; AD users typically deply 1 AD-server per subnet |
||
or per building, so it's rare for an AD server to see heavy |
or per building, so it's rare for an AD server to see heavy |
||
kdc-traffic. |
kdc-traffic. |
||
− | Q: |
+ | Q: In unix-based krb deployments, you usually see 1 master kdc |
& a couple slaves handling a large organization (thousands |
& a couple slaves handling a large organization (thousands |
||
− | of user-accounts). |
+ | of user-accounts). So in unix deployments, performance-hits |
− | + | would be bad. |
|
− | A: |
+ | A: Sounds like kernel-level redirection (iptable-remapping) |
− | + | might be best. you need to use the routing capabilities of |
|
− | + | the linux kernel. |
|
− | + | A: So the samba-server-host would be a router for the kdc port. |
|
− | + | Q: Is this feature universal across linux distros? |
|
− | A: |
+ | A: Yes; linux makes for a very good router; Cisco uses it for |
− | + | low-end models |
|
− | Q: |
+ | Q: Do I have hope of seeing this feature on Solaris or on *bsd? |
− | A: |
+ | A: I think most Unix boxes can act as routers. |
− | A: |
+ | A: What you are wanting to do is to route just one port and |
− | + | leave others alone. |
|
− | + | Q: I think so; I believe the Samba service catches different |
|
− | A: I think most unix can act as routers |
||
− | A: what you are wanting to do is route just one port and leave |
||
− | others alone |
||
− | Q: i think so; i believe the samba service catches different |
||
services on different ports, as usual. |
services on different ports, as usual. |
||
− | A: |
+ | A: If that's the case, it should be easy |
− | Q: |
+ | Q: So you're suggesting that the Samba server can route kdc |
traffic to the kdc, on the same host or on a different host, |
traffic to the kdc, on the same host or on a different host, |
||
in such a way that the client doesn't have to know the kdc's |
in such a way that the client doesn't have to know the kdc's |
||
− | real |
+ | real IP-address / port? |
− | A: |
+ | A: Yes |
− | Q: |
+ | Q: And in such a way that the kdc does see the client's real |
− | + | IP-address, just as if the kdc readrecv()'ed the client's |
|
original kdc-request-packet? |
original kdc-request-packet? |
||
A: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html#ss4.5 |
A: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html#ss4.5 |
||
A: ^^^ might be useful |
A: ^^^ might be useful |
||
− | A: |
+ | A: Now the question is did it make it into iptables mainline by now |
+ | </pre> |
Latest revision as of 14:59, 31 August 2009
Q: Background problem: to port Samba4 from Heimdal-krb to MIT-krb. Samba4 is an open-source replacement for Active Directory. Foreground problem: * Samba, the AD-surrogate server, uses the Heimdal KDC via a library interface, so that the KDC runs in the same process as all of the other AD services (SMB, netlogon, cifs, samr, etc). * The Samba4 people repeatedly insist that they won't accept an MIT integration that doesn't work in exactly the same way. * The MIT-krb people respond that spec'ing such a libkdc interface, getting approval from the krbdev community, and building the libkdc interface will take "a long time". Part of the technical disagreement is two conflicting realities: * Unix deployments of MIT-krb take it for granted that you don't run non-kdc services on the same box that hosts a kdc; while * Samba4 people know that Windows clients inflexibly expect that kdc, cifs, netlogon, ntlm, samr, etc all have to be served from the same ip-address. So, I'm looking for a better solution. Specifically, I believe the Samba4 people are more devoted to uniformity than to their libkdc approach; they might accept an alternate solution, as long as both MIT-krb & Heimdal kdc will work identically with that one solution. So, here's what I'm hoping can be made to work: * I want to keep the Samba4 kdc (Heimdal or MIT's) in a separate process on the Samba-server host; * When the Samba server catches a client request for AD-style krb-service, I want the Samba server to pretend that it is tunnelling the client request to the kdc, via an IPC connection. * The kdc needs to receive the krb-protocol packets with the client's source-address intact. in unix krb deployments, the kdc ignores the client's IP-address for authentication purposes, but for AD, the kdc usually enforces access-control on the client's IP-address. Is there some way to make this pseudo-tunnelled approach work, without reimplementing the TCP/IP stack? I'm told that tun/tap kernel modules might help, but I dunno. One asset in my favor: the kdc knows how to deliver krb service via UDP; though AD clients use only TCP-mediated krb-service. A: How about: * iptables redirection: iptables can take a port & redirect it. * IPSec can tunnel between machines. * xinetd can do redirection and tunneling * sshd or stunnel can do it (stunnel might be better than sshd). Q: So you're saying, the samba4 server catches (readrecv()) the client's kdc-request, and the samba4 server can then tunnel the client's request to the kdc, inside some other IPC- connection protocol, so that the client & the kdc don't know about the tunnel? is this easy to set up? A: I was thinking iptables could probably do the proxy work and send the packet to another machine. if that doesn't work, then xinetd might be possible Q: The Samba4 people really-really want everything on one host; ease-of-administration is one of their selling-points. A: The only issue with doing it in iptables is that you have to make sure not to delete tha NAT rules when locking down the system Q: But having a host-to-host tunnel solution available for krb-admins who want it, would be good from MIT's POV, and might be acceptable to the samba4 people, as non-default behavior. A: Would the traffic be something you wouldn't want 3rd parties to see? in other words, clear text or encrypted? Q: Doesn't matter; the krb protocol is GRAS (generally recognized as safe). A: xinetd would add some overhead. Q: I believe kdc performance isn't a critical issue in Samba deployments; AD users typically deply 1 AD-server per subnet or per building, so it's rare for an AD server to see heavy kdc-traffic. Q: In unix-based krb deployments, you usually see 1 master kdc & a couple slaves handling a large organization (thousands of user-accounts). So in unix deployments, performance-hits would be bad. A: Sounds like kernel-level redirection (iptable-remapping) might be best. you need to use the routing capabilities of the linux kernel. A: So the samba-server-host would be a router for the kdc port. Q: Is this feature universal across linux distros? A: Yes; linux makes for a very good router; Cisco uses it for low-end models Q: Do I have hope of seeing this feature on Solaris or on *bsd? A: I think most Unix boxes can act as routers. A: What you are wanting to do is to route just one port and leave others alone. Q: I think so; I believe the Samba service catches different services on different ports, as usual. A: If that's the case, it should be easy Q: So you're suggesting that the Samba server can route kdc traffic to the kdc, on the same host or on a different host, in such a way that the client doesn't have to know the kdc's real IP-address / port? A: Yes Q: And in such a way that the kdc does see the client's real IP-address, just as if the kdc readrecv()'ed the client's original kdc-request-packet? A: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html#ss4.5 A: ^^^ might be useful A: Now the question is did it make it into iptables mainline by now