The K Blag

Determine CSN update time from CSR in Directory Server 5/6

Mike — Mon, 22 Dec 2008 16:50:38 +0000

I needed to determine the update time for a particular attribute for one of my customers. I knew I had ran across how to get it from a csn attribute.

If you can obtain the CSN of an attribute, ie: from the nscpentrywsi operational attribute), the timestamp is the first 8 bytes of the CSN, in hex format.

ie:

nscpentrywsi: cn;adcsn-494d685d000000010000;vucsn-494d685d000000010000: The K

The timestamp in hex is: 494d685d

With a bit of perl magic, we can obtain the localtime value:

perl -e ‘print localtime(hex(”494d685d”)) . “\n”;’

Which returns:

Sat Dec 20 16:49:17 2008

bookmark to

Longer term self-signed OpenSSL Certificates and Sun DSEE Directory Server

Mike — Wed, 10 Dec 2008 14:28:15 +0000

I’ve long had an itch to scratch about the default 3-month duration of self-signed certificates available in Sun DSEE 6.x.

For the initial part, I’ve followed the instructions available at http://www.akadia.com/services/ssh_test_certificate.html.

Create your server’s key

# openssl genrsa -des3 -out server.key 1024

Make the key use no password, one less thing to remember.

# cp server.key server.key.org
# openssl rsa -in server.key.org -out server.key

We need to generate a certificate signing request, from the Sun Directory Server (DSEE).

cd /path/to/dsadm

./dsadm request-cert –name “ldap.example.com” –org “Example.com” –org-unit “IT” –city “New York” –state “New York” –country “USA” /path/to/ldap > /tmp/server.csr

Sign the certificate request locally, using the key we generated ourselves. In my case, I’m making it good for approximate 10y (3650 days)

# openssl x509 -req -days 3650 -in /tmp/server.csr -signkey server.key -out
server.crt

We now have a cert as server.crt we need to add to the directory keystore

./dsadm add-cert /path/to/ldap ‘ldap.example.com’ server.crt

./dsadm restart /path/to/ldap
./dsconf set-server-prop -h hostname -p 389
ssl-rsa-cert-name:ldap.example.com

Thats all it takes to get your server running with a self-signed 10y certificate.

bookmark to

Directory Server 6.3 released

mike — Wed, 16 Apr 2008 16:51:48 +0000

Sun released their Directory Server Enterprise Edition 6.3. This fixes at least one critical issue with database corruption.

You can get the full version from Sun at: http://www.sun.com/software/products/directory_srvr_ee/index.jsp.
Patches are available via Sunsolve:

Source available here.

bookmark to

APC Network Shutdown and Solaris 10 firewall

Mike — Wed, 26 Mar 2008 20:18:10 +0000

One day, not too long ago, when the power went out in my neighborhood (for some unknown reason), I was pondering whether or not the machines here would shutdown cleanly. I knew I had a reasonable amount of battery life, but that wouldn’t be enough if the outage was extensive.I had already configured the APC UPS (with the network card) to my satisfaction, and also loaded the APC Network Shutdown software into the root zone of my Solaris 10 x86 box. Over the course of many tests, I realized that my Solaris 10 firewall was in the way. I had to create a new rule to allow any UDP traffic, originating from the APC network interface, to allow communication to the broadcast IP address of my local network. At first, I only allowed specific communication between the two via UDP, but after much examination, realized it was broadcasting.Here are my IPF rules:

pass  in  quick on nge0 proto udp from 10.0.0.10 to any port = 3052

pass  in  quick on nge0 proto tcp from 10.0.0.10/32 to 10.0.0.2 port = 2161 flags S keep state

pass  in  quick on nge0 proto tcp from 10.0.0.10/32 to 110.0.0.2 port = 3052 flags S keep state

pass  in  quick on nge0 proto tcp from 10.0.0.10/32 to 10.0.0.2 port = 6547 flags S keep state

Hope this saves someone some headaches in the future.

bookmark to

Blocking E-Mail By Sender Domain using Sun Java Messaging Server

Mike — Thu, 13 Dec 2007 16:05:27 +0000

With the Sun Java Messaging Server, you can block inbound mail based on the senders E-Mail domain (as self-reported in their E-Mail), also known as their From: address. In the example here, I want to block all inbound email with a From: address from Zambia (TLD: .za). It doesn’t matter where in the world it is sent from, any inbound E-Mail that is said to be from a .za domain will get blocked automatically.

In order to keep my mappings file (/opt/msg/msg-test/config/mappings) more readable, and to keep the items organized, I created a file of domains that I block, and include it in my mappings file in the right section. I named my file /opt/msg/msg-test/config/orig_send_access_block.txt .

I do an include of the file in the ORIG_SEND_ACCESS section of the mappings file. It is the first content line, as such:

ORIG_SEND_ACCESS

tcp_local|*|tcp_local|* $N$D30|Relaying$ not$ allowed

The contents of the orig_send_access_block.txt file are as follows (each line is indented 2 spaces):

tcp_local|*.za|*|* $NNo$ thank$ you$ Zambia

I ensured the files were readable by the id that runs Sun Java Messaging Server, then re-compiled and restarted the imsimta dispatcher.

./imsimta cnbuild

./imsimta chbuild

./imsimta restart

bookmark to

Enable E-Mail Reminders on Sun Java Calendar Server 6.3

Mike — Wed, 12 Dec 2007 14:17:51 +0000

Recently, I needed to enable E-Mail reminders for Sun Java Calendar Server 6.3. I thought they were enabled by default, and peering through the documentation available, thought I had confirmed my suspicions. However, being pragmatic with the available documentation, I decided to specifically define the available configuration options.

In the /opt/SUNWics5/config/ics.conf file, I changed the following option from:

!
! Enable binary alarms. Used by csnotifyd and csadmind. (default: yes)
!caldb.serveralarms.binary.enable = “yes”

To the following:

!
! Enable binary alarms. Used by csnotifyd and csadmind. (default: yes)
caldb.serveralarms.binary.enable = “yes”

And restarting the server. Voila! Uncommenting the (supposedly) default value worked! Calendar E-Mail reminders enabled.

bookmark to

Blocking E-Mail By IP Address Using Sun Messaging Server

Mike — Tue, 11 Dec 2007 15:26:19 +0000

I’ve been getting increasing amounts of Unsolicited Bulk E-Mail, or Spam from certain ranges of IP Addresses that have not been sending any legitimate E-Mail. I’ve wanted to block these IP ranges when they first connect to the mail server, and before my (expensive) Spam filter needs to run.

The first step is to identify the IP addresses sending you bulk E-Mail; or if you want, you can get an entire set of IP Addresses, already sub-netted for use by Sun Messaging Server at http://ip.ludost.net/. For our purposes here, we want to block the IP Address range 192.231.176.0/24.

Create a file (much easier to maintain a single file than to continually edit the mappings file); with a name like port_access_block.txt and add the line as such (note, there are 2 spaces at the beginning of the line):

TCP|*|25|$(192.231.176.0/24)|* $T$N500$ No$ thank$ you

when the file is created, edit the mappings file, adding a link to your newly created file in the PORT_ACCESS section. My updated PORT_ACCESS section looked like:

PORT_ACCESS

*|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
* $YEXTERNAL

Ensure the port_access_block.txt is readable by the user running your mail server; then recompile and restart your messaging server.

All E-mail to your mail server from remote machines in the IP address range listed will rejected immediately with a fatal error.

bookmark to

Enable Sun Messaging Server to use SpamAssassin

Mike — Mon, 10 Dec 2007 16:50:50 +0000

Like many others, I’ve been receiving an ever greater amount of Spam in my E-Mail box. I decided to take action and deploy SpamAssassin on my Sun Messaging Server (6.3) in order to reduce amount of Spam E-Mail I receive.

First of all, I deployed SpamAssassin. Being as I’m on Solaris 10 x86, and use Blastwave for package management; I installed SpamAssassin thusly:

pkg-get -i spamassassin

It will install all the pre-requisite packages; as well as the SpamAssassin package. With SpamAssassin, there is a tad bit of post-installation configuration (to set it up to run as a service) located at /opt/csw/doc/spamassassin/README.CSW.

When SpamAssassin’s spamd process is successfully up and running the Sun Messaging Server configuration needs to be modified in order to call out to SpamAssassin. This is done first by creating a configuration file, generally in the config directory. I named mine spamassassin.cf with the following contents:

host=127.0.0.1
port=783
debug=1
mode=1
field=

host denotes where the spamd daemon lives; in my case on the local host.

port denotes what port the spamd daemon is listening to; in my case 783 (default).

debug denotes whether the Sun Messaging Server maintains debug information about its talking to SpamAssassin; 0 for off, 1 for on

mode denotes when a score will be handled. mode=0 specifies that no result string is returned. mode=1 specifies that the SpamAssassin result string is returned if the message is found to be spam. mode=2 for all messages

field specifies a string prefix for the SpamAssassin result string.

The config I have above works well for filtering messages based on score into a separate folder. A later post will make some changes in order to reduce messages that exceed a higher score.

Another change needs to happen to the option.dat file (located in config). Add the following lines to this file.

!
! SpamAssassin
spamfilter1_config_file=/opt/msg/msg-test/config/spamassassin.cf
spamfilter1_library=/opt/msg/msg-test/lib/libspamass.so
spamfilter1_optional=0
spamfilter1_string_action=data:,require “fileinto”; fileinto “Spam”;

The spamfilter1_config_file is the location of the config file above.

The spamfilter1_library is the full path to the .so file for libspamass.so that comes with Sun Messaging Server.

The spamfilter1_optional denotes whether SpamAssassin is bottlenecking inbound mail (0) or it will proceed and deliver as normal if SpamAssassin has an error (or is not up) (1).

The spamfilter1_string_action specifies what happens when a message is found to be Spam. In our case, it will file it into a folder named Spam.

The final step is to update the imta.cnf file to specify that messages should go to the Spam Filter. Update the ims-ms line to add the destinationspamfilter1optin spam option to the line.

After deploying SpamAssassin, mine looks like:

ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff “pt5m” “pt10m” “pt30m” “pt1h” “pt2h” “pt4h” maxjobs 2 pool IMS_POOL fileinto $U+$S@$D destinationspamfilter1optin spam

With a final ./imsimta cnbuild; ./imsimta chbuild; and an ./imsimta restart; Spam filtering should be in place.

Reference information from Sun about deploying SpamAssassin.

bookmark to

Greylisting Email with Sun Messaging Server using grossd

Mike — Sat, 08 Dec 2007 04:49:13 +0000

One of the best weapons I’ve used in the larger battle against unsolicited bulk Email, or SPAM, as it is commonly referred; is Greylisting.
Greylisting is very effective for reducing the volume of SPAM an Email server takes in by returning a temporary error during the conversation to the remote MTA, essentially saying to come back in a few minutes. While some MTA’s do not support resending, the vast majority do.
grossd takes this a bit further. While also working with the Sun Messaging Server (6.3 in my case); it only forces the temporary error for remote MTA’s that are on its set of blacklists. While it doesn’t explicitly reject the message outright, it does force the remote MTA to at least retry in order to send the message.

Configuring a (standalone) Sun Messaging Server MTA is fairly straightforward. It requires the c-ares DNS library to be compiled and installed. Then the grossd code needs to be compiled and installed. A gcc compiler other than the default installed in /usr/sfw on Solaris 10 may not be sufficient.

The summary installation instructions for c-ares.

# gunzip -c c-ares-1.4.0.tar | tar xf -
# cd c-ares-1.4.0
# ./configure –prefix=/usr/local
# make && make install

The summary installation instructions for grossd.

# gunzip -c gross-0.8.2.tar.gz | tar xf -
# cd gross-0.8.2
# ./configure –prefix=/usr/local
# make && make install

I needed to make a single change in /usr/local/etc/grossd.conf; which was to simply comment out the following line:

protocol = postfix

So that it reads:

#protocol = postfix

Once grossd is configured, it needs to be started, and probably have a startup script to automatically make it run at boot.

#!/sbin/sh

case “$1″ in
start)
[ -f /usr/local/etc/grossd.conf ] || exit 0
/usr/local/sbin/grossd -f /usr/local/etc/grossd.conf
;;
stop)
pkill grossd
;;
*)
echo “Usage: $0 { start | stop }”
exit 1
;;
esac
exit 0

I started grossd using the script:

# sh /etc/init.d/grossd start

# ps -ef | grep -i gross

root 21356 1 0 Oct 24 ? 9:00 /usr/local/sbin/grossd -f /usr/local/etc/grossd.conf

With grossd running, the Sun Messaging Server config needs to get tweaked. Edit the mappings file; adding the following section. Please be careful to have a complete newline before the beginning of the section, immediately following the section name, and following the contents of the section. There are 2 spaces leading off the TCP line, in case they are not clear.

ORIG_MAIL_ACCESS

TCP|*|*|*|*|*|*|tcp_local|*|*|* $[/usr/local/lib/grosscheck.so,grosscheck,127.0.0.1,,1111,$2,$=$8$_,$=$6$_]

After making this change, recompile the configuration, and test grossd.

# ./imsimta cnbuild

# ./imsimta chbuild

After testing; restart the messaging server;

# ./imsimta restart

To determine the number of messages that greylisting has worked on, you can grep on the mail logs for the string “452 4.4.3″

# grep -ic “452 4.4.3″ mail.log_current

29536

bookmark to

Backing up and Restoring data from Directory Server 6

Mike — Mon, 26 Nov 2007 19:54:10 +0000

One of the largest problems that I have noticed when doing directory deployments, are either invalid, or non-existent backups of their directory information. They often assure peace of mind when things unexpectedly go wrong (a la unexpected power outages).

I’ve found a good reference to how to do backups with Directory Server 6; and won’t rehash them here.

In essence, it may become necessary to have a single instance dedicated to doing routine backups in a large environment. This is because you need to be able to turn the instance to read-only for the duration of the backup.

bookmark to