Le ven 03/10/2003 � 16:31, Buchan Milne a �crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> FACORAT Fabrice wrote:
> > Thanks to drakauth we can easily change auth method and even specify
> > auth method during installation. So setting a client is easy. This is
> > possible because PAM give use flexibility.
> 
> BTW, drakauth is not complete. I have been working with Pixel on some
> aspects of preparing for AD support (which involves kerberos, so if
> someone has a Unix kerberos setup to test that could probably be
> supported quite easily too). Also, we want to test with pam_ldap and
> kerberos finding the servers via DNS (both support it), we just need to
> do the work for doing the DNS queries to see if we need to hardcode
> anything or not.

:( sorry. I'm using NIS  ... yeah, I know, but when I try to set up LDAP
( mdk 9.0 ) it failed and I lost 2 days trying to do it without using
source. At the end I decide to use NIS ...

> > 1�/ user management.
> > - you can just migrate previously created user in /etc/passwd thanks to
> > userdrake
> 
> userdrake isn't the best way to do this. migration-tools is (IMHO), and
> I have a small script as prototype.

just click "migrate infos", and userdrake will call the script with all
the needed informations.

> > 2�/ server configuration :
> > Now, when you want to set up a LDAP server you have several manipulation
> > to do ( http://www.mandrakesecure.net/en/docs/ldap-auth2.php ). This
> > wizard should do all necessary steps ( ACL, ask for users migration from
> > /etc/passwd, ... ) and just ask for needed information.
> 
> Some of this can possibly be simplified using regex-based ACLs.
> 
> For kerberos+ldap, we also need mapping to SASL (which I have looked at
> briefly but not tested).
> 
> For LDAP setup, you would also want to do things like:
> - -setup an LDAP slave (this takes a number of steps to do, although I
> think I have a working method)

for 10.1 ? let's begin with a rock solid base first ... no ?

> - -add more schema files (this is non-trivial, as the schema files must be
> enabled on all LDAP servers before you add any attributes from the
> schema files). Schemas are also about the only thing that can't be done
> via LDAP ;-).
> - -referral and delegation support.
> - -Kerberos support for authentication of the master to the slaves for
> updates (we currently use randomly generated passwords, but Kerberos
> would be better, however then the tickets need to be renewed also).
> 
> Of course, you would want to TLS/SSL the whole thing, which also means
> we need certificate management (since OpenLDAP with TLS now wants to
> have a verfiable cert for TLS). And for TLS/SSL to work right, you also
> need working DNS ...
> 
> For kerberos, we need working NTP also, ideally ntpd should be able to
> find it's time server via DHCP or DNS (it has support for neither, so
> maybe some script needs to check for this).

wow !

> >
> > 3�/ directory export ( NFS/SMB ).
> > we can easily set remotes share thanks to diskdrake, but we don't have
> > the server part.
> 
> You can export shares from Konqueror and Nautilus. Also check out
> ksambaplugin, and swat-clone from perl-Libconf CVS.

it's for directory in personal directory.


> > select directory to export, set ACL ( options, authorized hosts ).
> 
> ACLs should be set in the filesystem instead (even MS "best practices"
> say so).

I misused a word. It's not ACL but permissions, see /etc/exports

/home/mygroup  192.168.1.2(rw,nosuid)

> Try the directory-properties thing from ksambaplugin. It can do all this
> for samba shares.

This need to be done by the wizard, be integrated at least for basic
stuff. For more advance settings, you can use whatever you want (
vi/emacs/joe/ksambaplugin/webmin/.... )

--- 
Les chats irradies ont-ils 18 demi-vies ?


Reply via email to