RE: [Zope-dev] GenericUserFolder available for beta
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.
I'm pulling my groups from another source - an Oracle database in my case
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 :) -
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>
On Thu, 18 Nov 1999, Ian Blenke wrote:
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)
What appears to be happening is that although the Zope superuser will retain manage rights over the GUF, users defined within Zope and granted the Manage role will not. I'll be looking into this tomorrow (I got a deadline today, and still an hours worth of email to read :-) ) and will hopefully release a new beta for Monday.
My biggest problem still remains: how do I get GenericUserFolder to work? (I still need to tie Zope "Roles" to these authenticated users)
Try accessing the contents of the GUF when logged in as the Zope supervisor (if you arn't already). I think this is my dodgy workaround in validate() biting me which was due to be looked at again, or something I don't understand about the 'aquire permissions' settings that I've documented.
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.
When you create a new GUF, it should be viable. Have a look at the templates that are copied into the new installation (GenericUserFolder/templates/dumb). If you want, you can modify the default userRoles.dtml code to return 'Manager' (and change userAuthenticate.dtml and userList.dtml if you like). -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
Ian Blenke wrote
[snip]
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
[snip] There is one, but it doesn't seem to have been noticed. Or, more correctly, the first draft of what we're using in-house is available at http://www.zope.org/Members/bwarff. It's in a pretty rough form there (it's basically a cut'n'paste from etcUserFolder, or thereabouts), we'll chuck the slightly cleaned up version up there if people are interested. The cleaned up version checks a file first for the user, if it's there, it pam-auths as given, if it's not there, it appends a default domain name, and auths that way - we're using it to get radius auth for a soon-to-be-public site. We're going to make the default domain optional rather than compulsory and move the list of users into the module, rather than storing it on-disk. KevinL
participants (3)
-
Ian Blenke -
Kevin Littlejohn -
Stuart 'Zen' Bishop