OpenVPN under FreeBSD

Getting OpenVPN to play nice with FreeBSD was not as easy as I normally
get from a FreeBSD port

This is due to both my learning on the fly and lack of good
BSD related documentation



Here's my notes on how I accomplished it

I hope it helps you


Feel free to use/share/mod



Sorry it's not yet all that perty



I used/did

FreeBSD 6.2/7.0

portsnap

cd /usr/ports/security/openvpn

make install clean




I like to copy the scripts to
/etc/openvpn

cd /usr/local/share/doc/openvpn/easy-rsa

mkdir /etc/openvpn

cp -R * /etc/openvpn

cd /etc/openvpn

Edit vars to your environment (http://openvpn.net/howto.html)



Now run the scripts.  They are
bash scripts !!




sh

. ./vars

sh ./clean-all

sh ./build-ca

sh ./build-key-server server

sh ./build-key-pass client

sh ./build-dh  (takes a while, grab a drink/chill)




Copy/Edit the config.  I like to
keep the openvpn.conf in the normal configuration location.  Edit
/usr/local/etc/rc.d/openvpn to adjust the default location

mkdir /usr/local/etc/openvpn

cp /usr/local/share/doc/openvpn/sample-config-files/server.conf 
/usr/local/etc/openvpn/openvpn.conf





Edit
/usr/local/etc/openvpn/openvpn.conf to add the correct path to these
files


ca.crt

server.crt

server.key

dh1024.pem



Like



ca /etc/openvpn/2.0/keys/ca.crt

cert /etc/openvpn/2.0/keys/server.crt

key /etc/openvpn/2.0/keys/server.key


dh /etc/openvpn/2.0/keys/dh1024.pem





Add this to /etc/rc.conf



openvpn_enable="YES"

gateway_enable="YES"



openvpn_if="tun" for Tunneling

or

openvpn_if="tap" for Bridging






Make sure IP Forwarding is enabled

Check it with

sysctl -a |grep net.inet.ip.f



It should look like this

inet.inet.ip.forwarding: 1



If your /etc/rc.conf has gateway_enable="YES",
it will be set on reboot




You can have this /etc/rc.conf setting read without a reboot by doing
this

/etc/rc/d/routing restart



You can also set IP Forwarding manaully with sysctl

sysctl inet.inet.ip.forwarding=1





Edit
/usr/local/etc/openvpn/openvpn.conf enough
to get tunelling going

Leave it at that if you want




For me it was a pain to configure routing on the server side

I found it necessary to
add permanent routes back as static routes on my gateway did not seem
to help

This probably will be less painful if your gateway is your OpenVPN
server.

It wasnt for my install

I did eventually choose bridging but here's my route notes for history



FreeBSD

Temporary

route add -net 10.8.0.0/24 192.168.10.1




Permanent

/etc/rc.conf

static_routes="openvpn"

openvpn="-net 10.8.0.0/24 192.168.10.1"



Windows

Temporary

route ADD 10.8.0.0 MASK 255.255.255.0 192.168.10.1




Permanent

route -p ADD 10.8.0.0 MASK 255.255.255.0 192.168.10.1





Because of the routing pain, I then
tried Bridge

OpenVPN's scripts do not automatically create the bridge device

I could not find a solution

Based on some reading, I made a startup script to build the bridge at
startup

So far so good, It's probably a bad hack, maybe someone will help me
out here




/usr/local/etc/rc.d/create-bridge.sh

ifconfig bridge0 create

ifconfig bridge0 addm fxp0 addm tap0 up

ifconfig bridge0 inet 192.168.10.12 netmask 255.255.255.0



The script

1. Creates the bridge device

2. Adds a hardware NIC and TAP0 device, brings it up

3. Assigns a static IP




You'll have to edit the interface name and bridged IP to taste



For a bridge, you have to modify the
openvpn.conf

Change from tun to tap

dev tap

;dev tun



Modify server-bridge for the bridge IP
and pushed out IP range

server-bridge 192.168.10.12  255.255.255.0 192.168.10.100
192.168.110.109




Your dmesg will fill up with stuff
like this

arp: 192.168.10.2 is on fxp0 but got reply from 00:0a:5e:4d:37:ee on
bridge0

I turned off logging of this with sysctl
net.link.ether.inet.log_arp_wrong_iface=0



Add net.link.ether.inet.log_arp_wrong_iface=0

 to /etc/sysctl.conf for a permanent change to this setting



Optional improved security

Use tls-auth


openvpn --genkey --secret ta.key

Copy ta.key to server and client

In the server configuration, add:

tls-auth ta.key 0



In the client configuration, add:

tls-auth ta.key 1



Larger RSA keys like 2048

Edit vars to include


export KEY_SIZE=2048



Revoke a certificate if someone gets
the boot (aka fired), hopefully not me

. ./vars

./revoke-full client2

This Creates crl.pem

Edit server config to point to this file

crl-verify crl.pem

Watch permissions


I needed to copy the crl.pem to /usr/local/sbin as the openvpn daemon
running as nobody could not see it in the location is was created



Adding authentication seemed an easy
improvement method for security

Add to client config

auth-user-pass



Add to server config

plugin /usr/local/lib/openvpn-auth-pam.so login



For lab use I did this


# Uncomment this directive if multiple clients

# might connect with the same certificate/key

# files or common names.  This is recommended

# only for testing purposes.  For production use,

# each client should have its own certificate/key

# pair.

#


# IF YOU HAVE NOT GENERATED INDIVIDUAL

# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,

# EACH HAVING ITS OWN UNIQUE "COMMON NAME",

# UNCOMMENT THIS LINE OUT.

;duplicate-cn

--duplicate-cn



Cipher strength hmmm

3 choices


;cipher BF-CBC        # Blowfish
(default)

;cipher AES-128-CBC   # AES

;cipher DES-EDE3-CBC  # Triple-DES



Here's a cool command to test
throughput relative to cipher

openssl speed bf-cbc des-ede3 aes-128-cbc


The 'numbers' are in 1000s of bytes per second processed.

type            
16 bytes     64 bytes    256
bytes   1024 bytes   8192 bytes

des ede3        
11884.66k    11914.43k   

11951.81k    11965.71k    11963.80k

blowfish cbc     52814.10k   
53821.89k    54053.87k   
54415.30k    53871.86k


aes-128 cbc      40888.23k   
38975.23k    39728.08k   
40106.78k    39669.99k



Want to delete a person in order to
create a new key or changes
password?

Delete their .crt .key and .csr


Then remove their entry from the OpenVPN keys directory in the file
index.txt



I was getting - Initialization
Sequence Completed With Errors

ip-win32 netsh - was the fix for me



Here's a rip from some docs

Make sure that the DHCP Client Service is started.

If the above fix doesn't work, then it's possible that the TAP-Win32
adapter is being firewalled. In general, it's safe to disable the
firewall on the TAP-Win32 adapter because OpenVPN makes sure that only
an authenticated machine on the other end of the connection can
communicate through it. Having said that, there have been reports that
certain third party firewalls will block the TAP-Win32 adapter after an
XP SP2 upgrade.

You can also try changing the ip-win32 setting to a non-DHCP method.
For example:




ip-win32 netsh

ip-win32 ipapi

ip-win32 manual



Signing the Certificate.  I chose
the allow the users to create
their own key.  They then sent me a csr which I signed ...

Transfer the csr to the server in /etc/openvpn/2.0/keys

From /etc/openvpn/2.0




sh

. ./vars

sh ./pkitool --sign dsuzuki



This creates a certificate *.crt in /etc/openvpn/2.0/keys

Sent this back to the client



Fast Forwarding

I dont know why I wrote this
down originally


It looks cool so I left it

net.inet.ip.fastforwarding=1



Here's notes from the FreeBSD Kernel Interfaces Manual for inet(4)



(ip.fastforwarding)

Boolean: enable/disable the use of fast IP forwarding code.

Defaults to off



When fast IP forwarding is enabled, IP packets are forwarded directly
to the appropriate network interface with direct processing to
completion, which


greatly improves the throughput.

All packets for local IP addresses, non-unicast, or with IP optionsare
handled by the normal IP input processing path.

All features of the normal (slow) IP forwarding path are supported
including firewall (through pfil(9) hooks) checking, except ipsec(4)
tunnel brokering.

The IP fastforwarding path does not generate ICMP redirect or source
quench messages.



Have fun

Installing FreeBSD onto a USB stick

The easy way

A little secret - the easy way to do this is to boot from the installation CDROM while you have the USB stick in and just install to it.

You didn't come here for that though, did you?

The slightly more involved way

It doesn't qualify as "hard".

You'll still need to grab that ISO — get the latest one.

• Mount that ISO on /dist:

     # mkdir /dist
     # mdconfig -a -f /a/FreeBSD/6.1-BETA4-i386-disc1.iso
     md17
     # mount -t cd9660 /dev/md17 /dist

• Insert the stick. They come preformatted with a FAT32 partition on, so we'll need to throw a BSD slice label on there — this command will destroy all existing slices. If you get a warning regarding "Geom not found", don't worry.:

  
  
  

  # fdisk -BI /dev/da0
  




• We need a disk label:

  
  
  

  # bsdlabel -B -w da0s1
  




• and a filesystem, which we'll mount on /mnt:

  
  
  

  # newfs -U /dev/da0s1a
  /dev/da0s1a: 481.0MB (985040 sectors) block size 16384, fragment size 2048
          using 4 cylinder groups of 120.25MB, 7696 blks, 15424 inodes.
          with soft updates
    super-block backups (for fsck -b #) at:
    160, 246432, 492704, 738976
  # mount /dev/da0s1a /mnt
  




• Now to do an install the blindingly easy way:

  
  
  

  # cd /dist/6.1-BETA4/base
  # DESTDIR=/mnt ./install.sh 
  You are about to extract the base distribution into /mnt - are you SURE
  you want to do this over your installed system (y/n)? y
  




• Since we are using 6.1-BETA4, there is some additional messing about to do. This is very likely to change in later release candidates (since it is somewhat broken), but this works for 6.1-BETA4:

  
  
  

  # cd /dist/6.1-BETA4/kernels
  # DESTDIR=/mnt sh ./install.sh generic
  # rmdir /mnt/boot/kernel
  # mv /mnt/GENERIC /mnt/boot/kernel
  




• Make the USB stick bootable:

  
  
  

  # boot0cfg -v -B da0
  #   flag     start chs   type       end chs       offset         size
  1   0x80      0:  1: 1   0xa5    480: 63:32           32       985056
  
  
  version=1.0  drive=0x80  mask=0xf  ticks=182
  options=packet,update,nosetdrv
  default_selection=F1 (Slice 1)
  
  




• Create an fstab(5) file on the USB stick. Here's a simple one:

  
  
  

  /dev/da0s1a /      ufs    rw                      1 1
  md          /tmp   mfs    rw,-s16M,nosuid,noatime 0 0
  /dev/acd0   /cdrom cd9660 ro,noauto,nosuid        0 0
  proc        /proc  procfs rw                      0 0
  




• Install any packages you might want:

  
  
  

  # chroot /mnt /bin/sh
  # pkg_add -r lsof rsync unzip zsh kde...
  

You're done.

Enabling Multiple Remote Desktop Sessions in Windows XP Professional and Media Center Edition 2005

If you have ever used a real remote computer system like Citrix, then you have probably been craving multiple Remote Desktop sessions since you first fired up Windows XP Professional and/or Media Center Edition. Here is a HACK (translated: USE AT YOUR OWN RISK), to enable multiple Remote Desktop sessions on your XP Pro or MCE 2005 box:

NOTE: You will have to have knowledge of the Windows operating system and more specifically the Windows Registry. If you have no experience with the registry, then I would recommend you find someone who does or leave these alone. I do not make any kind of warranty that this will work for you or your friends. This is provided for entertainment purposes only. Don’t call me if your computer stops working. Got it?

1. Print these directions so that you have them to work from.


2. Restart your computer in Safe Mode - Follow this link to learn how to restart Windows XP in Safe Mode



3. Turn off/disable Remote Desktop Connection (RDC) and Terminal Services

1. Right click My Computer


2. Select Properties


3. Click on the Remote tab at the top of the window



4. UNCHECK the box next to, “Allow users to connect remotely to this computer“


5. Click OK


6. Go to Start -> Control Panel -> Administrative Tools -> Services


7. Find Terminal Services in the list


8. Right click on Terminal Services and click Properties
   
   


9. In the Startup Type box, select Disabled


10. Click OK to close the window

Next you will replace the current version of the Terminal Services DLL (termsrv.dll) with an unrestricted version from a previous release of Terminal Services.

1. Here is a copy of the Terminal Services DLL - Save it to your Desktop or other suitable location


2. Using a file manager like Windows Explorer open C:\Windows\system32\dllcache


3. Rename the file termsrv.dll to termsrv_dll.bak or whatever you would like.


4. Copy the downloaded termsrv.dll file (the one you just downloaded from the web) to C:\Windows\system32\dllcache



5. Open the C:\Windows\system32 folder


6. Delete the file termsrv.dll in C:\Windows\system32

Now we can edit the Windows Registry to enable more than one RDP connection. Go to Start -> Run and type regedit - Hopefully you knew that already

Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core

Add a DWORD Key named EnableConcurrentSessions and give it a value of 1

Close the Registry Editor window

Go to Start -> Run and type gpedit.msc to run the Group Policy Editor

Browse to Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services and double click Limit number of connections

Select the Enabled button and enter the number of connections you would like to enable….at least 2.

Restart Windows

Right click My Computer and select Properties.

Click on the Remote tab at the top of the window

CHECK the box next to, “Allow users to connect remotely to this computer“

Click OK

Go to Start -> Control Panel ->Administrative Tools -> Services. Select Terminal Services from the list and double click it or right-click -> Properties. Set the Startup Type to Manual.

Restart Windows/Computer

Qmail Error Messages

Qmail Most Common Errors

(Also see http://qmail-scanner.sourceforge.net/FAQ.php )
Most commonly, Setuid of specific files/programs

 $ chmod u+s /var/qmail/bin/qmail-scanner-queue.pl

or

 $ chmod u+s /usr/bin/suidperl

(FYI, If qmail jams-up occurs often and suidperl gets reset after every system update. Then the issue is which SuSEconfig, and can be avoided by updating the /etc/permissions.local file.)

 /usr/bin/sperl5.8.5                     root.root               4711
 /usr/bin/suidperl                       root.root               4711

[edit]

Common Error Messages

(See below for specific error messages and solutions ... )

[edit]

451 qq temporary problem (#4.3.0)

CHECK: /var/log/mail

 Feb  2 01:04:07 HOSTNAME X-Antivirus-HOSTNAME.DOMAIN.COM-1.22-st-qms: [] cannot create /var/spool/qmailscan/tmp - Permission denied 

SOLUTION:

$ chmod u+s /var/qmail/bin/qmail-scanner-queue.pl
$ chown qmailq:qmail /var/qmail/bin/qmail-scanner-queue.pl
$ /etc/init.d/qmail doqueue

SOLUTION#2: (but med security risk, avoid if possible)

$ chmod a+wxr /var/spool/qmailscan/tmp/
$ /etc/init.d/qmail doqueue

-- OR --
CHECK: /var/log/mail

Feb 23 14:08:16 aker X-Antivirus-MYHOST.MYDOMAIN.COM-1.25-st-qms: [MYHOST114073249677517083] 

cannot open /var/spool/qmailscan/qmail-scanner-queue-version.txt - did you initialise the
system by running "qmail-scanner-queue.pl -z"? - Permission denied
ISSUE:

 Cannot read /var/spool/qmailscan/qmail-scanner-queue-version.txt file. Needs to be readable by qmail programs.

SOLUTION:

$ chmod u+s /var/spool/qmailscan/qmail-scanner-queue-version.txt
$ chown qmailq:qmail /var/spool/qmailscan/qmail-scanner-queue-version.txt
$ /etc/init.d/qmail doqueue

SOLUTION#2: (but low security risk, avoid if possible)

$ chmod a+r /var/spool/qmailscan/qmail-scanner-queue-version.txt
$ /etc/init.d/qmail doqueue

[edit]

(Unable to access ClamAV database)

FILE:

 /var/log/spamd/freshclam.log

ERROR LOG:
SOLUTION:

 /etc/init.d/freshclam 

RESULT:

Feb  2 04:36:16 HOSTNAME freshclam[6157]: Received signal: wake up
Feb  2 04:36:16 HOSTNAME freshclam[6157]: ClamAV update process started at Thu Feb  2 04:36:16 2006
Feb  2 04:36:17 HOSTNAME freshclam[6157]: main.cvd is up to date (version: 35, sigs: 41649, f-level: 6, builder: tkojm)
Feb  2 04:36:22 HOSTNAME freshclam[6157]: daily.cvd updated (version: 1269, sigs: 2308, f-level: 7, builder: diego)
Feb  2 04:36:22 HOSTNAME freshclam[6157]: Database updated (43957 signatures) from db.us.clamav.net (IP: 206.154.203.13)
Feb  2 04:36:22 HOSTNAME freshclam[6157]: Clamd successfully notified about the update.
Feb  2 04:36:22 HOSTNAME freshclam[6157]: --------------------------------------

[edit]

250 ok Your SPAM has been ignored.

CHECK:

$ tail /var/log/qmail/qmail-*/current
$ tail /var/spool/qmailscan/qms-events.log 

POSSIBLE LOG MESSAGE:

 1138764631:25585:ERROR:X-Antivirus-HOSTNAME.DOMAIN.COM-1.22-st-qms:cannot open /var/spool/qmailscan/qmail-scanner-queue-version.txt - did you initialise the system by running "qmail-scanner-queue.pl -z"? - Permission denied

SOLUTION #1:
Regenerate and verify various log files:

• /var/spool/qmailscan/qmail-queue.log
• /var/spool/qmailscan/qms-events.log
• /var/spool/qmailscan/qmail-scanner-queue-version.txt
  

# /var/qmail/bin/qmail-scanner-queue.pl -z

SOLUTION #2:
Regenerate database file:

• /var/spool/qmailscan/quarantine-attachments.db

#  /var/qmail/bin/qmail-scanner-queue.pl -g

POSSIBLE LOG MESSAGE:

@4000000044445b40279a5bec tcpserver: status: 1/30
@4000000044445b40279a7744 tcpserver: pid 19813 from MYHOST.MYDOMAIN.COM
@4000000044445b402aa0cdbc tcpserver: ok 19813 MYHOST.MYDOMAIN.COM:192.168.1.20:25 :192.168.1.21::7463
@4000000044445b421f069aa4 Can't do seteuid!

@4000000044445b421f111e0c tcpserver: end 19813 status 0
@4000000044445b421f11357c tcpserver: status: 0/30

SOLUTION #1:
Update suidperl permissions

# chown root /usr/bin/suidperl
# chmod 4711 /usr/bin/suidperl

BEFORE

-rwx--x--x  3 root root 1203220 Sep  9 22:08 /usr/bin/suidperl

AFTER

-rws--x--x  3 root root 1203220 Sep  9 22:08 /usr/bin/suidperl

FYI, If qmail jams-up occurs often and suidperl gets reset after every system update. Then the issue is which SuSEconfig, and can be avoided by updating the file:

/etc/permissions.local

/usr/bin/sperl5.8.5                     root.root               4711
/usr/bin/suidperl                       root.root               4711

SOLUTION #2:
Update softlimit to 50M (50000000).

[edit]

(Email is not being sent out from qmail)

(or other sites are replying 'too many connections')
DESC:

 Qmail is receiving email messages ok, but not being sent off-site correctly.

SOLUTION:

1. Check /var/qmail/control/smtproutes for correct path going off server.
   
   1. Some ISP's will give you the correct SMTP address to use for outgoing email, use it !
   2. If this file is not present, then normal one-to-one connectivity will happen. Some sites like GMail, will only accept one connection from 'Cable' or 'DSL' home connections. Which will slow down outgoing email or even deny connections.
   
   

1. Check all redirections/forwards in /var/qmail/alias
   
   1. Check for any direct 'mailbox' saving, make sure that 'alias' account has write permission.
      
      1. (Solution also, forward email to user accounts if you want to save email out for specific user)
   2. Check for any called programs or routines, make sure in path, or specific state the location.

[edit]

451 qq trouble creating files in queue (#4.3.0)

(Mail not send, Sending Error:)
DESC:

 Permissional problem/issue.

FILE/DIRECTORY:

 /var/qmail/bin

FIX:

 $ chmod u+s /var/qmail/bin/qmail-queue
 $ chown qmailq:qmail /var/qmail/bin/qmail-queue

RESULT:

  -rws--x--x 1 qmailq qmail 15464 2004-11-09 12:19 qmail-queue

[CONFIRMED, 2006.02.02, 2006.04.02]

[edit]

quarantine-attachments.txt is empty or missing

SOLUTION:

 $ setuidgid qscand /var/qmail/bin/qmail-scanner-queue.pl  -g
 perlscanner: generate new DB file from /var/spool/qmailscan/quarantine-attachments.txt
 perlscanner: total of 9 entries.

[edit]

This message is looping: it already has my Delivered-To line. (#5.4.6)

DESC:

 When I send a message now to a user on my server from an outside account.
 I am getting this from qmail.

OBSERVATION:

 You are probably forwarding mail to yourself.

SOLUTION:

 Check your /var/qmail/control/smtproutes file to make sure you are not
 sending mail to a relay which is sending back to you, and also look at
 your forwarding files, .qmail, .qmail-default etc.

[edit]

Unable to close pipe to /var/qmail/bin/qmail-queue

FILE qms-events.log

1138948565:5337:ERROR:X-Antivirus-MYDOMAIN.ORG-1.25-st-qms:Unable to open pipe to /var/qmail/bin/qmail-queue [62] (#4.3.0) - 
1138948565:5332:ERROR:X-Antivirus-aker.MYDOMAIN.ORG-1.25-st-qms:Unable to close pipe to /var/qmail/bin/qmail-queue [62] (#4.3.0) - Illegal seek

SOLUTION:

 $ chown qmailq:qmail /var/qmail/bin/qmail-queue
 $ chmod 4711 /var/qmail/bin/qmail-queue
(The suggested equivalant to assuring that chmod go+x and chmod u+s has been done correctly.)

---

[edit]

clamdscan: corrupt or unknown clamd scanner error

[edit]

or memory/resource/perms problem - exit status 512/2

ISSUE:

Mar 23 10:08:55 MYHOST X-Antivirus-MYDOMAIN-1.25-st-qms: [MYHOST.11115941357754112]
 clamdscan:   corrupt or unknown clamd scanner error or memory/resource/perms problem - exit status 512/2

SOLUTION #1:

 Check the paths in qmail-scanner-queue.pl for your clamav binaries.

SOLUTION #2:

 Remove clamav (or clamdscan_scanner) from the scanners_installed array in qmail-scanner-queue.pl

SOLUTION #3:

 set clamd to run as root.
 (instead of running as qscand)

SOLUTION #4:
One of the issues I had with configuring it was that it was trying to use clamav user to access its program. I wanted it to use qscand.

 downloaded the clamav-0.80.tar.gz.
 untarred the file 
 compile it with
 ./configure --disable-clamav --sysconfdir=/etc
 make && make install

 Edit the clamav.conf and changed the user to the qscand.
 (problems should go away)

[edit]

(incorrect permissions or unable to write file)

ISSUE: File ownership is 'root' instead of proper 'qscand' or 'qscand:qscand'.

drwxrwx---   5 qscand qscand       424 2006-02-02 04:59 ./
drwxr-xr-x  13 root   root         352 2005-10-17 01:50 ../
-rw-------   1 qscand qscand 311970391 2006-02-02 04:32 qmail-queue.log
-rw-------   1 root   root           0 2006-02-02 04:32 qmail-scanner-queue-version.txt
-rw-------   1 qscand qscand 258599592 2006-02-02 04:32 qms-events.log
drwxrwx---   5 qscand qscand       120 2005-10-17 01:50 quarantine/
-rw-r-----   1 root   root       12288 2006-02-02 04:49 quarantine-attachments.db

SOLUTION:

$ chown qscand:root qmail-scanner-queue-version.txt

---

[edit]

Clamd was NOT notified: Can't connect to clamd through /tmp/clamd

ERROR:

 ERROR: Clamd was NOT notified: Can't connect to clamd through /tmp/clamd

FIX:

 Add line to /etc/freshclam.conf

 NotifyClamd /etc/clamd.conf

DESC:

 This tells freshclam where to pickup the information about 'clamd' and how to notify the process.

[edit]

451 qq trouble creating files in queue

(with Mail not sent. Sending error: )
DESC:

 Trouble sending email from pine or other mail program on a 'qmail' enabled site.

CHECK:

 $ tail /var/log/mail
 $ tail /var/log/qmail/qmail-send/current 
 $ more /var/qmail/supervise/qmail-pop3d/run
 $ more /var/qmail/supervise/qmail-send/run

SOLUTION #1:

 Possible issues/problems with scripts, double-check installation instructions for correct commands and formatting

SOLUTION #2:

 Check recently changed xinetd config files.

SOLUTION:

 FROM: legend 02-18-2004, 04:29 AM, Posting

Then do this : chown -R vpopmail.vchkpw /var/spool/qmailscan

AFter that, it should run. The system does use the vpopmail identity when scanning the
mail with qmailscanner....

The point is, the user vpopmail needs to be able to read the configs and write to the log  
file. Besides that, it must be able to write the mail in working, so it should have write
there too. 

OTHER OPTIONS:
(last ditch effort)

 $ "make setup" 

From the qmail source directory should rebuild your mail queue, fixing any permission or other problems.
REFERENCES:

• http://www.sxpress.com/~henry/qmail-pop-imap-web-howto.htm
  

[edit]

(unknown)

FIX:

  /etc/init.d/clamd restart

RESULT:
FILE: /var/log/clamd/clamd.log

Feb  2 04:23:28 HOSTNAME clamd[6028]: Pid file removed.
Feb  2 04:23:28 HOSTNAME clamd[6028]: Exiting (clean)
Feb  2 04:23:28 HOSTNAME clamd[6028]: --- Stopped at Thu Feb  2 04:23:28 2006

Feb  2 04:27:02 HOSTNAME clamd[29316]: Daemon started.
Feb  2 04:27:02 HOSTNAME clamd[29316]: clamd daemon 0.88 (OS: linux-gnu, ARCH: i386, CPU: i686)
Feb  2 04:27:02 HOSTNAME clamd[29316]: Log file size limited to 1048576 bytes.
Feb  2 04:27:02 HOSTNAME clamd[29316]: Running as user qscand (UID 1009, GID 100)
Feb  2 04:27:02 HOSTNAME clamd[29316]: Reading databases from /var/lib/clamav
Feb  2 04:27:03 HOSTNAME clamd[29316]: Protecting against 43955 viruses.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Bound to address 127.0.0.1 on port 3310
Feb  2 04:27:03 HOSTNAME clamd[29316]: Setting connection queue length to 15
Feb  2 04:27:03 HOSTNAME clamd[29316]: Archive: Archived file size limit set to 10485760 bytes.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Archive: Recursion level limit set to 8.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Archive: Files limit set to 1000.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Archive: Compression ratio limit set to 250.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Archive support enabled.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Archive: RAR support disabled.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Portable Executable support enabled.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Mail files support enabled.
Feb  2 04:27:03 HOSTNAME clamd[29316]: OLE2 support enabled.
Feb  2 04:27:03 HOSTNAME clamd[29316]: HTML support enabled.
Feb  2 04:27:03 HOSTNAME clamd[29316]: Self checking every 1800 seconds.

[edit]

GENERIC GENERAL SOLUTIONS

• (All files should be owned by the Qmail Scanner 'qscand')

$ chown -R qscand:qscand /var/spool/qmailscan

• Directory is missing or incorrect permissions

$ mkdir /var/spool/qmailscan/tmp
$ chown qscand:vchkpw /var/spool/qmailscan/tmp

• I can't use qmail-scanner as I have an error during the ./configure that tell I can't do suid.

So i've installed the perl-suidperl rpm. but it is the same think. Here is the qmail-scanner FAQ :

A- Can't do suid: some perl distributions have decided that as running suid perl scripts is a rare event,  they won't install/enable it by default. On these systems this package won't work. Typically the fix is:

$ chown root /usr/bin/suidperl
$ chmod 4711 /usr/bin/suidperl

• Sometimes One solution I found was changing the owner/group to root/root for /var/spool/qmailscan.
  
  • Then using chmod 777 -R qmailscan/ . Not what I wanted to do but it works for now...
  
  

[edit]

WARNING: lstat() failed on: /var/spool/qscan/tmp/mail.example.ro132320635978813191/test_mail.zip

This is hapend beacause files are unzipped in the tmp folder with root user.
Clamd work with qscand user and no have rights to scan files.

SOLUTION:

Enter in qmail-scanner-queue.pl and search about this:

"&debug("u_f: $zip_status, and successfully unzipped");"

After that insert these two lines:

my $xchmod=`chown -R $ENV{'TMPDIR'} qscand:qscand . 2>&1`; 

&debug("u_f: change chmod to scand:qscand");   

This is not a better solution but it works.

Making FreeRADIUS and MSSQL work together

How to use FreeRADIUS with Microsoft SQL 2000

There aren't many start-to-finish howto's on this subject. I found some that described how to
get the SQL components working, and others that described how to get freeRADIUS to use a SQL
database (although they mostly talked about MySQL). So here I will attempt to document how
to do it from start to finish.




My requirements:

We are testing some wireless access points from a company called Extricom. We have some older,
el-cheapo Trendnet APs in some of our buildings, and with them, we've always left them wide open -
no logins required, no WEP/WPA, nothing. We are a small, private, liberal-arts school out in the
middle of nowhere, so I've never felt the least bit worried about our wireless allowing open access.
However, our department got a new boss last year, and she came from an uptight school down in Atlanta.
She isn't built to handle such open access, so she wants the Extricom stuff to at least require the
users to validate themselves before it will let them our our network. OK, that's fair enough,
she's not asking for encryption, just authorization. The Extricom gear will validate users against a
RADIUS server, so this should be pretty easy, I've just got to find a RADIUS server. And did I
mention that our primary network logins are done in Novell's eDirectory? Yes, we're also a
Netware site. That only adds more icing to the cake. :)




After looking around and asking, I found two Open Source RADIUS servers that run on Linux -
FreeRADIUS and OpenRADIUS. Of the two, FreeRADIUS is the only one that specifically mentioned
eDirectory in its docs, so that's the one I decided to learn and use. However, reading a bit further,
I found that using FreeRADIUS against eDirectory requires me to turn-on Novell's Universal Password.
Universal Password would require some changes that I don't want to make right now. So that leaves me
with three choices for where to store the usernames and passwords:

• Create UNIX accounts on the box running FreeRADIUS for all of my 1400 users.
  Err, no, I don't want to do it this way.


• Store the usernames and passwords in a Livinston or Cistron type text file.
  A better idea than UNIX accounts, but still not great - the text files have lots of
  flexibility, but there is still a bit of formatting to be done for each user in the file.



• Store the usernames and passwords in a SQL database. I've got a CPU license for MS SQL 2000
  on one of our Database servers, so this is what I'll do.

My RADIUS box specs:

• IBM ThinkCenter with a 3.0 Ghz P-4


• 1 Gig of RAM


• 20 gig HD


• Intel eepro100 nic (the IBM's built-in NIC is fried)



• RedHat 7.2

Yes, I used a fairly old version of RedHat. I had tried all of this on a Debian 3.1 box, but ran
into trouble. I've not used Debian much, so the Debian package system confused me at times.
I decided to try this with RH 7 because it's fairly stable and I've been using RH since the late '90s.




Software:


Using FreeRADIUS with MSSQL requires three components:

• FreeRADIUS - the radius server software


• FreeTDS - this is a set of libraries that know how to "talk" to a MSSQL server.



• unixODBC - this is a conduit between FreeRADIUS and FreeTDS.

At one time, I think FreeRADIUS supported FreeTDS directly, but for some reason the FreeRADIUS
folks removed that capability in recent versions. So we have to use unixODBC now. No biggie really.
It's still pretty simple.




I used the following versions on my box:

• FreeRADIUS 1.1.0


• FreeTDS 0.63


• unixODBC 2.2.11

If your distro has these as RPMs, debs, etc, you might be able to get it going with what the distro
provides. If so, you can skip the install instructions and focus on the configuration (but do be
careful as your files won't likely be in the same place that my files are). However,
since I may want to use eDirectory later, and since there is a special configure switch for
FreeRADIUS to turn on eDirectory support, I'm starting from scratch with all of them.





Compiling and installing:





The general order to compile these three components is:

1. unixODBC


2. FreeTDS


3. FreeRADIUS

Part I - compiling/installing unixODBC and FreeTDS

unixODBC:


pretty straightforward. Just do a standard

./configure

make

make install

However, if your Linux box doesn't have X Windows (mine doesn't), do a

./configure --enable-gui=no

so that it won't try to compile any GUI components.



The only components of unixODBC that you have to deal with are the configuration file
odbc.ini
and the isql "testing" program. The install routine puts odbc.ini in /usr/local/etc, and puts
isql in /usr/local/bin/ . You can't really tweak the ini file until after you've installed FreeTDS,
so we'll skip that part for now.




What you need from unixODBC: you need the odbc.ini file in /usr/local/etc and the
isql program
in /usr/local/bin.




FreeTDS:


again, pretty straightforward.

./configure

make

make install

I didn't need any options for ./configure. I think at one time you had to tell it where
unixODBC was, but versions since ~0.62 can find it by themselves (which is why you have to
compile/install unixODBC first... )




what you need from FreeTDS: the freetds.conf file in /usr/local/etc, the
libtdsodbc.so file in
/usr/local/lib, and the tsql testing program in /usr/local/bin





After you've got unixODBC and freeTDS installed, you almost ready to start configuring files and
testing your database connectivity.





Initial Test of FreeTDS:




Before you jump into the configuring part, do a quick test to make sure your box can actually
connect to your SQL server and that FreeTDS compiled and installed cleanly. (Note that at this point, we
aren't really using the unixODBC stuff yet). Use the tsql program
to do this. My SQL server name is blackboard, and I'll use a SQL username of "tester" and a password
of "letmein" to get in.

tsql -H blackboard -p 1433 -U tester -P letmein

If it works, you should see this:

locale is "en_US"


locale charset is "ISO-8859-1"

1>

If you see that, you know that you can at least talk to your SQL server. That is a Good Thing (tm).
If the test fails, try using the IP instead of the hostname (or edit your resolv.conf/update your
DNS records/etc). If it still fails, make sure you've, umm, you know, really GOT a SQL user on your
database server named "tester". If it still still fails, you've got mondo problems that I won't
get into here...




BTW - type "quit" to end the connection to the sql server.

Part II Configuring FreeTDS and unixODBC

Although you compile unixODBC before you compile FreeTDS, you have to configure them in the
reverse order.




Configuring FreeTDS:



So your initial test worked. Good. Now on to setting up a permanent host in FreeTDS. The primary
config file for FreeTDS is /usr/local/etc/freetds.conf. The file isn't terribly complicated,
and you can probably leave most of the configuration options alone. I didn't tweak any of them.
All you do have to add an entry that points to your database server. The ONLY things you need
in the freetds config file are the low-level networking stuff - the address of the server, the port
that SQL server is running on, and what version of SQL Server you're talking to. It doesn't care
about usernames/passwords, database names, etc. (the database name goes in the unixodbc config, the
username/password in one of the FreeRADIUS config files (mssql.conf)).




This is what the very end of my freetds.conf file looks like:

[mypool]

host = 127.0.0.1


port = 5000

tds version = 4.2



[blackboardhost]

host = blackboard.reinhardt.edu

port = 1433


tds version = 8.0

There are several other "sample" entries in the file. I deleted all of them except the mypool entry.
You can probably nuke it too, if you want.



Actually, if you're only going to be doing simple RADIUS authorizations, you can rem out the tds
version line. It will default to 4.2, which seemed to work OK for me when I tried it. But for
completeness, I left it in.





At this point, you should be able to test again with tsql. But this time, do it like this:

tsql -S blackboardhost -U tester -P letmein

You should get the same SQL prompt as before

locale is "en_US"

locale charset is "ISO-8859-1"

1>

The -S option tells tsql to use the entry "blackboardhost" in the freetds.conf file. If that works,
then your FreeTDS setup is complete.



If it doesn't work, check the entry in the freetds.conf file for spilleng erors. ;)





Configuring unixODBC:



The primary config file for unixODBC is /usr/local/etc/odbc.ini. The file is fairly simple.
Here's what my entire file looks like:

====================================

[ODBC Data Sources]

blackboardDSN = Radius on Blackboard



[blackboardDSN]


Driver = /usr/local/lib/libtdsodbc.so

Description = Radius on Blackboard

Trace = No

Servername = blackboardhost

Database = radius




[Default]

Driver = /usr/local/lib/libtdsodbc.so

====================================

Basically, it sets up a single data source (DSN) named blackboardDSN. AFAIK, you can name the DSN
whatever you want, the "DSN" part is just eye-candy I put on mine to distinguish it from the
server entry.

• Make sure the Driver entry is pointing to the right directory - you may find that other howto's
  say libtdsodbc.so is in /usr/local/lib/freetds/, but it's not there anymore. With the 0.63 version
  of FreeTDS that I used, it was put in /usr/local/lib.



• The Description is free text, I think. But since I'm superstitious, I made it exactly match the
  string in the ODBC Data Sources area.



• Trace is to turn on tracing. It's up to you.



• ServerName - this must exactly match the host entry you put in the freetds.conf file.
  This is how unixODBC ties itself to freetds. If this ain't right, you'll spin your wheels.



• Database - the name of the database. This is what FreeRADIUS expects the database on the server
  to be named. I don't think you can use any other name without severely hacking the mssql.conf file
  under FreeRADIUS... ;)

--------------------

Note to the clueless others like me: from what I can tell, unixODBC is meant to be a
"one-stop shop" for database connections, kinda like the "Data Sources (ODBC)" thing is in
Windows 2K/XP. It's a single "go to" area for programs that need to get to databases.
Hence, you could have multiple entries in the [ODBC Data Sources] section, then create a sub-section
for each of the entries. But we only need one entry for freeradius to use, so that's all that's here.


--------------------





There's also a odbcinst.ini file, but I don't know that it is really used (mine is empty and
things work OK). I only mention it here because several of the other websites say to put stuff in
it. But like I said, my odbc stuff works OK without it. (FWIW - I think there is an odbcinst
program that's kinda like a wizard that will help setup odbc connections in the odbc.ini file,
and odbcinst.ini is its config file. But for us, the odbc.ini file is simple enough that we don't
need it)





Create the "radius" database on your SQL Server:



Simple enough to do. Go into Enterprise Manager (if you're a slacker like me), and create a database
named "radius". You don't have to put any tables in it yet. You DO need to create a user that
FreeRADIUS will use (I'm just guessing that you don't want sa's password lying around in a text
file on a Linux server somewhere...), unless you've already gotten a username in mind. For now,
you can put the user in Public. That will be enough to run the tests. We'll change that when we
start configuring FreeRADIUS.





Final test of ODBC and FreeTDS:



Now the big test. Drumroll please. This test will determine whether or not you can use a
MSSQL server with FreeRADIUS. In other words, until you get this test to work, FreeRADIUS won't
be able to get to your SQL server.




We use the isql program, instead of tsql, to test our unixODBC connectivity.

isql blackboardDSN tester letmein

If it works, you'll see this prompt:

+---------------------------------------+

| Connected!                                         |


|                                                            |

| sql-statement                                       |

| help [tablename]                                  |

| quit                                                     |


|                                                            |

+---------------------------------------+

SQL>

Woohoo! It's working. Go get yourself a candy bar and a Coke to celebrate. You can skip over the next
part about troubleshooting.




Troubleshooting:




Uh-oh. It didn't work. Lucky you, there's a verbose switch (-v) to isql. It's very, very handy
in debugging problems.



As long as the "tsql -S" test works, you can rest assured that your isql problem is entirely
related to your lack of typing skills when transcribing the odbc.ini file or when typing in the
isql command. :)



For instance, here's what you get when you misspell the username or password on the isql command line:

[root@localhost /etc]# isql -v blackboardDSN testeeeer letmein

[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source

[28000][unixODBC][FreeTDS][SQL Server]Login incorrect.


[][unixODBC][FreeTDS][SQL Server]Login failed for user 'testeeeer'.

[ISQL]ERROR: Could not SQLConnect

Here's what happens when you misspell the DSN name on the command line:

[root@localhost etc]# isql -v blackbooooardDSN tester letmein

[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source


[ISQL]ERROR: Could not SQLConnect

Here's what you get when odbc.ini is pointing to the wrong directory for libtdsodbc.so, or when
the library name is misspelled.

(I changed it to point to the older location of /usr/local/lib/freetds/libtdsodbc.ini for this example)

[root@localhost etc]# isql -v blackboardDSN tester letmein

[01000][unixODBC][Driver Manager]Can't open lib '/usr/local/lib/freetds/libtdsodbc.so' :

/usr/local/lib/freetds/libtdsodbc.so: cannot open shared object file: No such file or directory


[ISQL]ERROR: Could not SQLConnect

Here's what happens when you misspell the ServerName in odbc.ini:

(I changed it to blackboooooardhost for this example)

[root@localhost etc]# isql -v blackboardDSN tester letmein

[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source

[ISQL]ERROR: Could not SQLConnect

Here's what happens when you misspell the database name in odbc.ini:

(radiuuus in this example)

[root@localhost etc]# isql -v blackboardDSN tester letmein

[S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source

[28000][unixODBC][FreeTDS][SQL Server]Login incorrect.

[][unixODBC][FreeTDS][SQL Server]Login failed for user 'tester'.


[][unixODBC][FreeTDS][SQL Server]Cannot open database requested in login 'radiuuus'. Login fails.

[ISQL]ERROR: Could not SQLConnect

Like I said, so long as the "tsql -S" test works, then the only place you have to look is in odbc.ini.
Using unixODBC really IS that simple at this point of the process.

Part III - FreeRADIUS

Now we get to the really ugly bit.



Compiling and installing FreeRADIUS:



Like the other two, this is just the standard

./configure

make

make install

On my box, I used the --with-edir switch to configure, since I may later try this against our
eDirectory tree, and this way I won't have to recompile. If you're not a Novell shop,
you can safely ignore that last sentence...




What you need from FreeRADIUS:


lots of stuff. The config files are in /usr/local/etc/raddb, and that's where you do all of your
work. The binaries go into /usr/local/sbin (or at least that's where the radiusd binary is.)
The "realm" libraries are put in /usr/local/lib, but you probably won't have to mess with them
unless you just want to check to confirm that a specific realm library was compiled and installed.




Starting FreeRADIUS for testing:



Start FreeRADIUS with:

radiusd

simple, no?




FreeRADIUS has a very (very, very) verbose mode that you can use for testing (or use it all the
time if you want). Use the " -X" (capital X) switch to turn it on.

radiusd -X

You'll see several screens of info scroll by. If you're using an xterm or a ssh term, you can
scroll back through the entries to see what's going on.




Initial FreeRADIUS test:



At this point, you can do a quickie test to make sure that FreeRADIUS installed OK and that it's
more or less working. By default, when FreeRADIUS installs it sets itself to authorize users from
either the "users" file (/usr/local/etc/raddb/users) or from the local Unix user accounts. The
users file is kinda icky, so I always test with my unix username and password (dave and davepass
for this example). To run the test, you'll use the radtest program.

radtest dave davepass localhost 1 testing123

• Since we want to test the local machine, we specify localhost. If your box has problems with
  that (yeh), try 127.0.0.1.


• The "1" is just some made up number - radtest expects a dial-in port number here, but we aren't dialing
  in, so we made up a number.


• "testing123" is the "secret", which I'll explain in the next section.

If it didn't work, hmm. It really should work. Maybe chek yur speling.



Configuring FreeRADIUS:



There are several steps to configuring FreeRADIUS :

1. Adding clients (ie - APs, dial-in boxes, etc) to the /usr/local/etc/raddb/clients.conf file


2. setting up the mssql file


3. setting up the radiusd.conf file

Adding clients to clients.conf



The clients.conf file determines what machines are allowed to query the radius server to lookup users. For
instance, your Wireless Access Points go here, and/or your NAS/Perle/LANRover dialin boxes. And don't forget to
add your test computer if you want to test from a machine besides the Radius box itself. (I use the freeware
NTRADPING from MasterSoft on my Windows workstation).



--------------------


Clueless Hint: Note that clients.conf does NOT have ANYTHING to do with the remote computers (ie - the laptops
trying to get on your WLAN, of a user's home PC that's trying to dial in). Those devices should be relying on
the AP or dial-in box to do all of the talking to RADIUS. I mention this here because it confused
me for a few minutes when I first saw it.


--------------------



Anyway, clients.conf isn't too big, but it IS full of comments and examples. You can put your
entries anywhere.



For clarity I put mine at the end. Here is the entry for my Extricom WLAN switch

client 172.20.254.70 {

secret = letmein

shortname = extricomgordy


}

Here's the entry for my Windows workstation where I run ntradping.

client 172.20.2.22 {

secret = dave

shortname = empty2

}

If you're new to radius, the "secret" may need 2 seconds of explaining. It's just what it says it is - it's a
secret. You tell the server what secret goes with which client entry, then you tell the client (access point,
dial-in box, etc) what the secret is and it sends the secret word anytime it makes a request. When a request
comes in, the radius server checks for the secret and ignores (or returns an error) if the secret is missing
or isn't what the server thinks it should be. I guess it's kinda like a password. Note that there is one secret
already in the clients.con file for the localhost entry - it's "testing123". That's what we used when we ran
radtest earlier.






Testing FreeRADIUS (second test):



Now that you've got some clients in the file, try testing from one of them. Kill the radiusd server you started
earlier (ctrl-C), then restart it before starting the test.




Here's a quick tutorial about using ntradping:


Here's what you have to fill in on the NTRADPING screen:

• RADIUS Server IP



• change the Port to 1812 (1645 is the "old" port for RADIUS)


• RADIUS Secret key (the one from the clients file)


• the User-Name and Password of the unix account you're trying to test


• set the Request Type to Authentication Request.

Then click the "Send" button.


If it works, you should get a "response: Access-Accept" line in the RADIUS Server reply box.



If you get an
Access-Reject response, check your spelling of the Secret key, username and password (stupid stars, but that's
another rant...), because those SHOULD be working OK since they worked when you did it on localhost.



If you get a "recvfrom() error, WSAGetLastError()=10054", check the port number.




If you get a loong pause after you click send, then you start getting noresponse and retries, check the IP address.



If it still doesn't work, check the clients.conf file on the server. Make sure you typed in the IP address and
secret correctly.




You MIGHT also need to tweak any firewall/iptables/ipchains rules that are running on the radius box (if any).
That might be blocking the connection down at the network level. I didn't install the firewall stuff on my RH7
box, because I didn't want any interference, so I dunno. But it's a possibility. Maybe you can just stop the
firewall by running "/etc/rc3.d/Sxxx stop" if you can figure out which Sxxx file it's in. Or you might have to
rename that link so it doesn't start with "S" and reboot the radius box - it could have tweaked the IP stuff at
boot up, so it might be easier to reboot. Sorry, I wish I had more info on the firewall stuff, but I don't.




We're coming down the home stretch now... I promise.




Configuring the mssql.conf file:



While not too hard to configure, the mssql.conf file is really ugly. Lucky for us, we only have to make a few
changes to it, and those are all at the "top" of the file. Just remember to check your double-quote marks.



1. Under Database type, make sure the driver line says

driver = "rlm_sql_unixodbc"

it already should say that, but be smart and check it.




2. Under Connect Info, set the "server" entry to be the DSN name you gave the connection in odbc.ini. Remember
that far back? Yes, it was long ago. Also, the "login" and "password" are for the SQL user on the database
server. I told you those were coming.

# Connect info

server = "blackboardDSN"

login = "tester"


password = "letmein"

3. The radius_db entry (under Database table configuration) should say "radius". If it doesn't, I can't help you
anymore, because that means the freeRADIUS guys have changed something big... ;)

# Database table configuration

radius_db = "radius"

4.The last thing you'll want to change is

# Print all SQL statements when in debug mode (-x)


sqltrace = no

sqltracefile = ${logdir}/sqltrace.sql

you really should set sqltrace to "yes" while you're debugging this. it will be a great help, as it will print out
all of the sql stuff when you run "radiusd -X". You can reset it to "no" after you've got everything working.




That's it for mssql.conf, you don't have to touch any of the other stuff in the file.




At this point, we have no way to test that mssql.conf is doing what we want, since radiusd doesn't know to use sql
yet. That's why it's so handy to turn sqltrace on right now, because you're really going to need it later...




Finally, we get to the last little bit of all this. Tying it all together in FreeRADIUS. Please wake up if you've
fallen asleep. My great work, umm, sorry, YOUR great work in all of this is soon to pay off and you'll want to be
awake when it does.




Configuring radiusd.conf:




This is prolly a good time for a break. Go get a coke and a smoke. walk around a little. Only a few more tweaks
and we're done.




radiusd.conf is a grand-pappy of a config file. In many ways, it's similar to Apache's httpd.conf file (in fact,
there is a section dealing with threads that looks really similar to Apache's. wink wink)



Anyway, we don't have too much to do in this file.



Way down around line 1225 (past the "acct_unique{" section) you should see a small section on SQL stuff.
Specifically, there should be a line that says:

$INCLUDE ${confdir}/sql.conf

rem that line out and add a line that reads:

$INCLUDE ${confdir}/mssql.conf

Congratulations, you just told radiusd to read your mssql.conf file when it starts. But, we aren't done yet.
Trust me, I tried it like this the first time, and kept wondering why it wasn't working. Duh! We still have to
tell radiusd to use SQL as an authorization source.



To tell radius to use SQL for authorization, scroll way, way down in the file to the "authorize {" section (the section
starts at around line 1727), then scroll down another 3 or 4 pages. You shold see the following block:

#

# Look in an SQL database. The schema of the database

# is meant to mirror the "users" file.

#


# See "Authorization Queries" in sql.conf

# sql

uncomment the sql line. Now you've told radiusd to use sql to lookup usernames and passwords.



However, there is one last little detail that you should be aware of. At around line 103, you can set the user and
password for the user that you want radiusd to run as. For now, leave them commented out, and it will run as you
(you are running as root, right???). However, once you've got everything going, you should go in and set these
(and turn off sqltrace, while you're at it). I think the way to do it is create a new unix user and make that user
the owner of the relevant stuff in /usr/local/etc , /usr/local/etc/raddb, /usr/local/lib, and /usr/local/sbin
(maybe not the stuff in sbin, I'm not sure). Or sit down and figure out how to shove all of this in a chroot jail,
if you're really paranoid.




Creating tables in the radius database:



You have to create the data table structures in the radius database on the SQL server. Luckily there is a script
for this. Yipee. It took me a while to find the script - I couldn't find the one for MS SQL in the source
directory, although there was one for MySQL, but it wouldn't work. Finally, I found it squirrelled away in the CVS
tree. I dunno why the FreeRADIUS guys aren't distributing it anymore. Maybe they got pissed off at Microsoft or
something. If you read the FreeRADIUS docs, you'll see references to the MSSQL schema, but afaik, it's NOT in
the source tarballs anymore, you can only get it from their CVS, or from my link below.




Fire up Enterprise Manager, browse to the radius database, and open Query Analyzer. The script is too long for me
to put inline here, so


here's a link.



Paste the script into the Query Analyzer window and run it. When it finishes, you can check a few
tables to make sure they have fields definied.




Next, the data.



For simple user/password authorization, you need data in three tables :

• usergroup



• radcheck


• radgroupcheck

-The username has to appear twice - once in usergroup, once in radcheck.


-The password goes in the radcheck table with an "op" field of " ==" (double equals).


-radgroupcheck is the simplest of the tables - it only needs one row of data in it -

• the groupname you used in usergroup


• attribute = "Auth-Type"



• value = "Local"


• op = ":="

Really, there's just ONE SINGLE RECORD in radgroupcheck, and it's that one. (Note: I've seen some
sites - maybe the FreeRADIUS docs themselves - say that if you don't have anything in
radgroupcheck, the Auth-Type will default to Local. I haven't tested this, so I can't verify it.
I don't know that it makes much difference one way or the other. I would imagine that freeradius
is still going to send queries for the table, it's just going to get an empty record returned.)



Here are my sample items:

The usergroup table:

id	UserName	GroupName
1	spongebob	static
2	patrick	static
3	plankton	static
4	squidward	static

The radcheck table:

id	UserName	Attribute	Value	Op
1	spongebob	Password	softy	==
2	patrick	Password	rockbrain	==
3	plankton	Password	squirt	==
4	squidward	Password	bignose	==

And the simple radgroupcheck table:

id	GroupName	Attribute	Value	Op
1	static	Auth-Type	Local	:=

I would imagine that the usergroup and radcheck tables are linked by their "id" field, although
I haven't found out for sure. I don't know if the UserName's have to be an exact match. I
would GUESS that it's better if they are...




The Groupname is "static". I don't know if that's a magic value in Radius, or if it's freetext.
It's what I found in one of web documents, so it's what I used here.



I didn't do anything with the radreply and radgroupreply tables on my box, they're still empty.



----------------------

Clueless NOTE: make sure you give the whichever database user you're using "select" rights to all
of the rad* tables and the
usergroup table. I tried using the Microsoft supplied "public" for mine, but it din't work.
The user does NOT need any write access unless you plan to use sqlaccounting (which I am not
doing, nor do I plan to. I don't care when or how often our little buggers log in.)
----------------------



Once you have a few test users in your database, you're ready to go to the FINAL FINAL Step.




RUN THE FINAL TEST OF FREERADIUS AND MSSQL.




Really, you're almost there. The train is either about to come roaring out of the tunnel
into the daylight, or
catch fire and burn down the mountain. If you've followed along, and your base distro isn't
too esoteric, you should be fine.



At this point, all that's left is to kill any running radiusd servers, and restart them. Be
SURE to use the -X switch. Also, you did turn sqltrace on in mssql.conf, didn't you?



For this test, it doesn't matter if you use ntradping or radtest. You should be way beyond
worrying about client secrets by now. Either way, give it a whirl. Did it work? If so, wow,
you got lucky. Please pick my next set of lottery numbers and email them to me. :)



For the other 99.9% of us, something didn't work. Hey, it's a kinda complex setup, and since
we haven't been able to test in several steps, we've got a lot of variables that could have gone
wrong. So many, in fact, that I won't go into them here. However, I will tell you some of
what the radiusd screen should show you.



If you scroll back to the start of the radiusd output, you should see a line around line 7 or
8 that says:

Config: including file: /usr/local/etc/raddb/mssql.conf

If you don't see that, check your radiusd.conf file to make sure you didn't misspell something up
around line 1225 where you told radiusd to include the mssql.conf file. Also, make sure it isn't
remmed out...




Scrolling on down the output, you should eventually see the start of where the SQL module loaded.

Module: Loaded SQL

sql: driver = "rlm_sql_unixodbc"

sql: server = "blackboardDSN"

sql: port = ""

sql: login = "radius"


sql: password = "br549"

Those should all look pretty familiar to you by now. You should also see several more settings
that were in mssql.conf that we didn't touch. Below them, you'll see a few pages of SQL queries.
After those, you'll see a few more settings. Finally you'll see the part that we're after.
The Good Stuff (tm). Look for this:

rlm_sql (sql): Driver rlm_sql_unixodbc (module rlm_sql_unixodbc) loaded and linked

rlm_sql (sql): Attempting to connect to radius@blackboardDSN:/radius

rlm_sql (sql): starting 0


rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #0

rlm_sql (sql): Connected new DB handle, #0

rlm_sql (sql): starting 1

rlm_sql (sql): Attempting to connect rlm_sql_unixodbc #1

rlm_sql (sql): Connected new DB handle, #1

If you see those, your database connection (and hence your mssql.conf file) are probably OK.
If you get errors, hopefully the errors are illuminating enough to show you what's wrong.



If the sql module loaded OK, then maybe it's a problem with the tables in the database, or a
problem with the user permissions for your sql user. Check all of them. Keep at it. This
stuff really does work once you get all the little buggies out.



===================================




Once you get the bugs worked out, Congratulations!, you have a functioning RADIUS server that
DIDN'T cost you $5,000. But don't think you can stop now. Start reading up on the encryption
stuff, and the other authentication stuff. The FreeRADIUS guys even have a book on Amazon
that goes into mind-numbing detail on those things. As well, a lot of The new wireless
equipment can often times do some amazing things, if you've got time to learn how to set it
all up. Now that you know how to install (and re-install) a basic RADIUS server, you can
build those services on it. You've got the foundation, so now start laying the bricks.


======================================

My running config files

For the sake of completeness, here are MY files that are known to work. Only the passwords
have been changed to protect the innocent (ie - me...)




odbc.ini

odbcinst.ini

freetds.conf

clients.conf

mssql.conf

radiusd.conf




And last but not least, here AGAIN is the SQL script to create the tables in
the database

freeradius-mssql.sql

Resources/Credits:

I pulled this howto together from several disparate sources, none of which really gave
start-to-finish instructions.





http://www.slashtmp.co.uk/index.php


(find the entry for February 7, 2006 - connecting to Microsoft SQL Server on *nix)





http://www.geocities.com/satish_patel_2000_2000/doc/freeradius.html


(the top half of the article deals with setting up FreeRADIUS, the bottom half deals with
the radiusd.conf tweaks for MySQL, as well as a layout of the tables and fields, and what
needs to be where. This is where I swiped my pretty Spongebob tables from...)



For the rest, I primarily read the docs for each package. Of them, FreeTDS and unixODBC have
some pretty decent docs. The FreeRADIUS docs just plain suck ass if you're not already a
FreeRADIUS hacker...



I would also like to thank my boss, without whose paranoid delusions of invasion I would
never have undertaken this little adventure.



David Doster

Network Admin


Reinhardt College