Re: Samba Login Script in LDAP

["Mark H. Wood" <mwood@IUPUI.Edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 29 Aug 2003, Adam Williams wrote:
> > > > Define an attribute to store the script,  if you don't
> > > > have an OID I'm willing to define one for you - since
> > > > this sounds like not a half-bad idea.
> > > Adam, I have an OID to define this attribute, my tree OID's is
> > > this:
> > > 1.3.6.1.4.1.17307 - Tribunal Regional do Trabalho da 15ª Região
> > > 1.3.6.1.4.1.17307.1 - LDAP Elements
> > > 1.3.6.1.4.1.17307.1.1 - LDAP Attributes
> > > and the OID for this new login script attribute can be
> > > 1.3.6.1.4.1.17307.1.1.3
> > > But my big problem is, how I define a text attribute. I don't
> > > know the attribute definition format. Can somebody help me ?
> > Your big problem is that Windows doesn't know what to do with this
> > attribute.
>
> Who cares what Windows knows,  Samba feeds Windows the logon script.
> Samba can manifest the script from LDAP - Samba can do 'pert near
> anything you can imagine.  All he has to do is make a preexec to
> manifest the file.  There are lots of systems for generating managing
> logon scripts with Samba floating around.

All that work, when the file could simply be stored on a share in the
server exactly the way Windows expects it to be, and for which all of the
code already exists.

I'm running Samba 3.0 beta right now, and appreciate what it can do.

> >  The login script code expects a path to a file.  Even in ADS,
> > native login scripts are stored as files tucked away in the DC's sysvol
> > under some horrible GUID-named directory and legacy scripts still live in
> > the same NETLOGON share they always did.
>
> So, he just creates the file from the LDAP value attribute before the
> client connects to the share.  He could remove it when they disconnect
> if he wanted to (postexec).

True, but I'm still waiting to hear *why* all this extra effort is useful.

> > Likewise NDS stores login scripts as separate "stream files".  IIRC it
> > makes them look like arbitrarily large string-valued attributes and NDS
> > clients know to ask for them that way.  But I'm not aware of any
> > directory-enabled logon thingy that doesn't keep the scripts as individual
> > files, no matter how they are presented.
>
> And he is about to create one!  Open Source is amazing.

You are preaching to the choir.  But I'll be interested to see if there is
any actual advantage to this.

> > It would be interesting to know what you expect to gain from all this
> > effort.  The UMich LDAP list is probably a better place for that
> > discussion.
>
> I think the Samba list is a better place for this discussion.  I think
> he's going to gain manageability.  He can edit the logon script via en
> LDAP enabled UI verses hacking directly on the server's text file.  He
> wouldn't even need direct access to the PDC (which is always a good
> thing to limit ruthlessly).

See my discussion of NDS?  I'm quite familiar with being required to use a
particular LDAP-enabled specialty editor, as opposed to crafting files
using my preferred editor in my preferred environment.  You see, there are
(at least) two ways to look at this.  Consider not only what you get, but
what you trade away for it.

[tap, tap] Okay, I found an 'ldap.el' that looks promising -- maybe I
*can* use a civilized editor on text BLOBs stored in a directory service.
But can I 'egrep' them? 'sed' them? crank new ones out automagically via a
DBMS' report writer?

- -- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQE/VK7hs/NR4JuTKG8RAtHMAJ4txjAMf1eL29Xpn9A82ilFgg/2EACfWkvJ
9sl5FmPsoiAEv6G9ZP5c2ZQ=
=FFEl
-----END PGP SIGNATURE-----