[Zope] RE: [Zope-dev] GenericUserFolder available for beta

[Ian Blenke]

This thread seems to be applicable to the Zope list as a whole. Should we
Cc: the rest of the list at some point? Feel free to cut away any of my
useless banter below. :)

On Thur, 18 Nov 1999, Stuart 'Zen' Bishop wrote:

> On Wed, 17 Nov 1999, Ian Blenke wrote:
> 
> > 1. The README and installation guides may have a minor typo
(<dtml-return
> > - then what? :)
> 
> Oops :-)

No biggie. A minor oversight :)

> <dtml-return "MyRadius(username=username,password=password)">

Excellent! This was rather important :)

Unfortunately, the page still seems to be "locked"

> > 2. Whenever I add GenericUserFolder to a folder, the folder becomes
> > "locked".
> 
> Locked as in you can no longer view the contents of the folder?

Exactly that. In fact, I can no longer "manage" that folder either. I can
repetitively login, but it always returns with a Login:/Password: prompt
(and management of the page is impossible)

> > 1. What should go after <dtml-return in the userAuthentication method?
Even
> > a <dtml-return 1> doesn't seem to help.
> 
> <dtml-return "_.int('1')">
> 
> I'm explicity checking for a numeric 1, rather than normal truth checking.
> I do this, as otherwise it would be too easy to stuff up and write 
> <dtml-return 0> which would probably evaluate to true (possibly being
> a string and all, or a zope object with an id of '0' that was aquired, 
> or something).

Ouch. That would be bad :) Trying the above workaround, I am still unable
to manage the folder after using GenericUserFolder - so I'm still doing
something wrong.

> > 2. How do I use ZRadius to authenticate with a GenericUserFolder? (and
tie a
> > login to a Role)
> > 3. How could I implement "groups" of users and tie them to Roles using
> > ZRadius?
> 
> ZRadius is not intelligent enough to determine a type of user from
> a Radius server... and I don't know enough about Radius to know if it
> is possible... I know how to put the packets together now, but most
> of those attribute names are fairly meaningless to me ;-) A brief
> glance at RFC2138 gives me the impressions that Radius does not support
> the notion of groups in anyway.

Nope. It sure doesn't. The Microsoft RADIUS server isn't going to pass back
an attribute for user groups regardless of how hard I try :)

> I'm pulling my groups from another source - an Oracle database in my case
-
> from which all my accounts are generated.

The best bet is to make up my own TinyTables/SQL tables/LDAP source to 
correlate the login to appropriate groups.

> You could pull groups out of /etc/groups and /etc/password in the final
> instalation, if the NT users are duplicated on the Unix box.

No such luck. I have pam_smb working (so a PAM enabled Zope authentication
Product would be nice), however there is no good solution for an NSS
"interworking" piece without LDAP. One solution might be to use the
Microsoft
"Unix Integration Kit" to get NIS /etc/passwd and/or /etc/group maps to pass
through - but this would still require an NSS friendly Zope User Folder 
Product.

Simply put: 

 1. etcUserFolder isn't going to work against an NT Domain - ever.
 2. NTUserFolder will only work against an NT Domain if you run Zope from
    a BDC or PDC (local SAM database).
 3. smbuserfolder only works under Linux/Solaris, with a Python 
    hand-compiled smb_valid module (with pam_smb in your environment)
 4. ZRadius/GenericUserFolder/ZLDAPConnection is the ONLY authentication
    solution for an NT Domain that can run under either NT or any
    flavor of Unix - given Microsoft's current authentication model
    (PDC/BDC frontended by RADIUS, and an Exchange directory server)

Getting ldap_nss to "interwork" with the Microsoft Exchange server isn't
a trivial task (see below :) This isn't necessarily a Bad Thing(TM).
(using NSS/PAM with win32 is a fairly moot point at present)

When Active Directory Services are available (give it 8-12 months before
people start actively using it), perhaps a true LDAP environment may be
feasible.

> You could authenticate using Radius, and use the samba tools to pull
> group information (or do groups and authentication using the samba tools).
> Similar to smbfolder, which I havn't played with so I couldn't tell you
> which one is better.

Unfortunately, smbfolder isn't a simple thing to get working. You need
to patch your Python distribution to build the smb_valid module. To get
the smb_valid module working, you need to have pam_smb built as well.

We have pam_smb built. I've built smb_valid as well. The big pain is getting
this cludge to work *reliably*.

More importantly: this approach WILL NOT WORK under win32. This doesn't
concern me as much as it does everyone else here - but I still need to
keep the site as platform-neutral as possible.

> You could try running an LDAP server instead of a RADIUS server, and
> either use LDAPAuthenticatior or GenericUserFolder + LDAP - LDAP should
> allow both authentication and group membership direct from the NT Domain
> if you can find a decent LDAP server for NT that doesn't turn your brain
> to mush when you try and configure it (I decided to stick with Radius
after
> skimming the OpenLDAP docs...).

We have an LDAP server as part of our Exchange 5.5 server. Granted, it is 
a useful repository of user information - but it doesn't contain the {crypt}
passwords neccesary to get it to work with LDAPAuthenticator. This isn't a
problem when you hook it together with your ZRadius product, however.

The best part about the LDAP/RADIUS solution: it is 100% cross-platform!

I have a working ZLDAPConnection pulling information from our Exchange LDAP
server. Your ZRadius Product is reliably authenticating usernames/passwords
every time. Both of these are working from both a win32 server as well as
the Solaris 7.0 box. 

My biggest problem still remains: how do I get GenericUserFolder to work?
(I still need to tie Zope "Roles" to these authenticated users)

If you could throw together a "viable" working *.zexp showing what I'm
doing wrong, I would greatly appreciate it! If not, anything you can
suggest would help a great deal as well.

Thanks!

- Ian C. Blenke <icblenke@2c2.com>