Difference between revisions of "Samba4 Port: iptables Remapping"
From K5Wiki
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
<pre> |
<pre> |
||
− | Q: Background problem |
+ | Q: Background problem: to port Samba4 from Heimdal-krb to MIT-krb. |
− | + | Samba4 is an open-source replacement for Active Directory. |
|
− | The Samba4 people have built their AD-surrogate server |
||
+ | Foreground problem: |
||
− | + | * Samba, the AD-surrogate server, uses the Heimdal KDC via a |
|
− | interface, so that the KDC runs in the same process |
+ | library interface, so that the KDC runs in the same process |
− | the other AD services (SMB, netlogon, cifs, samr, |
+ | 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: |
Part of the technical disagreement is two conflicting realities: |
||
− | * Unix deployments of MIT-krb take it for granted that you |
+ | * 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 |
|
− | while |
||
* Samba4 people know that Windows clients inflexibly expect that |
* Samba4 people know that Windows clients inflexibly expect that |
||
kdc, cifs, netlogon, ntlm, samr, etc all have to be served |
kdc, cifs, netlogon, ntlm, samr, etc all have to be served |
||
Line 21: | Line 21: | ||
So, I'm looking for a better solution. |
So, I'm looking for a better solution. |
||
Specifically, I believe the Samba4 people are more devoted to |
Specifically, I believe the Samba4 people are more devoted to |
||
− | uniformity than to their libkdc approach; they might accept |
+ | uniformity than to their libkdc approach; they might accept |
− | alternate solution, as long as both MIT-krb & Heimdal kdc |
+ | an alternate solution, as long as both MIT-krb & Heimdal kdc |
− | work identically with that one solution. |
+ | 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 |
* I want to keep the Samba4 kdc (Heimdal or MIT's) in a |
||
separate process on the Samba-server host; |
separate process on the Samba-server host; |
||
Line 30: | Line 30: | ||
krb-service, I want the Samba server to pretend that it is |
krb-service, I want the Samba server to pretend that it is |
||
tunnelling the client request to the kdc, via an IPC connection. |
tunnelling the client request to the kdc, via an IPC connection. |
||
− | * A curlicue is that in unix krb deployments, the kdc ignores |
||
+ | * 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. |
|
− | address intact. |
||
Is there some way to make this pseudo-tunnelled approach work, |
Is there some way to make this pseudo-tunnelled approach work, |
||
without reimplementing the TCP/IP stack? |
without reimplementing the TCP/IP stack? |
||
Line 42: | Line 42: | ||
A: How about: |
A: How about: |
||
− | * iptables redirection: |
+ | * iptables redirection: iptables can take a port & redirect it. |
− | + | * IPSec can tunnel between machines. |
|
− | * xinetd can |
+ | * xinetd can do redirection and tunneling |
* sshd or stunnel can do it (stunnel might be better than sshd). |
* 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 |
||
Line 67: | Line 67: | ||
Q: Doesn't matter; the krb protocol is GRAS (generally recognized |
Q: Doesn't matter; the krb protocol is GRAS (generally recognized |
||
as safe). |
as safe). |
||
− | A: xinetd |
+ | A: xinetd would add some overhead. |
Q: I believe kdc performance isn't a critical issue in Samba |
Q: I believe kdc performance isn't a critical issue in Samba |
||
deployments; AD users typically deply 1 AD-server per subnet |
deployments; AD users typically deply 1 AD-server per subnet |
||
Line 76: | Line 76: | ||
of user-accounts). So in unix deployments, performance-hits |
of user-accounts). So in unix deployments, performance-hits |
||
would be bad. |
would be bad. |
||
− | A: Sounds like kernel-level redirection |
+ | A: Sounds like kernel-level redirection (iptable-remapping) |
− | + | might be best. you need to use the routing capabilities of |
|
− | + | the linux kernel. |
|
− | linux kernel. |
||
A: So the samba-server-host would be a router for the kdc port. |
A: So the samba-server-host would be a router for the kdc port. |
||
Q: Is this feature universal across linux distros? |
Q: Is this feature universal across linux distros? |
||
− | A: Yes; linux makes for a very good router |
+ | 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? |
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: I think most Unix boxes can act as routers. |
A: What you are wanting to do is to route just one port and |
A: What you are wanting to do is to route just one port and |
||
leave others alone. |
leave others alone. |
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