Monday, December 13, 2010
Run a script with administrative privilege
A great tool that allows you to run a script with administrative rights.
Wednesday, December 1, 2010
Friday, November 26, 2010
VMware tool
A colleague of mine showed me a great tool : VMware Powerpack.
This tool allow you to see a huge number of info's about your VMware infrastructure: last powered on machines, VMDK not used any more, ...
This tool allow you to see a huge number of info's about your VMware infrastructure: last powered on machines, VMDK not used any more, ...
Thursday, October 14, 2010
Treesize enemy
One of my colleague told me about a Treesize concurrent: Xinorbis. This one is more powerfull : report per file type, comparing history. This is free.
Tuesday, September 21, 2010
Firmware update for IBM
You need to update firmware on IBM hardware ? Use this tool. It will ask you which model you are trying to update and will then create a bootable CD with all the needed updates.
Thursday, September 9, 2010
Iphone directory lookup with Traveler
You cannot access a secondary address book from your Iphone using Traveler for Lotus Domino ? Stop traveler, rename the following file data\traveler\cfg\NTSConfig.xml in NTSConfig.old and restart Traveler.
Thursday, August 12, 2010
iPhone library lost? Recover files from your iPhone!
My hard disk crashed yesterday. Unfortunately I didn't have a backup of my iTunes library. If you plug your iPhone with a fresh installed iTunes it will not get back all the files from the iPhone.
I discovered a great tool named i-Funbox that let you transfer everything from the iPhone to your PC.
There are also commercial softwares with more features: PodToPc and TouchCopy.
I discovered a great tool named i-Funbox that let you transfer everything from the iPhone to your PC.
There are also commercial softwares with more features: PodToPc and TouchCopy.
Tuesday, May 18, 2010
Compiler cannot create executables under ubuntu
I frequently receive the following questions from friends: "I tried to compile something but get the following message Compiler cannot create executables under ubuntu".
Answer: just install the build-essential package.
Answer: just install the build-essential package.
Friday, May 14, 2010
Kerberos on iSeries-P6
One customer needed to have single sign on between iSeries session and Active Directory. So I decided to use kerberos. During the setup I had trouble getting a ticket for the iSeries using the kinit command. The error message was EUVF06007E Unable to obtain name of default credentials cache. After hours I found that the home directory for the user didn't exist on the iSeries. After having this one created with crtdir in /home everything ran fine.
Don't forget to check in the properties of Network Authentication Service that Use TCP is checked.
If you are using Windows 2008 you also need to change two parameters.
Add the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\allowTGTSessionKey needs to be dword and value equals 1
Computer policy\Windows Settings\Securyt settings\Local policies\Security Options\Network security: Configure encryption type : DES_CBC_MD5, DES_CBC_CRC
Important: the DNS resolution. Both workstations and server need to get the same result when using reverse lookup !
In case you are using Windows 7 as client you have to check the following points.
Don't forget to check in the properties of Network Authentication Service that Use TCP is checked.
If you are using Windows 2008 you also need to change two parameters.
Add the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\allowTGTSessionKey needs to be dword and value equals 1
Computer policy\Windows Settings\Securyt settings\Local policies\Security Options\Network security: Configure encryption type : DES_CBC_MD5, DES_CBC_CRC
Important: the DNS resolution. Both workstations and server need to get the same result when using reverse lookup !
In case you are using Windows 7 as client you have to check the following points.
- In Administrative Tools select
- Local Security policy
- Security settings
- Local policies
- Security options Select Network Security
- LAN Manager Authentication level and change it to "Send LM & NTLM responses"
- In Internet Explorer
- Internet Options
- Advanced
- Enable Integrated authentication
- The Network security: Configure encryption types allowed for Kerberos under Security Options likely is set to "No minimum". This needs to have DES_CBC_CRC turned on at minimum for Kerberos authentication to work properly. Once this is turned on the above authentication test should work as well as FIMO SSO.
KTPASS failed getting target domain for specified user
In order to get ktpass working you must specify user domain in the command.
ktpass -princ krbsvr400/6p.domain.ini@DOMAIN.INI -mapuser DOMAIN\6p -pass password -mapOp set
ktpass -princ krbsvr400/6p.domain.ini@DOMAIN.INI -mapuser DOMAIN\6p -pass password -mapOp set
Wednesday, February 24, 2010
Interesting tool
An unusual sniffer: driftnet. It will display pictures that travel across your network.
Thursday, January 28, 2010
Freeware NAS software
You need a NAS to test VMware ESX or Windows Clustering ? Hardware is too expensive ? Use one of these following Linux distributions: FreeNAS (http://freenas.org/freenas) or OpenFiler (http://www.openfiler.com/). Both can use NFS, iSCSI, CIFS.
Sunday, January 24, 2010
SSL Certificate in Lotus Domino
For a customer of our I needed to import a PKCS12 certificate in a Lotus Domino keyring. After having searched the Lotus Domino documentation I did not find the solution. I then began a deep google search and found the following utility: ikeyman. This latest provides export and import between PKCS12 and keyring.
Friday, January 8, 2010
Thursday, January 7, 2010
Postfix smtp auth configuration
I found the following intersting article http://www.oqube.com/services/system/postfix.html
Server configuration
Install SASL
apt-get install libsasl2
aptitude install sasl2-bin
apt-get install libsasl2-modules
The last line is very important: It took me a whole hour to figure that this was missing and prevented postfix from properly recognizing the presence of the sasl daemon !
Edit /etc/default/saslauthd, this is the file that configures the SASL authentication daemon on startup. Note that the working dir, which is to contain the socket for communication between client (postfix) and server (saslauthd), is set to a directory relative to the chroot jail of the postfix daemon:
START=yes
PWDIR="/var/spool/postfix/var/run/saslauthd"
PARAMS="-m ${PWDIR}"
PIDFILE="${PWDIR}/saslauthd.pid"
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
dpkg-statoverride --force --update --add root sasl 755 /var/spool/postfix/var/run/saslauthd
/etc/init.d/saslauthd start
testsaslauthd -u user -p secret -f /var/spool/postfix/var/run/saslauthd/mux
Don't know what the first line is for. The second one obviously starts the daemon (check with ps ax), and the third one is used to test the deamon using some referenced user on the host. Don't forget the -f parameter as the socket is not in its standard place.
Edit /etc/postfix/sasl/smtpd.conf
saslauthd_version: 2
pwcheck_method: saslauthd
mech_list: plain login
It is theoretically possible to add more methods in the mech_list parameter, eg. cram-md5 or digest-md5, but this prevents the client to authenticate properly (or so I think).
Edit /etc/postfix/main.cf
# sasl support for relaying mails
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
Note that there is a smtpdsaslpath that is somewhat confusing: this is not the path to the config file, but an arbitrary token that is passed to the server (kind of realm ?).
Then restart postfix:
/etc/init.d/postfix restart
If everything goes well, one can test with the following connection:
telnet www.oqube.com 25
Trying 213.251.185.91...
Connected to www.oqube.com.
Escape character is '^]'.
220 www.oqube.com ESMTP Postfix (Debian/GNU)
EHLO localhost
250-www.oqube.com
...
250-AUTH PLAIN LOGIN
...
The line 250-AUTH should list the available mechanisms defined in the smtpd.conf file.
Install the sasldb2 file correctly:
cp /etc/sasldb2 /var/spool/postfix/etc/
chown root:sasl /var/spool/postfix/etc/sasldb2
chmod 660 /var/spool/postfix/etc/sasldb2
sed -i -e 's/\(sasl:.*\)/\1postfix/g' /etc/group
For some reason, this file was not installed in the chroot jail by package configuration, and postfix need to access it (don't know why however because I did not use sasldb mechanism for authenticating).
Troubleshooting
I spent lot of a time working around a cryptic error appearing in postfix logs:
Feb 21 13:41:45 ns35748 postfix/smtpd[9736]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Feb 21 13:41:45 ns35748 postfix/smtpd[9736]: fatal: no SASL authentication mechanisms
Feb 21 13:41:46 ns35748 postfix/master[26660]: warning: process /usr/lib/postfix/smtpd pid 9736 exit status 1
Feb 21 13:41:46 ns35748 postfix/master[26660]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
This error was due to the missing installation of libsasl2-modules
Then I got:
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: SASL authentication failure: no secret in database
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: LMontsouris-152-62-50-113.w80-13.abo.wanadoo.fr[80.13.68.113]: SASL DIGEST-MD5 authentication failed:
authentication failure
Which I resolved by removing digest-md5 from the list of authentication mechanisms and setting up sasldb2 correctly.
Install TLS
We use plaintext authentication because we plan to use TLS, which creates a encrypted tunnel between the two hosts that prevent (hopefully) capture of passwords. TLS can also be used for client certificate authentication which is somewhat better as far as security is concerned. I plan to switch to that at some time in the future.
Edit /etc/postfix/main.cf
# activation of TLS
smtpd_tls_auth_only = yes
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /path/to/server.key
smtpd_tls_cert_file = /path/to/server.crt
smtpd_tls_CAfile = /path/to/CACertificatesList.crt
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
The important things to note are:
* first line enforces TLS for authentication. This means that no 250-AUTH banner is offered to the client until it does start TLS communication. This ensures that plaintext authentication is encrypted,
* server keys and certificates are generated as usual, either using self-signed certificate, or through a regular Certificate Authority. The smtpdtlsCAfile parameter points to root CAs certificates that are used to authenticate remote hosts.
IN the logs (/var/log/mail.log), one can see TLS in action:
Key generation
openssl genrsa -out /etc/ssl/private/oqube.key 1024
openssl req -x509 -new -key /etc/ssl/private/oqube.key -out /etc/ssl/certs/oqube.crt -days 3650 -subj '/CN=mail.oqube.com'
An example of failed certifcate validation (probably the remote server is using a self-signed certificate):
Feb 22 09:05:21 ns35748 postfix/smtp[28926]: certificate verification failed for exchange.norsys.fr: num=20:unable to get local issuer certificate
F
A succesful TLS connection from a client:
Feb 22 06:41:11 ns35748 postfix/smtpd[22745]: connect from artima.com[63.246.23.132]
Feb 22 06:41:11 ns35748 postfix/smtpd[22745]: setting up TLS connection from artima.com[63.246.23.132]
Feb 22 06:41:11 ns35748 postfix/smtpd[22745]: TLS connection established from artima.com[63.246.23.132]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
If everything works properly, one can see:
Trying 213.251.185.91...
Connected to www.oqube.com.
Escape character is '^]'.
220 www.oqube.com ESMTP Postfix (Debian/GNU)
EHLO localhost
250-www.oqube.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
The option is offered as 250-STARTTLS.
Server configuration
Install SASL
apt-get install libsasl2
aptitude install sasl2-bin
apt-get install libsasl2-modules
The last line is very important: It took me a whole hour to figure that this was missing and prevented postfix from properly recognizing the presence of the sasl daemon !
Edit /etc/default/saslauthd, this is the file that configures the SASL authentication daemon on startup. Note that the working dir, which is to contain the socket for communication between client (postfix) and server (saslauthd), is set to a directory relative to the chroot jail of the postfix daemon:
START=yes
PWDIR="/var/spool/postfix/var/run/saslauthd"
PARAMS="-m ${PWDIR}"
PIDFILE="${PWDIR}/saslauthd.pid"
MECHANISMS="pam"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
dpkg-statoverride --force --update --add root sasl 755 /var/spool/postfix/var/run/saslauthd
/etc/init.d/saslauthd start
testsaslauthd -u user -p secret -f /var/spool/postfix/var/run/saslauthd/mux
Don't know what the first line is for. The second one obviously starts the daemon (check with ps ax), and the third one is used to test the deamon using some referenced user on the host. Don't forget the -f parameter as the socket is not in its standard place.
Edit /etc/postfix/sasl/smtpd.conf
saslauthd_version: 2
pwcheck_method: saslauthd
mech_list: plain login
It is theoretically possible to add more methods in the mech_list parameter, eg. cram-md5 or digest-md5, but this prevents the client to authenticate properly (or so I think).
Edit /etc/postfix/main.cf
# sasl support for relaying mails
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
check_relay_domains
Note that there is a smtpdsaslpath that is somewhat confusing: this is not the path to the config file, but an arbitrary token that is passed to the server (kind of realm ?).
Then restart postfix:
/etc/init.d/postfix restart
If everything goes well, one can test with the following connection:
telnet www.oqube.com 25
Trying 213.251.185.91...
Connected to www.oqube.com.
Escape character is '^]'.
220 www.oqube.com ESMTP Postfix (Debian/GNU)
EHLO localhost
250-www.oqube.com
...
250-AUTH PLAIN LOGIN
...
The line 250-AUTH should list the available mechanisms defined in the smtpd.conf file.
Install the sasldb2 file correctly:
cp /etc/sasldb2 /var/spool/postfix/etc/
chown root:sasl /var/spool/postfix/etc/sasldb2
chmod 660 /var/spool/postfix/etc/sasldb2
sed -i -e 's/\(sasl:.*\)/\1postfix/g' /etc/group
For some reason, this file was not installed in the chroot jail by package configuration, and postfix need to access it (don't know why however because I did not use sasldb mechanism for authenticating).
Troubleshooting
I spent lot of a time working around a cryptic error appearing in postfix logs:
Feb 21 13:41:45 ns35748 postfix/smtpd[9736]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Feb 21 13:41:45 ns35748 postfix/smtpd[9736]: fatal: no SASL authentication mechanisms
Feb 21 13:41:46 ns35748 postfix/master[26660]: warning: process /usr/lib/postfix/smtpd pid 9736 exit status 1
Feb 21 13:41:46 ns35748 postfix/master[26660]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
This error was due to the missing installation of libsasl2-modules
Then I got:
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: SASL authentication failure: no secret in database
Feb 21 14:52:04 ns35748 postfix/smtpd[15470]: warning: LMontsouris-152-62-50-113.w80-13.abo.wanadoo.fr[80.13.68.113]: SASL DIGEST-MD5 authentication failed:
authentication failure
Which I resolved by removing digest-md5 from the list of authentication mechanisms and setting up sasldb2 correctly.
Install TLS
We use plaintext authentication because we plan to use TLS, which creates a encrypted tunnel between the two hosts that prevent (hopefully) capture of passwords. TLS can also be used for client certificate authentication which is somewhat better as far as security is concerned. I plan to switch to that at some time in the future.
Edit /etc/postfix/main.cf
# activation of TLS
smtpd_tls_auth_only = yes
smtp_use_tls = yes
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /path/to/server.key
smtpd_tls_cert_file = /path/to/server.crt
smtpd_tls_CAfile = /path/to/CACertificatesList.crt
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
The important things to note are:
* first line enforces TLS for authentication. This means that no 250-AUTH banner is offered to the client until it does start TLS communication. This ensures that plaintext authentication is encrypted,
* server keys and certificates are generated as usual, either using self-signed certificate, or through a regular Certificate Authority. The smtpdtlsCAfile parameter points to root CAs certificates that are used to authenticate remote hosts.
IN the logs (/var/log/mail.log), one can see TLS in action:
Key generation
openssl genrsa -out /etc/ssl/private/oqube.key 1024
openssl req -x509 -new -key /etc/ssl/private/oqube.key -out /etc/ssl/certs/oqube.crt -days 3650 -subj '/CN=mail.oqube.com'
An example of failed certifcate validation (probably the remote server is using a self-signed certificate):
Feb 22 09:05:21 ns35748 postfix/smtp[28926]: certificate verification failed for exchange.norsys.fr: num=20:unable to get local issuer certificate
F
A succesful TLS connection from a client:
Feb 22 06:41:11 ns35748 postfix/smtpd[22745]: connect from artima.com[63.246.23.132]
Feb 22 06:41:11 ns35748 postfix/smtpd[22745]: setting up TLS connection from artima.com[63.246.23.132]
Feb 22 06:41:11 ns35748 postfix/smtpd[22745]: TLS connection established from artima.com[63.246.23.132]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
If everything works properly, one can see:
Trying 213.251.185.91...
Connected to www.oqube.com.
Escape character is '^]'.
220 www.oqube.com ESMTP Postfix (Debian/GNU)
EHLO localhost
250-www.oqube.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
The option is offered as 250-STARTTLS.
Subscribe to:
Posts (Atom)