diff options
Diffstat (limited to 'docs/textdocs')
| -rw-r--r-- | docs/textdocs/BROWSING.txt | 17 | ||||
| -rw-r--r-- | docs/textdocs/HINTS.txt | 3 | ||||
| -rw-r--r-- | docs/textdocs/Printing.txt | 2 | ||||
| -rw-r--r-- | docs/textdocs/Samba-OpenSSL.txt | 405 | ||||
| -rw-r--r-- | docs/textdocs/Solaris-Winbind-HOWTO.txt | 361 | ||||
| -rw-r--r-- | docs/textdocs/Tracing.txt | 2 | ||||
| -rw-r--r-- | docs/textdocs/UNIX_SECURITY.txt | 2 |
7 files changed, 414 insertions, 378 deletions
diff --git a/docs/textdocs/BROWSING.txt b/docs/textdocs/BROWSING.txt index 2ca41e5624..ad12d4c722 100644 --- a/docs/textdocs/BROWSING.txt +++ b/docs/textdocs/BROWSING.txt @@ -7,14 +7,10 @@ Summary: This describes how to configure Samba for improved browsing. OVERVIEW: ========= - SMB networking provides a mechanism by which clients can access a list -of machines in a network, a so-called "browse list". This list -contains machines that are ready to offer file and/or print services -to other machines within the network. Thus it does not include -machines which aren't currently able to do server tasks. The browse -list is heavily used by all SMB clients. Configuration of SMB -browsing has been problematic for some Samba users, hence this +of machines that are available within the network. This list is called +the browse list and is heavily used by all SMB clients. Configuration +of SMB browsing has been problematic for some Samba users, hence this document. Browsing will NOT work if name resolution from NetBIOS names to IP @@ -63,10 +59,9 @@ browsing on another subnet. It is recommended that this option is only used for 'unusual' purposes: announcements over the internet, for example. See "remote announce" in the smb.conf man page. -If something doesn't work then hopefully the log.nmb file will help -you track down the problem. Try a debug level of 2 or 3 for finding -problems. Also note that the current browse list usually gets stored -in text form in a file called browse.dat. +If something doesn't work then hopefully the log.nmb file will +help you track down the problem. Try a debug level of 2 or 3 for +finding problems. Note that if it doesn't work for you, then you should still be able to type the server name as \\SERVER in filemanager then hit enter and diff --git a/docs/textdocs/HINTS.txt b/docs/textdocs/HINTS.txt index 877640108c..75114557fe 100644 --- a/docs/textdocs/HINTS.txt +++ b/docs/textdocs/HINTS.txt @@ -49,9 +49,6 @@ windows. Just drag your file onto the icon and it converts the file. Get it from ftp://samba.org/pub/samba/contributed/fixcrlf.zip -The utilities unix2dos and dos2unix(in the mtools package) should do -the job under unix. - ---------------------- HINT: Use the "username map" option diff --git a/docs/textdocs/Printing.txt b/docs/textdocs/Printing.txt index 2c50e5f4fe..b47120eaba 100644 --- a/docs/textdocs/Printing.txt +++ b/docs/textdocs/Printing.txt @@ -3,7 +3,7 @@ Revised by: Patrick Powell <papowell@lprng.org> Date: August 11, 2000 Status: Current -Subject: Debugging Printing Problems +Subject: Dubugging Printing Problems ============================================================================= This is a short description of how to debug printing problems with diff --git a/docs/textdocs/Samba-OpenSSL.txt b/docs/textdocs/Samba-OpenSSL.txt new file mode 100644 index 0000000000..e1b54b1a03 --- /dev/null +++ b/docs/textdocs/Samba-OpenSSL.txt @@ -0,0 +1,405 @@ +Contributor: Christian Starkjohann <cs@obdev.at> +Date: May 29, 1998 +Status: + +Comment: Updated by Lutz Jaenicke <Lutz.Jaenicke@aet.TU-Cottbus.DE> +Date: July 16, 2001 + +Subject: Compiling and using samba with SSL support +============================================================================ + +What is SSL and SSLeay/OpenSSL? +=============================== +SSL (Secure Socket Layer) is a protocol for encrypted and authenticated data +transport. It is used by secure web servers for shopping malls, telebanking +and things like that. + +SSLeay is a free implementation of the SSL protocol. The successor of it is +OpenSSL, available from + + http://www.openssl.org/ + +The current version while these lines are written is 0.9.6b. In some countries +encryption is plagued by legal problems, even though things have relaxed a +lot in the last years. + +To compile samba with SSL support, you must first compile and install OpenSSL. +At least version 0.9.5 of OpenSSL is required. Version 0.9.6b is the latest +version and is strongly recommended. +OpenSSL consists of a library (which can be linked to other applications like +samba) and several utility programs needed for key generation, certification +etc. OpenSSL installs to /usr/local/ssl/ by default. + + +Compiling samba with OpenSSL +============================ +1. Get and install OpenSSL. The rest of this documentation assumes that you + have installed it at the default location, which is /usr/local/ssl/. +2. Call "configure" with the "--with-ssl" flag. If OpenSSL is not installed in + the default directory, you can use the "--with-sslinc" and "--with-ssllib" + flags to specify the location. +3. Compile and install as usual. + + +Configuring SSL in samba +======================== +Before you configure SSL, you should know the basics of cryptography and how +SSL relates to all of this. A basic introduction can be found further down in +this document. The following variables in the "[global]" section of the +configuration file are used to configure SSL: + +ssl = yes + This variable enables or disables the entire SSL mode. If it is set to + "no", the SSL enabled samba behaves exactly like the non-SSL samba. If set + to "yes", it depends on the variables "ssl hosts" and "ssl hosts resign" + whether an SSL connection will be required. +ssl hosts = +ssl hosts resign = 192.168. + These two variables define whether samba will go into SSL mode or not. If + none of them is defined, samba will allow only SSL connections. If the + "ssl hosts" variable lists hosts (by IP-address, IP-address range, net + group or name), only these hosts will be forced into SSL mode. If the + "ssl hosts resign" variable lists hosts, only these hosts will NOT be + forced into SSL mode. The syntax for these two variables is the same as + for the "hosts allow" and "hosts deny" pair of variables, only that the + subject of the decision is different: It's not the access right but + whether SSL is used or not. See the man page of smb.conf (section about + "allow hosts") for details. The above example requires SSL connections + from all hosts outside the local net (which is 192.168.*.*). +ssl CA certDir = /usr/local/ssl/certs + This variable defines where to look up the Certification Autorities. The + given directory should contain one file for each CA that samba will trust. + The file name must be the hash value over the "Distinguished Name" of the + CA. How this directory is set up is explained later in this document. All + files within the directory that don't fit into this naming scheme are + ignored. You don't need this variable if you don't verify client + certificates. +ssl CA certFile = /usr/local/ssl/certs/trustedCAs.pem + This variable is a second way to define the trusted CAs. The certificates + of the trusted CAs are collected in one big file and this variable points + to the file. You will probably only use one of the two ways to define your + CAs. The first choice is preferable if you have many CAs or want to be + flexible, the second is perferable if you only have one CA and want to + keep things simple (you won't need to create the hashed file names). You + don't need this variable if you don't verify client certificates. +ssl server cert = /usr/local/ssl/certs/samba.pem + This is the file containing the server's certificate. The server _must_ + have a certificate. The file may also contain the server's private key. + See later for how certificates and private keys are created. +ssl server key = /usr/local/ssl/private/samba.pem + This file contains the private key of the server. If this variable is not + defined, the key is looked up in the certificate file (it may be appended + to the certificate). The server _must_ have a private key and the + certificate _must_ match this private key. +ssl client cert = /usr/local/ssl/certs/smbclient.pem + The certificate in this file is used by smbclient if it exists. It's needed + if the server requires a client certificate. +ssl client key = /usr/local/ssl/private/smbclient.pem + This is the private key for smbclient. It's only needed if the client + should have a certificate. +ssl require clientcert = yes + If this variable is set to "yes", the server will not tolerate connections + from clients that don't have a valid certificate. The directory/file + given in "ssl CA certDir" and "ssl CA certFile" will be used to look up + the CAs that issued the client's certificate. If the certificate can't be + verified positively, the connection will be terminated. + If this variable is set to "no", clients don't need certificates. Contrary + to web applications you really _should_ require client certificates. In + the web environment the client's data is sensitive (credit card numbers) + and the server must prove to be trustworthy. In a file server environment + the server's data will be sensitive and the clients must prove to be + trustworthy. +ssl require servercert = yes + If this variable is set to "yes", the smbclient will request a certificate + from the server. Same as "ssl require clientcert" for the server. +ssl ciphers = ??? + This variable defines the ciphers that should be offered during SSL + negotiation. You should not set this variable unless you know what you do. +ssl version = ssl2or3 + This enumeration variable defines the versions of the SSL protocol that + will be used. "ssl2or3" allows dynamic negotiation of SSL v2 or v3, "ssl2" + results SSL v2, "ssl3" results in SSL v3 and "tls1" results in TLS v1. TLS + (Transport Layer Security) is the (proposed?) new standard for SSL. The + default value is "ssl2or3". +ssl compatibility = no + This variable defines whether SSLeay should be configured for bug + compatibility with other SSL implementations. This is probably not + desirable because currently no clients with SSL implementations other than + SSLeay exist. +ssl entropy file = + Specifies a file from which processes will read "random bytes" on startup. + In order to seed the internal pseudo random number generator, entropy + must be provided. On system with a /dev/urandom device file, the processes + will retrieve its entropy from the kernel. On systems without kernel + entropy support, a file can be supplied that will be read on startup + and that will be used to seed the PRNG. +ssl entropy bytes = 256 + Number of bytes that will be read from entropy file. If -1 is given, the + complete file will be read. +ssl egd socket = + Location of the communiation socket of an EGD or PRNGD daemon, from which + entropy can be retrieved. This option can be used instead of or together + with the "ssl entropy file" directive. 255bytes of entropy will be + retrieved from the daemon. + + +Running samba with OpenSSL +========================== +Samba is started as usual. The daemon will ask for the private key's pass +phrase before it goes to background if the private key has been encrypted. +If you start smbd from inetd, this won't work. Therefore you must not encrypt +your private key if you run smbd from inetd. + +Windows clients will try to connect to the SSL enabled samba daemon and they +will fail. This can fill your log with failed SSL negotiation messages. To +avoid this, you can either not run nmbd (if all clients use DNS to look up +the server), which will leave the Windows machine unaware of the server, or +list all (local) Windows machines in the "ssl hosts resign" variable. + + +About certificates +================== +Secure samba servers will not be set up for public use as it is the case with +secure web servers. Most installations will probably use it for distributed +offices that use parts of the internet for their intranet, for access to a +web server that's physically hosted by the provider or simply for teleworking. +All these applications work with a known group of users that can easily agree +on a certification authority. The CA can be operated by the company and the +policy for issuing certificates can be determined by the company. If samba is +configured to verify client certificates, it (currently) only verifies +whether a valid certificate exists. It does not verify any of the data within +the certificate (although it prints some of the data to the log file). + + +Which clients are available that support SSL? +============================================= +Currently there are only smbclient which is part of the samba package and +Sharity. Shariy versions newer than 0.14 in the beta branch and 1.01 in the +main branch can be compiled with SSLeay. Sharity is a CIFS/SMB client +implementation for Unix. It is a commercial product, but it is available in +source code and the demo-mode allows access to the first three layers of the +mounted directory hierarchy. Licenses for universities and students are free. +Sharity is available at + + http://www.obdev.at/Products/Sharity.html + + + +########################################################################### +Basics about Cryptography and SSL(eay) +########################################################################### + +There are many good introductions to cryptography. I assume that the reader +is familiar with the words "encryption", "digital signature" and RSA. If you +don't know these terms, please read the cryptography FAQ part 6 and 7, which +is posted to the usenet newsgroup sci.crypt. It is also available from + + ftp://rtfm.mit.edu/pub/usenet/news.answers/cryptography-faq +and + http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq + +I'll concentrate on the questions specific to SSL and samba here. + + +What is a certificate? +====================== +A certificate is issued by an issuer, usually a "Certification Authority" +(CA), who confirms something by issuing the certificate. The subject of this +confirmation depends on the CA's policy. CAs for secure web servers (used for +shopping malls etc.) usually only attest that the given public key belongs the +the given domain name. Company-wide CAs might attest that you are an employee +of the company, that you have permissions to use a server or whatever. + + +What is an X.509 certificate technically? +========================================= +Technically, the certificate is a block of data signed by the certificate +issuer (the CA). The relevant fields are: + - unique identifier (name) of the certificate issuer + - time range during that the certificate is valid + - unique identifier (name) of the certified subject + - public key of the certified subject + - the issuer's signature over all of the above +If this certificate should be verified, the verifier must have a table of the +names and public keys of trusted CAs. For simplicity, these tables are lists +of certificates issued by the respective CAs for themselves (self-signed +certificates). + + +What are the implications of this certificate structure? +======================================================== + - Because the certificate contains the subject's public key, the + certificate and the private key together are all that's needed to encrypt + and decrypt. + - To verify certificates, you need the certificates of all CAs you trust. + - The simplest form of a dummy-certificate is one that's signed by the + subject itself. + - A CA is needed. The client can't simply issue local certificates for + servers it trusts because the server determines which certificate it + presents. + + + +########################################################################### +Setting up files and directories for OpenSSL +########################################################################### + +The first thing you should do is to change your PATH environment variable to +include the bin directory of OpenSSL. E.g.: + + PATH=$PATH:/usr/local/ssl/bin + +If your system's kernel supports a /dev/urandom device, all OpenSSL operations +will automatically retrieve its entropy from it. If your system does not +support /dev/urandom, you may install an EGD/PRNGD daemon for entropy +supply or can generate seed from reading files (that should contain information +unpredictable/unknown to attackers). Use the "-rand" option to the openssl +commands to specify the entropy source (if /dev/urandom is not available). + +OpenSSL additionally keeps random seed in the $HOME/.rnd file. You can +initialize this file using: + + openssl rand -rand /tmp/rfile.txt > $HOME/.rnd + rm -f /tmp/rfile.txt # nobody must know!! + +or + + openssl rand -rand /path/to/egd-socket > $HOME/.rnd + +How to create a keypair +======================= +This is done with 'genrsa' for RSA keys and 'gendsa' for DSA keys. For an RSA +key with 1024 bits which is written to the file "key.pem" type: + + openssl genrsa -des3 -rand /path/to/source 1024 > key.pem + +You will be asked for a pass phrase to protect this key. If you don't want to +protect your private key with a pass phrase, just omit the parameter "-des3". +If you want a different key size, replace the parameter "1024". You really +should use a pass phrase. + +If you want to remove the pass phrase from a key use: + + openssl rsa -in key.pem -out newkey.pem + +And to add or change a pass phrase: + + openssl rsa -des3 -in key.pem -out newkey.pem + + +How to create a dummy certificate +================================= +If you still have your keypair in the file "key.pem", the command + + openssl req -new -x509 -key key.pem -out cert.pem + +will write a self-signed dummy certificate to the file "cert.pem". This can +be used for testing or if only encryption and no certification is needed. +Please bear in mind that encryption without authentication (certification) +can never be secure. It's open to (at least) "man-in-the-middle" attacks. + + +How to create a certificate signing request +=========================================== +You must not simply send your keypair to the CA for signing because it +contains the private key which _must_ be kept secret. A signing request +consists of your public key and some additional information you want to have +bound to that key by the certificate. If you operate a secure web server, +this additional information will (among other things) contain the URL of +your server in the field "Common Name". The certificate signing request is +created from the keypair with the following command (assuming that the key +pair is still in "key.pem"): + + openssl req -new -key key.pem -out csr.pem + +This command will ask you for the information which must be included in the +certificate and will write the signing request to the file "csr.pem". This +signing request is all the CA needs for signing, at least technically. Most +CAs will demand bureaucratic material and money, too. + + +How to set up a Certification Authority (CA) +============================================ +Being a certification authority requires a database that holds the CA's +keypair, the CA's certificate, a list of all signed certificates and other +information. This database is kept in a directory hierarchy below a +configurable starting point. The starting point must be configured in the +ssleay.conf file. This file is at /usr/local/ssl/lib/ssleay.conf if you have +not changed the default installation path. + +The first thing you should do is to edit this file according to your needs. +Let's assume that you want to hold the CA's database at the directory +"/usr/local/ssl/CA". Change the variable "dir" in section "CA_default" to +this path. You may also want to edit the default settings for some variables, +but the values given should be OK. This path is also contained in the shell +script CA.sh, which should be at "/usr/local/ssl/bin/CA.sh". Change the path +in the shell script: + + CATOP=/usr/local/ssl/CA + CAKEY=./cakey.pem # relative to $CATOP/ + CACERT=./cacert.pem # relative to $CATOP/private/ + +Then create the directory "/usr/local/ssl/CA" and make it writable for the +user that operates the CA. You should also initialize SSLeay as CA user (set +up the random number generator). Now you should call the shell script CA.sh +to set up the initial database: + + CA.sh -newca + +This command will ask you whether you want to use an existing certificate or +create one. Just press enter to create a new key pair and certificate. You +will be asked the usual questions for certificates: the country, state, city, +"Common Name", etc. Enter the appropriate values for the CA. When CA.sh +finishes, it has set up a bunch of directories and files. A CA must publish +it's certificate, which is in the file "/usr/local/ssl/CA/cacert.pem". + + +How to sign a certificate request +================================= +After setting up the CA stuff, you can start signing certificate requests. +Make sure that the SSLeay utilities know where the configuration file is. +The default is compiled in, if you don't use the default location, add the +parameter "-config <cfg-file>". Make also sure that the configuration file +contains the correct path to the CA database. If all this is set up properly, +you can sign the request in the file "csr.pem" with the command: + + openssl ca -policy policy_anything -days 365 -infiles csr.pem >cert.pem + +The resulting certificate (and additional information) will be in "cert.pem". +If you want the certificate to be valid for a period different from 365 days, +simply change the "-days" parameter. + + +How to install a new CA certificate +=================================== +Whereever a certificate must be checked, the CA's certificate must be +available. Let's take the common case where the client verifies the server's +certificate. The case where the server verfies the client's certificate works +the same way. The client receives the server's certificate, which contains +the "Distinguished Name" of the CA. To verify whether the signature in this +certificate is OK, it must look up the public key of that CA. Therefore each +client must hold a database of CAs, indexed by CA name. This database is best +kept in a directory where each file contains the certificate of one CA and is +named after the hashvalue (checksum) of the CA's name. This section describes +how such a database is managed technically. Whether or not to install (and +thereby trust) a CA is a totally different matter. + +The client must know the directory of the CA database. This can be configured. +There may also be a configuration option to set up a CA database file which +contains all CA certs in one file. Let's assume that the CA database is kept +in the directory "/usr/local/ssl/certs". The following example assumes that +the CA's certificate is in the file "cacert.pem" and the CA is known as +"myCA". To install the certificate, do the following: + + cp cacert.pem /usr/local/ssl/cers/myCA.pem + cd /usr/local/ssl/certs + ln -s myCA.pem `openssl x509 -noout -hash < myCA.pem`.0 + +The last command creates a link from the hashed name to the real file. + +From now on all certificates signed by the myCA authority will be accepted by +clients that use the directory "/usr/local/ssl/certs/" as their CA certificate +database. + + + diff --git a/docs/textdocs/Solaris-Winbind-HOWTO.txt b/docs/textdocs/Solaris-Winbind-HOWTO.txt deleted file mode 100644 index a81bacf486..0000000000 --- a/docs/textdocs/Solaris-Winbind-HOWTO.txt +++ /dev/null @@ -1,361 +0,0 @@ -!== -!== Solaris-Winbind-HOWTO.txt -!== -Contributors: Naag Mummaneni <getnag@rediffmail.com> -Updated: May 2, 2002 -Status: Current - -Subject: Installing and Configuring Winbind on Solaris -============================================================================= - -Installation and Configuration of Winbind on Solaris. ------------------------------------------------------ - -This HOWTO describes how to get winbind services up and running to control -access and authenticate users on your Solaris box using the winbind services -which come with SAMBA 2.2.x latest CVS Checkout.Make sure you are using the -latest Samba 2.2.x cvs checkout as other versions come with a lots of bugs -regarding winbind .And even the Latest Samba Stable Release is also not an -exception to this. - -Introduction ------------- - -This HOWTO describes the procedures used to get winbind up and running on a -Solaris system. Winbind is capable of providing access and authentication -control for Windows Domain users through an NT or Win2K PDC for 'regular' -services, such as telnet and ftp, as well for SAMBA services. - -Why should I to this? - -This allows the SAMBA administrator to rely on the authentication mechanisms -on the NT/Win2K PDC for the authentication of domain members. NT/Win2K users -no longer need to have separate accounts on the SAMBA server. - -Who should be reading this document? - -This HOWTO is designed for system administrators. If you are implementing -SAMBA on a file server and wish to (fairly easily) integrate existing -NT/Win2K users from your PDC onto the SAMBA server, this HOWTO is for you. - -Requirements ------------- - -If you have a samba configuration file that you are currently using... BACK -IT UP! If your system already uses PAM, back up the /etc/pam.conf file ! If -you haven't already made a boot disk, MAKEONE NOW! Messing with the pam -configuration file can make it nearly impossible to log in to yourmachine. -That's why you want to be able to boot back into your machine in single user -mode and restore your /etc/pam.conf back to the original state they were in -if you get frustrated with the way things are going. ;-) Please refer to the -main SAMBA web page or, better yet, your closest SAMBA mirror site for -instructions on downloading the source code of Samba 2.2.x from the SAMBA -CVS repository. To allow Domain users the ability to access SAMBA shares and -files, as well as potentially other services provided by your SAMBA machine, -PAM (pluggable authentication modules) must be setup properly on your -machine. In order to compile the winbind modules, you should have at least -the pam libraries resident on your system. Solaris 7/8 has its pam modules -coming with the distribution itself. - -Testing Things Out ------------------- - -Before starting, it is probably best to kill off all the SAMBA related -daemons running on your server. Kill off all smbd, nmbd, and winbindd -processes that may be running. - - -Configure and compile SAMBA ---------------------------- - -The configuration and compilation of SAMBA is pretty straightforward. The -first three steps may not be necessary depending upon whether or not you -have previously built the Samba binaries. - -root# autoconf -root# make clean -root# rm config.cache -root# ./configure --with-winbind --with-pam -root# make -root# make install - -This will, by default, install SAMBA in /usr/local/samba. See the main SAMBA -documentation if you want to install SAMBA somewhere else. It will also -build the winbindd executable and libraries. - -Configure nsswitch.conf and the winbind libraries -------------------------------------------------- - -The libraries needed to run the winbindd daemon through nsswitch need to be -copied to their proper locations, so - -root# cp ../samba/source/nsswitch/libnss_winbind.so /usr/lib - -I also found it necessary to make the following symbolic links: - -root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1 -root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.2 -root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1 -root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2 - -Now, as root you need to edit /etc/nsswitch.conf to allow user and group -entries to be visible from the winbindd daemon. My /etc/nsswitch.conf file -look like this after editing: - - passwd: files winbind - group: files winbind - - -Configure smb.conf ------------------- - -Several parameters are needed in the smb.conf file to control the behavior -of winbindd. Configure smb.conf These are described in more detail in the -winbindd(8) man page. My smb.conf file was modified to include the following -entries in the [global] section: - -[global] - <...> - # The previous documentation says to - # as the "winbind seperator " directive also but - # it is no longer supported. - - # use uids from 10000 to 20000 for domain users - winbind uid = 10000-20000 - - # use gids from 10000 to 20000 for domain groups - winbind gid = 10000-20000 - - # allow enumeration of winbind users and groups - winbind enum users = yes - winbind enum groups = yes - - # give winbind users a real shell (only needed if - # they have telnet access) - template homedir = /home/winnt/%D/%U - template shell = /bin/bash - - -Join the SAMBA server to the PDC domain ---------------------------------------- - -Enter the following command to make the SAMBA server join the PDC domain, -where DOMAIN is the name of your Windows domain and Administrator is a -domain user who has administrative privileges in the domain. - -root# /usr/local/samba/bin/smbpasswd -j DOMAIN -r PDC -U Administrator - -The proper response to the command should be: "Joined the domain DOMAIN" -where DOMAIN is your DOMAIN name. - -Start up the winbindd daemon and test it! - -Eventually, you will want to modify your smb startup script to automatically -invoke the winbindd daemon when the other parts of SAMBA start, but it is -possible to test out just the winbind portion first. To start up winbind -services, enter the following command as root: - -root# /usr/local/samba/bin/winbindd - -I'm always paranoid and like to make sure the daemon is really running... - -root# ps -ae | grep winbindd - -This command should produce output like this, if the daemon is running - - 3025 ? 00:00:00 winbindd - -Now... for the real test, try to get some information about the users on -your PDC - -root# /usr/local/samba/bin/wbinfo -u - -This should echo back a list of users on your Windows users on your PDC. For -example, I get the following response: - -CEO\Administrator -CEO\burdell -CEO\Guest -CEO\jt-ad -CEO\krbtgt -CEO\TsInternetUser - -root# /usr/local/samba/bin/wbinfo -g - -CEO\Domain Admins -CEO\Domain Users -CEO\Domain Guests -CEO\Domain Computers -CEO\Domain Controllers -CEO\Cert Publishers -CEO\Schema Admins -CEO\Enterprise Admins -CEO\Group Policy Creator Owners - -The function 'getent' can now be used to get unified lists of both local and -PDC users and groups. Try the following command: - -root# getent passwd - -You should get a list that looks like your /etc/passwd list followed by the domain users with their new -uids, gids, home directories and default shells. - -The same thing can be done for groups with the command - -root# getent group - -Fix the /etc/rc.d/init.d/samba.server startup files The winbindd daemon -needs to start up after the smbd and nmbd daemons are running. To accomplish -this task, you need to modify the /etc/init.d/samba.server script to add -commands to invoke this daemon in the proper sequence. My -/etc/init.d/samba.server file starts up smbd, nmbd, and winbindd from the -/usr/local/samba/bin directory directly. - -## -## samba.server -## - -if [ ! -d /usr/bin ] -then # /usr not mounted - exit -fi - -killproc() { # kill the named process(es) - pid=`/usr/bin/ps -e | - /usr/bin/grep -w $1 | - /usr/bin/sed -e 's/^ *//' -e 's/ .*//'` - [ "$pid" != "" ] && kill $pid -} - -# Start/stop processes required for samba server - -case "$1" in - -'start') -# -# Edit these lines to suit your installation (paths, workgroup, host) -# -echo Starting SMBD - /usr/local/samba/bin/smbd -D -s \ - /usr/local/samba/smb.conf - -echo Starting NMBD - /usr/local/samba/bin/nmbd -D -l \ - /usr/local/samba/var/log -s /usr/local/samba/smb.conf - -echo Starting Winbind Daemon - /usr/local/samba/bin/winbindd - ;; - -'stop') - killproc nmbd - killproc smbd - killproc winbindd - ;; - -*) - echo "Usage: /etc/init.d/samba.server { start | stop }" - ;; -esac - -If you restart the smbd, nmbd, and winbindd daemons at this point, you -should be able to connect to the samba server as a domain member just as if -you were a local user. - - -Configure Winbind and PAM -------------------------- - -If you have made it this far, you know that winbindd and samba are working -together. If you want to use winbind to provide authentication for other -services, keep reading. The pam configuration file need to be altered in -this step. (Did you remember to make backups of your original /etc/pam.conf -file? If not, do it now.) You will need a pam module to use winbindd with -these other services. This module will be compiled in the ../source/nsswitch -directory by default when we used ./configure --with-pam option. - -root# make nsswitch/pam_winbind.so - -from the ../source directory. The pam_winbind.so file should be copied to -the location of your other pam security modules. On my Solaris 8, this was -the /usr/lib/security directory. - -root# cp ../samba/source/nsswitch/pam_winbind.so /usr/lib/security - -The /etc/pam.conf need to be changed. I changed this file so that my Domain -users can logon both locally as well as telnet.The following are the changes -that I made.You can customize the pam.conf file as per your requirements,but -be sure of those changes because in the worst case it will leave your system -nearly impossible to boot. - -# -#ident "@(#)pam.conf 1.14 99/09/16 SMI" -# -# Copyright (c) 1996-1999, Sun Microsystems, Inc. -# All Rights Reserved. -# -# PAM configuration -# -# Authentication management -# -login auth required /usr/lib/security/pam_winbind.so -login auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass -login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pass -# -rlogin auth sufficient /usr/lib/security/pam_winbind.so -rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 -rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass -# -dtlogin auth sufficient /usr/lib/security/pam_winbind.so -dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass -# -rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 -other auth sufficient /usr/lib/security/pam_winbind.so -other auth required /usr/lib/security/$ISA/pam_unix.so.1 try_first_pass -# -# Account management -# -login account sufficient /usr/lib/security/pam_winbind.so -login account requisite /usr/lib/security/$ISA/pam_roles.so.1 -login account required /usr/lib/security/$ISA/pam_unix.so.1 -# -dtlogin account sufficient /usr/lib/security/pam_winbind.so -dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 -dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 -# -other account sufficient /usr/lib/security/pam_winbind.so -other account requisite /usr/lib/security/$ISA/pam_roles.so.1 -other account required /usr/lib/security/$ISA/pam_unix.so.1 -# -# Session management -# -other session required /usr/lib/security/$ISA/pam_unix.so.1 -# -# Password management -# -#other password sufficient /usr/lib/security/pam_winbind.so -other password required /usr/lib/security/$ISA/pam_unix.so.1 -dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1 -# -# Support for Kerberos V5 authentication (uncomment to use Kerberos) -# -#rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass -#login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass -#dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass -#other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass -#dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 -#other account optional /usr/lib/security/$ISA/pam_krb5.so.1 -#other session optional /usr/lib/security/$ISA/pam_krb5.so.1 -#other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass - -I also added a try_first_pass line after the winbind.so line to get rid of -annoying double prompts for passwords. - -Now restart your Samba & try connecting through your application that you -configured in the pam.conf. - - - -!== -!== end of Solaris-Winbind-HOWTO.txt -!== diff --git a/docs/textdocs/Tracing.txt b/docs/textdocs/Tracing.txt index 6cc1d69258..fd65045abd 100644 --- a/docs/textdocs/Tracing.txt +++ b/docs/textdocs/Tracing.txt @@ -70,7 +70,7 @@ Once you are attached you then can do whatever it is on the client that is causing problems and you will capture all the system calls that smbd makes. -So how do you interpret the results? Generally I search through the +So how do you interpret the results? Generally I search thorugh the output for strings that I know will appear when the problem happens. For example, if I am having touble with permissions on a file I would search for that files name in the strace output and look at diff --git a/docs/textdocs/UNIX_SECURITY.txt b/docs/textdocs/UNIX_SECURITY.txt index 38705f018a..d6a0a01acc 100644 --- a/docs/textdocs/UNIX_SECURITY.txt +++ b/docs/textdocs/UNIX_SECURITY.txt @@ -32,7 +32,7 @@ directory and do an ls, the UNIX security solution is to change the UNIX file permissions on the users home directories such that the cd and ls would be denied. -Samba tries very hard not to second guess the UNIX administrators +Samba tries very had not to second guess the UNIX administrators security policies, and trusts the UNIX admin to set the policies and permissions he or she desires. |