[PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS - Samba

This is a discussion on [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS - Samba ; After some experiments and with the help of Samba 4 code, I have finally made a Windows workstation join Samba 3.2 ADS controller. The job isn't nearly complete, and the workstation doesn't see the domain after reboot. But that's the ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS

  1. [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS

    After some experiments and with the help of Samba 4 code, I have finally made
    a Windows workstation join Samba 3.2 ADS controller.

    The job isn't nearly complete, and the workstation doesn't see the domain
    after reboot. But that's the next story. I used stock OpenLDAP and MIT
    Kerberos packages from Debian/unstable. The configuration was typical, the
    only addition was to use wrappers around smbldap-useradd/del to call kadmin
    to add/remove users, and usage of kadmin -k -q "cpw %u" as a passwd program.
    To make make kadmin work, I've added host/fqdn@REALM.ORG to kadm.acl

    I also tried Samba 4. It is good at managing Windows worstations in simple
    SSO setup! And python bindings are awesome. However, it is very difficult
    to manage linux services with it. Both ldap and kerberos system services are
    hidden behind ADS-like interface, and even getting host/fqdn keytabs to make
    ssh work isn't a trivial task.

    Since the patch will probably be reviewed by the person, who knows the answer,
    a question:

    How hard is it to use separate Kerberos and LDAP servers?

    There are definite technical challenges for this, but the current design,
    IMHO, will hamper Samba 4 adoption. Samba 3 is a good linux citizen, it obeys
    the laws and leverages advances in other products. But Samba 4 enforces
    Windows rules. F.e., to allow ssh on a host, the host must join domain.


    Sergey Yanovich (2):
    nmbd: fix netlogon in ads mode
    rpc: allow trailing dollar sign in user names

    source/nmbd/nmbd_processlogon.c | 46 ++++++++++++++++++++++-----------------
    source/rpc_server/srv_samr_nt.c | 6 ++--
    source/smbd/chgpasswd.c | 6 +++-
    3 files changed, 33 insertions(+), 25 deletions(-)


  2. [PATCH 2/2] rpc: allow trailing dollar sign in user names


    Signed-off-by: Sergey Yanovich
    ---
    source/rpc_server/srv_samr_nt.c | 6 +++---
    source/smbd/chgpasswd.c | 6 ++++--
    2 files changed, 7 insertions(+), 5 deletions(-)

    diff --git a/source/rpc_server/srv_samr_nt.c b/source/rpc_server/srv_samr_nt.c
    index a89e00f..e35a0f6 100644
    --- a/source/rpc_server/srv_samr_nt.c
    +++ b/source/rpc_server/srv_samr_nt.c
    @@ -3964,9 +3964,9 @@ static bool set_user_info_pw(uint8 *pass, struct samu *pwd,
    }

    /* if it's a trust account, don't update /etc/passwd */
    - if ( ( (acct_ctrl & ACB_DOMTRUST) == ACB_DOMTRUST ) ||
    - ( (acct_ctrl & ACB_WSTRUST) == ACB_WSTRUST) ||
    - ( (acct_ctrl & ACB_SVRTRUST) == ACB_SVRTRUST) ) {
    + if ((lp_security() != SEC_ADS) &&
    + (acct_ctrl & (ACB_DOMTRUST | ACB_WSTRUST | ACB_SVRTRUST)))
    + {
    DEBUG(5, ("Changing trust account or non-unix-user password, not updating /etc/passwd\n"));
    } else {
    /* update the UNIX password */
    diff --git a/source/smbd/chgpasswd.c b/source/smbd/chgpasswd.c
    index 2596e73..423bd32 100644
    --- a/source/smbd/chgpasswd.c
    +++ b/source/smbd/chgpasswd.c
    @@ -594,7 +594,8 @@ the string %%u, and the given string %s does not.\n", passwordprogram ));
    }
    }

    - passwordprogram = talloc_string_sub(ctx, passwordprogram, "%u", name);
    + passwordprogram = talloc_string_sub2(ctx, passwordprogram, "%u", name,
    + true, false, true);
    if (!passwordprogram) {
    return false;
    }
    @@ -603,7 +604,8 @@ the string %%u, and the given string %s does not.\n", passwordprogram ));
    as this would open up a security hole where the user could use
    a new password containing shell escape characters */

    - chatsequence = talloc_string_sub(ctx, chatsequence, "%u", name);
    + chatsequence = talloc_string_sub2(ctx, chatsequence, "%u", name, true,
    + false, true);
    if (!chatsequence) {
    return false;
    }
    --
    1.5.5.1


  3. Re: [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS

    On Wed, Jun 04, 2008 at 01:48:03AM +0300, Sergey Yanovich wrote:
    > After some experiments and with the help of Samba 4 code, I have finally made
    > a Windows workstation join Samba 3.2 ADS controller.
    >
    > The job isn't nearly complete, and the workstation doesn't see the domain
    > after reboot. But that's the next story. I used stock OpenLDAP and MIT
    > Kerberos packages from Debian/unstable. The configuration was typical, the
    > only addition was to use wrappers around smbldap-useradd/del to call kadmin
    > to add/remove users, and usage of kadmin -k -q "cpw %u" as a passwd program.
    > To make make kadmin work, I've added host/fqdn@REALM.ORG to kadm.acl
    >
    > I also tried Samba 4. It is good at managing Windows worstations in simple
    > SSO setup! And python bindings are awesome. However, it is very difficult
    > to manage linux services with it. Both ldap and kerberos system services are
    > hidden behind ADS-like interface, and even getting host/fqdn keytabs to make
    > ssh work isn't a trivial task.
    >
    > Since the patch will probably be reviewed by the person, who knows the answer,
    > a question:
    >
    > How hard is it to use separate Kerberos and LDAP servers?
    >
    > There are definite technical challenges for this, but the current design,
    > IMHO, will hamper Samba 4 adoption. Samba 3 is a good linux citizen, it obeys
    > the laws and leverages advances in other products. But Samba 4 enforces
    > Windows rules. F.e., to allow ssh on a host, the host must join domain.


    Oooooohhhh ! Oooooohhhhh !!!!!

    I'm excited :-). Please send in all these patches asap !!!!

    Thanks a *LOT* for this work.

    Jeremy.


  4. Re: [PATCH 1/2] nmbd: fix netlogon in ads mode

    On Wed, 2008-06-04 at 01:48 +0300, Sergey Yanovich wrote:
    > Signed-off-by: Sergey Yanovich


    This code ('fixing' Samba3's nmbd handling of ADS-style netlogon
    mailslots) should be removed, not fixed up...

    The recent work I've done in Samba4 shows that this area is far more
    complex than this first attempt makes out, and must be in common with
    the CLDAP server to have any chance of being correct.

    Why are you trying to patch Samba3 for this?

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIRcv6z4A8Wyi0NrsRAo5WAJ9gkpCAE6NiKJj3MIu+Bl RKAZoofACeKpLN
    sYl1nIfynu5JYttak4klTmc=
    =CoNX
    -----END PGP SIGNATURE-----


  5. Re: [PATCH 1/2] nmbd: fix netlogon in ads mode

    Andrew Bartlett wrote:
    > On Wed, 2008-06-04 at 01:48 +0300, Sergey Yanovich wrote:
    >> Signed-off-by: Sergey Yanovich

    >
    > This code ('fixing' Samba3's nmbd handling of ADS-style netlogon
    > mailslots) should be removed, not fixed up...
    >
    > The recent work I've done in Samba4 shows that this area is far more
    > complex than this first attempt makes out, and must be in common with
    > the CLDAP server to have any chance of being correct.


    With this patch Samba 3 fools Windows client to thinking it talks to
    ADS. So the external part is correct. I agree, that internals are not so
    easy, and that's why the workstation doesn't see the domain after reboot.

    > Why are you trying to patch Samba3 for this?


    Samba 4 overtakes ports 88, 389, 636. Established linux infrastructure
    isn't working with it. Configuring linux client/services to live with
    Samba 4 isn't a trivial task also...

    --
    Sergey Yanovich


  6. Re: [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS

    On Wed, 2008-06-04 at 01:48 +0300, Sergey Yanovich wrote:
    > After some experiments and with the help of Samba 4 code, I have finally made
    > a Windows workstation join Samba 3.2 ADS controller.


    How did you make it think it was ADS? In our early research, we found
    ADS was either an 'on' or 'off' thing - particularly if you support the
    new call on the LSA pipe, then you must start supporting an lot more.

    > The job isn't nearly complete, and the workstation doesn't see the domain
    > after reboot. But that's the next story. I used stock OpenLDAP and MIT
    > Kerberos packages from Debian/unstable. The configuration was typical, the
    > only addition was to use wrappers around smbldap-useradd/del to call kadmin
    > to add/remove users, and usage of kadmin -k -q "cpw %u" as a passwd program.
    > To make make kadmin work, I've added host/fqdn@REALM.ORG to kadm.acl
    >
    > I also tried Samba 4. It is good at managing Windows worstations in simple
    > SSO setup! And python bindings are awesome. However, it is very difficult
    > to manage linux services with it. Both ldap and kerberos system services are
    > hidden behind ADS-like interface, and even getting host/fqdn keytabs to make
    > ssh work isn't a trivial task.
    >
    > Since the patch will probably be reviewed by the person, who knows the answer,
    > a question:
    >
    > How hard is it to use separate Kerberos and LDAP servers?


    Difficult enough that I've spend the last 4 years working on Samba4. We
    know it's possible (see XAD for the proof by example), but the approach
    currently taken was very deliberate.

    > There are definite technical challenges for this, but the current design,
    > IMHO, will hamper Samba 4 adoption. Samba 3 is a good linux citizen, it obeys
    > the laws and leverages advances in other products. But Samba 4 enforces
    > Windows rules. F.e., to allow ssh on a host, the host must join domain.


    I have no objection to allowing 'normal' Kerberos authentication to
    Samba4. It is a trivial extension to gensec_gssapi - indeed the main
    challenge is just to decide how to map the resultant users, which is a
    challenge Samba3 shares.

    I commend you on your efforts, but the reason that this area was left at
    a stub in Samba3 was that the full scope of the problem was realised.

    As a Samba4 developer I would encourage you to help us make Samba4 work
    better for your use cases (a python script to export host/fqdn keytabs
    would be very easy to write) than to continue down this rat-hole.

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIRc5cz4A8Wyi0NrsRAgXeAKCvJZOfy3NQ/zoiu2TQiEq2/WI07QCdF7pL
    ehOvqozEtdHnuW9KoZzF5Ks=
    =1/Oc
    -----END PGP SIGNATURE-----


  7. Re: [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS

    Andrew Bartlett wrote:
    > On Wed, 2008-06-04 at 01:48 +0300, Sergey Yanovich wrote:
    >> After some experiments and with the help of Samba 4 code, I have finally made
    >> a Windows workstation join Samba 3.2 ADS controller.

    >
    > How did you make it think it was ADS?


    I am not 100% sure, but I saw with the wireshark that the client was
    using my kerberos tickets.

    In our early research, we found
    > ADS was either an 'on' or 'off' thing - particularly if you support the
    > new call on the LSA pipe, then you must start supporting an lot more.


    It is true, but probably relates to after-join phase.

    >> How hard is it to use separate Kerberos and LDAP servers?

    >
    > Difficult enough that I've spend the last 4 years working on Samba4. We
    > know it's possible (see XAD for the proof by example), but the approach
    > currently taken was very deliberate.


    > As a Samba4 developer I would encourage you to help us make Samba4 work
    > better for your use cases (a python script to export host/fqdn keytabs
    > would be very easy to write) than to continue down this rat-hole.


    Now I know, it is rat hole IIUC, Samba 4 was using its own python
    until recently. In other words, there are precedents for decoupling
    external components. Maybe KDC is the next in the queue? Samba can talk
    to kadm using normal kadmin interface, so it will be possible to use
    normal *nix way of administering KADM/KDC. MIT Kerberos has a plugin to
    store keys in LDAP, and this can handle canonicalization. So the only
    big peace of work is PAC, right?

    I am working an FOSS accounting package in Russia, and I plan to deploy
    it in an company with obsolete Windows infrastructure. My interest was
    to find out smooth transition path from a poorly managed W2K ADS to the
    linux domain. Samba 4 looks promising for the matter.

    --
    Sergey Yanovich


  8. Re: [PATCH 1/2] nmbd: fix netlogon in ads mode

    On Wed, 2008-06-04 at 02:05 +0300, Sergey Yanovich wrote:
    > Andrew Bartlett wrote:
    > > On Wed, 2008-06-04 at 01:48 +0300, Sergey Yanovich wrote:
    > >> Signed-off-by: Sergey Yanovich

    > >
    > > This code ('fixing' Samba3's nmbd handling of ADS-style netlogon
    > > mailslots) should be removed, not fixed up...
    > >
    > > The recent work I've done in Samba4 shows that this area is far more
    > > complex than this first attempt makes out, and must be in common with
    > > the CLDAP server to have any chance of being correct.

    >
    > With this patch Samba 3 fools Windows client to thinking it talks to
    > ADS. So the external part is correct. I agree, that internals are not so
    > easy, and that's why the workstation doesn't see the domain after reboot.


    Indeed!

    > > Why are you trying to patch Samba3 for this?

    >
    > Samba 4 overtakes ports 88, 389, 636. Established linux infrastructure
    > isn't working with it. Configuring linux client/services to live with
    > Samba 4 isn't a trivial task also...


    Sure - there isn't a way to avoid this, except to use seperate IP
    addresses. If we could use a stock KDC, then we would have. I'm sure
    an enterprising programmer could probably make Heimdal load the PAC
    generating plugin, and an AD-compatible hdb backend (because that's what
    we do internally anyway), but then it's not a stock KDC any more.

    Fortunately the services linux clients require of a KDC is a subset of
    those our modified Heimdal provides.

    We bundle the KDC because given the high degree of linkage required, we
    felt it was easier to have it 'just work' than the traditional linux
    nightmare to setup Kerberos and LDAP. (We also have an internal
    implementation of kpasswd).

    LDAP is a much more difficult question - windows client require the AD
    schema be loaded,and while we have a project to allow us to map Samba4's
    requirements onto standard-ish LDAP schema (on an external LDAP server),
    we have no choice but to present an AD-like view to AD clients such as
    Windows XP.

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIRdgMz4A8Wyi0NrsRAguCAJwLyKN9VBRRG1YNqGcZZi bJyCQaSwCeJw18
    1Iz+A04RpShl2nyTaBsSJgA=
    =FXBY
    -----END PGP SIGNATURE-----


  9. Re: [PATCH 0/2] Allow Windows XP SP 2 to join Samba 3.2 ADS

    On Wed, 2008-06-04 at 02:34 +0300, Sergey Yanovich wrote:
    > Andrew Bartlett wrote:
    > > On Wed, 2008-06-04 at 01:48 +0300, Sergey Yanovich wrote:
    > >> After some experiments and with the help of Samba 4 code, I have finally made
    > >> a Windows workstation join Samba 3.2 ADS controller.

    > >
    > > How did you make it think it was ADS?

    >
    > I am not 100% sure, but I saw with the wireshark that the client was
    > using my kerberos tickets.


    Given that your KDC was not generating the PAC, windows clients can't
    use it for logon. They certainly could use it in the join - but that
    isn't really the interesting part.

    > In our early research, we found
    > > ADS was either an 'on' or 'off' thing - particularly if you support the
    > > new call on the LSA pipe, then you must start supporting an lot more.

    >
    > It is true, but probably relates to after-join phase.


    One consequence of this is that as soon as you pretend to be AD, your
    NT4 system policy files are no longer applied, and you must use group
    policy. This requires an AD-like LDAP...

    > >> How hard is it to use separate Kerberos and LDAP servers?

    > >
    > > Difficult enough that I've spend the last 4 years working on Samba4. We
    > > know it's possible (see XAD for the proof by example), but the approach
    > > currently taken was very deliberate.

    >
    > > As a Samba4 developer I would encourage you to help us make Samba4 work
    > > better for your use cases (a python script to export host/fqdn keytabs
    > > would be very easy to write) than to continue down this rat-hole.

    >
    > Now I know, it is rat hole IIUC, Samba 4 was using its own python
    > until recently.


    We never used our own python - it was always the system python, but to
    ensure the Samba libraries were found until we got all the shared
    libraries working we linked them staticly against a 3-line program
    called 'smbpython', which called python's own 'main()'.

    > In other words, there are precedents for decoupling
    > external components. Maybe KDC is the next in the queue? Samba can talk
    > to kadm using normal kadmin interface, so it will be possible to use
    > normal *nix way of administering KADM/KDC. MIT Kerberos has a plugin to
    > store keys in LDAP, and this can handle canonicalization. So the only
    > big peace of work is PAC, right?


    The MIT plugin design is a disaster. But yes, as per my other mail you
    could probably build a Samba4 Heimdal plugin, should you wish to.

    > I am working an FOSS accounting package in Russia, and I plan to deploy
    > it in an company with obsolete Windows infrastructure. My interest was
    > to find out smooth transition path from a poorly managed W2K ADS to the
    > linux domain. Samba 4 looks promising for the matter.


    Great.

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIRdlnz4A8Wyi0NrsRAn7LAKCnP7GfGSoQy/V6UDSX5n4OyCu6wgCdG4hv
    gbBz2ROuuyDmxNqg3SlF+6o=
    =CtJu
    -----END PGP SIGNATURE-----


+ Reply to Thread