NuFW Handbook

NuFW is an advanced network filtering solution. For logging, as well as for domain integrations, it is highly recommended that all servers hosting NuFW services (nufw, nuauth, LDAP/Active Directory, and the logging server (SQLi/syslog/prelude)) be time-synchronized with a protocol such as NTP. NuFW does not provide time synchronization per se.

The nufw daemon only depends on:

A system with a kernel prior to 2.6.14 needs a patched version of the ip_queue module and of its "sibling" library libipq.

On kernel superior to 2.6.14, ipq is now deprecated in favor of libnetfilter_queue which uses the new nfnetlink system. On top of that nfnetlink also provides libnetfilter_conntrack which is used by NuFW to implement connection tracking, and strict time-based acls.

To use this features, the following libraries are needed:

You can find working versions of these libraries at http://nufw.org/download/libs/index.html Debian packages are available at http://www.nufw.org/debian/

If you plan to use NuFW time-based acls, it is best to use a kernel superior to 2.6.18 or to apply patches provided on NuFW site.

If you are installing NuFW from scratch, it is advised that you use the latest stable version. You should avoid distribution packages if they distribute old versions, especially if security upgrades have been notified in latest versions. NuFW security announces are always available at this URL.

          deb http://packages.inl.fr/ testing/
         

          deb http://packages.inl.fr/ stable/
         

Unless you are a developer or a very advanced user, we recommend that you do not attempt to use the trunk version of NuFW.

You should upgrade your installation at least when security announces are released in new versions. Security announces are always available at this URL.

You can easily find out which version of the software you are using, with each NuFW component, by using the -V switch with any program that we distribute :

# nuauth -V
nuauth (version 2.2.18 ($Revision: 5020 $))
# nufw -V
NuFW (version 2.2.19)
# nutcpc -V
nutcpc (version 2.2.19 $Revision: 5350 $)
        

As an alternative, you can also use your distribution's package manager to find out, for instance :

$ dpkg -l nutcpc
[...]
ii  nutcpc         2.2.19-1+inl1  The authentication firewall [client]
        

This is about copying the default certificates. Don't do that unless on very early tests ; you probably want to generate your own certificates: see next section.

For nufw

cp conf/certs/nufw-*.pem /etc/nufw/

For nuauth:

cp conf/certs/nuauth*.pem /etc/nufw/
cp conf/certs/NuFW*.pem /etc/nufw/

The management of certificates, or the use of a Public Key Infrastructure (PKI), is not covered in this howto. Using a dedicated software, like OpenCA or EBJCA, is suggested.

See section Hardening NuFW for details on how certificates are used in NuFW.

The following commands show how to quickly create a Certificate Authority, and some certificates for nufw and nuauth.

Generating your own Certificate authority:

mkdir private
chmod 700 private
openssl req -new -x509 -keyout private/CAkey.pem -out private/CAcert.pem

You have to set a strong password here and keep it secret.

Generating nufw and nuauth private keys:

openssl genrsa -out private/nufw-key.pem

openssl genrsa -out private/nuauth-key.pem

Generating Certificate Signing Requests for both nufw and nuauth keys:

openssl req -new -key private/nufw-key.pem -out nufw.csr

openssl req -new -key private/nuauth-key.pem -out nuauth.csr

Having our keys signed by the certificate authority we created:

openssl x509 -req -days 365 -in nufw.csr -CA private/CAcert.pem \
      -CAkey private/CAkey.pem -CAcreateserial -out nufw-cert.pem

openssl x509 -req -days 365 -in nuauth.csr -CA private/CAcert.pem \
      -CAkey private/CAkey.pem -CAcreateserial -out nuauth-cert.pem

Then, as in previous section, copy the files where needed: For nufw:

cp private/nufw-key.pem /etc/nufw/

cp nufw-cert.pem /etc/nufw/

For nuauth:

cp private/nuauth-key.pem /etc/nufw/

cp nuauth-cert.pem /etc/nufw/

And don't forget your key files (here, nufw-key.pem and nuauth-key.pem) should always remain private.

NuFW sources provide a sample configuration file for nuauth nuauth.conf which is available in the conf directory.

The two most important configuration variables are: nuauth_client_listen_addr which sets the address where nuauth listens for client requests and nuauth_nufw_listen_addr which sets the address where nuauth listens for nufw requests. The list of nufw servers authorized to connect to server nuauth is the nufw_gw_addr.

The next thing to do after setting this variable is to choose your authentication and acl checking module. Authentication modules for user have to be chosen in:

This is set with the option nuauth_user_check_module which default is libsystem (if not set in config file). Further choice for the acl checking module has to be done if you choose:

by setting the variable nuauth_acl_check_module.

We will test the setup by connecting from the local host ssh server. For this we need to add filtering rules to ask for authentication:

iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j QUEUE
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

^[2]

We will test the setup by connecting from the local host ssh server. For this we need to add filtering rules to ask for authentication:

iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j NFQUEUE
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

^[3]

First, the daemons need to be started. We start nuauth in a terminal

nuauth -vvvvvvvvv

then we start

nufw -s -vvvvvvvvv

in another terminal.

Next, we can try to connect a user. Under Linux it can be done with:

nutcpc -N -d -U [USERNAME] -H [NUAUTH IP]

Next step is to enter the user's password. Without the -U option, the current system user's name is used.

At nuauth level, we should see something like:

user bill@nufw uses OS Linux, 3.0.10, #1 Tue Oct 19 23:51:32 CEST 2008

If your PAM setup is based on shadow file, you will not be able to authenticate a user different from the one running nuauth. On this kind of setup, nuauth needs to be run as root to authenticate other users. ^[4]

Let's authenticate a ssh connection from the computer.

OpenLDAP server installation is standard. Use your Linux distribution packages, example with Debian:

apt-get install slapd

Read OpenLDAP Software Administrator's Guide, section "Building and Installing OpenLDAP Software" to get more information.

The file acls.schema has to be put in /etc/ldap/schema and a line

include         /etc/ldap/schema/acls.schema

has to be added at the beginning of the /etc/ldap/slapd.conf. In the level of access setup in this file, one can add:

#INL access for acls
access to  dn="ou=acls,dc=nufw,dc=org"
       by dn="uid=nufw,ou=Users,dc=nufw,dc=org" write
       by dn="uid=nuauth,ou=Users,dc=nufw,dc=org" read
       by dn="cn=admin,dc=nufw,dc=org" write
       by * none

nufw user is able to modify the policy and the nuauth user can only read the acls.

To speed up search request you can add the following index to your slapd.conf:

index OsName,OsRelease,OsVersion,AppName pres,eq
index SrcIPStart,SrcIPEnd,DstIPStart,DstIPEnd pres,eq
index Proto,SrcPortStart,SrcPortEnd,DstPortStart,DstPortEnd pres,eq
index SrcPort,DstPort pres,eq

You can start with a LDIF file such as:

dn: dc=nufw,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: nufw.org
dc: nufw
structuralObjectClass: organization

dn: ou=Users,dc=nufw,dc=org
objectClass: organizationalUnit
ou: Users
structuralObjectClass: organizationalUnit

dn: ou=acls,dc=nufw,dc=org
objectClass: organizationalUnit
ou: acls
structuralObjectClass: organizationalUnit

dn: uid=nuauth,ou=Users,dc=nufw,dc=org
objectClass: top
objectClass: simpleSecurityObject
uid: nuauth
userPassword: nuauth

dn: uid=nufw,ou=Users,dc=nufw,dc=org
objectClass: top
objectClass: simpleSecurityObject
uid: nufw
userPassword: nufw

To use LDAP support for acl checking, we need to modify the nuauth.conf file:

nuauth_acl_check_module="ldap"

and we have to setup the connection parameters:

ldap_bind_dn="uid=nuauth,ou=Users,dc=nufw,dc=org"
ldap_bind_password="secretpassword"
ldap_basedn="dc=nufw,dc=org"
ldap_acls_base_dn="ou=Acls,dc=nufw,dc=org"

INL has released a powerful Netfilter rules generator system for NuFW and Netfilter. It is called Nuface and it is available at: http://software.inl.fr/trac/wiki/EdenWall/NuFace It generates a set of rules for NuFW and Netfilter that can directly be applied from the web interface. All Netfilter rules generated by Netfilter use the stateful capabilities of Netfilter, without user intervention.

nuaclgen is a script that can help you maintain a simple set of acls in an LDAP tree.

It is advised that you use Nuface rather than Nuaclgen, if possible, since it makes things simpler. In particular, be aware that when you use nuaclgen, you need to also modify by hand your Netfilter rules.

The file nuaclgen.conf contains the informations about LDAP connections. It needs to be modified to suit your configuration, for example:

$ldap_host="localhost";
$username="uid=nufw,ou=Users,dc=nufw,dc=org";
$password="writepasswd";
$basedn="ou=Acls,dc=nufw,dc=org";

^[5]

To allow ssh for users of group 513 if they use /usr/bin/ssh application, we can use:

nuaclgen --Aclname cn=ssh,ou=Acls,dc=nufw,dc=org -p 6 --dport 22 -AppName "/usr/bin/ssh" -j ACCEPT -g 513

Or for access directed to a web server:

nuaclgen --Aclname cn=apt,ou=Acls,dc=nufw,dc=org -p 6 --dport 80 \
  -AppName "/usr/lib/apt/methods/http" -j ACCEPT -g 1042

This ACL gives access to group 1042 which is used by root user of some server of ours. Thus root user can only get file to update the computer, but other users can not access the web.

To achieve NuFW connection tracking it is necessary to have these options in nuauth.conf:

nuauth_log_users_sync=1
nuauth_log_users=9

MySQL server installation is standard. Use your Linux distribution packages, example with Debian:

apt-get install mysql-server

Read MySQL Documentation, section "2 Installing and Upgrading MySQL" to get more information.

PostgreSQL server installation is standard. Use your Linux distribution packages, example with Debian (replace 8.2 by the latest server version):

apt-get install postgresql-8.2

Read PostgreSQL Documentation, section "III. 14. Installation Instructions" to get more information.

The connection tracking system is really useful with SQL logging modules. We will describe here the setup of the MySQL module.

You have to create the SQL database from the dump file available in the conf/ subdir of the archive. Create a SQL account, which must have UPDATE, INSERT privileges on the "conntrack_ulog" table. You will have to set the credentials for that user in the nuauth.conf file.

You may choose between to schema an IPv4 only one and an IPv4/IPv6 one. Recent tools like Nulog2 are able to use the IPv6 schema. If you have old script or older tools, you better use the IPv4 only schema. To import the IPv4 schema into a newly created database, you can use:

mysqladmin create nufw
cat nulog.ipv4.mysql.dump | mysql nufw

For the IPv6 schema, simply use:

mysqladmin create nufw
cat nulog.ipv6.mysql.dump | mysql nufw

You may also want to rotate the "ulog" table, so that it doesn't grow to infinite size with time. The ulog_rotate.py script is available in the Nulog project tarball. At the present time, it is assumed those scripts are run as the root SQL user, as cronjobs. Of course the better way to go is to create a separate user for this and grant it the needed privileges. Please provide updates for this document if you implement this before we do.

If nuauth is configured to log network flow information in a SQL database, here is how the logging system works :

The SQL logging feature keeps track of the whole history of each connexion, and updates that nuauth performs on the database do never erase data that was previously logged. This log mode is the most powerful one that a firewall can achieve, because it is very synthetic : one single SQL entry is maintained for each connection ; and it keeps the whole history of all elements of connections.

nutop is a perl script provided with nufw sources. It is a top like tool that displays the active and authenticated connections in real-time.

The best way^[6] to use the logs generated by the connection tracking is to install nulog which provides a convenient web interface. nulog is available under GPL on this page: http://software.inl.fr/trac/wiki/EdenWall/NuLog

All you need to do is to setup a SQL user with SELECT permissions on the "conntrack_ulog" table. Then setup mod_auth_nufw to use the configured SQL user/database/table. The source code of the apache module is available at NuFW Apache SSO page

All you need to do is to setup a SQL user with SELECT permissions on the "conntrack_ulog" table. Then setup squid_nufw_helper to use the configured SQL user/database/table. The source code of the squid helper is available at NuFW Squid SSO page

Official Linux kernels are not able to mark packets with ip_queue framework before 2.6.14 release. It is thus necessary to patch the kernel (if pre 2.6.14), this has to be done by using the ip_queue_vwmark patch available in the patch-o-matic-ng from netfilter. This will generate a modified version of both ip_queue module and libipq.a file.

Once the new libipq.a is installed, you can now compile nufw:

./configure --with-user-mark ${EXTRA_OPTIONS_YOU_LIKE}
make
make install

nufw can now be run with -m to use userid marking. This option is compatible with -M.

As nufw only works with initialization packets it can not pull the userid mark of each packet of a connection. Thus, this is necessary to use CONNMARK^[7] which is a target able to propagate marks across connections. A basic setup is the following:

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

First line restores the existing mark when a packet arrives and second line saves mark on the connection so it can be restored later.

The nuauth variable nuauth_finalize_packet_module lists module which attach a hook called just before nuauth answer to nufw about a packet. It is usually used to modify the mark of the packet following a given strategy. By splitting the mark in different part, this is possible to define complex marking policy which can later be used by Linux routing and QoS systems.

Extensive documentation can be found in the file README.mark

Netfilter mark can be use by the Quality of Service system and the routing system of Linux.

So it is possible to do differentiated routing between different users by using command like:

ip rule add fwmark XXX lookup TABLE

This is almost the same for QoS, by using tc filter one needs to put user's flows in a specific class:

tc filter add dev IFACE  prio 5 protocol ip handle 102 fw flowid FLOWID

For more information about routing and quality of service you can read lartc.

NuFW can be used to implement strict time-based acls. When a period using time interval is defined (like say 08am-6pm) a authenticated connection can only start in the interval and is destroyed at the end of the interval.

Configuration is done by defining a set of periods and using them (by their name) in the acls backend. The plaintext acl backend uses the period key to defined the period to apply to the acl. The LDAP acls backend uses the TimeRange atttribute.

Definition of periods is done by modules and the corresponding option is nuauth_periods_module. For now, the only available module is xml_defs.

xml_defs is a period definition module. It uses a XML formatted file to store the periods. The path to this file can be set by using the xml_defs_periodfile:

xml_defs_periodfile="/etc/nufw/periods.xml"

The XML structure of the file is the following:

<?xml version="1.0"?>
<periods>
<period name="5x8" desc="open hour">
    <perioditem>
        <days start="1" end="5"/>
        <hours start="8" end="18"/>
    </perioditem>
</period>
<period name="long" desc="date example">
    <perioditem>
        <dates start="1128282" end="323232323"/>
    </perioditem>
</period>
<period name="interval" desc="one hour interval">
    <perioditem>
        <!-- Duration in second (1 hour) -->
        <duration length="3600"/>
    </perioditem>
</period>
</periods>

There are two major types of period definitions:

Multiple perioditem can be put in the same period to increase the flexibility of period definition.

The syntax is the following: Each option that sets up the use of a hook is a space separated list of modules.

For each module type, the syntax is as follows : name[:type[:config file]] If syntax is:

Let's analyze the following line: nuauth_user_logs_module="syslog dblocal:mysql maindb:mysql:/etc/nufw/mainmysql.conf" Packet will be logged multiple times:

It is highly recommended to install nuauth and nufw on a dedicated server, hardened for security. Other projects like GrSec ^[8] or SELinux ^[9] can be used to increase local (system) security.

To ensure confidentiality of communications between nufw, nuauth, and the clients, all connections are encrypted using TLSv1.

As the firewall policy is applied by nuauth, the trust relationship between nufw and nuauth should be verified. The certificate provided by nuauth during the TLS negotiation will be checked if a certificate authority is configured in nufw. This is done by using the -a option at start of nufw followed by the name of the certificate authority file. With this option set, nufw will require a signed certificate from nuauth, and verify it.

The CN (complete name) field from nufw certificate must contain the FQDN (fully qualified domain name) of nufw server.

Since release 2.2.18, NuFW runs in TLS strict mode by default. It means nufw will not start if nuauth certificate is:

See the Managing finer TLS settings with NuFW section of this document for advanced TLS options of nufw and other components.

To run nufw with strict TLS checking, you will have to specify the following option:

Thus a typical nufw command line should look like:

nufw -d nuauth.nufw.org -a localCA-cacert.pem -k server.nufw.org-key.pem -c server.nufw.org-cert.pem -r localCA-crl.pem

The option nuauth_tls_request_cert defines if client certificates are optional or not. Possible values are:

The default setting (nuauth_tls_request_cert=2) is that nuauth will require and verify client certificates for all connections (clients, and NuFW servers). Certificates are used to verify the identity of all components of a NuFW installation (nufw, nuauth, and clients), and ensure that no forgery or false representation has occurred.

All components must share the same certificate authority (CA). See the Managing finer TLS settings with NuFW section of this document for advanced TLS options of nuauth and other components.

The CN (complete name) field from nuauth certificate must contain the FQDN (fully qualified domain name) of nuauth server. All clients and nufw servers will check that the DNS name of nuauth server matches the name in the certificate.

You have to:

Warning: since release 2.2.18, this mode is now activated by default. You can disable it, at your own risks, by setting nuauth_tls_request_cert=0 in nuauth configuration file.

nuauth will check that the CN (complete name) field from nufw certificate contains the FQDN (fully qualified domain name) of the nufw server. You can disable it, at your own risks, by setting nuauth_tls_disable_nufw_fqdn_check=1 in nuauth configuration file.

You should also configure a Certificate Revocation List (CRL), with the nuauth_tls_crl parameter in nuauth configuration file. This file contains the list of all revoked certificates, in standard CRL format. You have to create a planified task (cron job) to update this file periodically, nuauth will check for modifications every nuauth_tls_crl_refresh seconds and will reload the file if necessary. You can use the HUP signal or the refresh crl command to force an update of the CRL.

You can restrict the number of simultaneous nuauth clients, per user or per IP address.

nuauth client (nutcpc or nuapplet) will verify nuauth certificate when connecting, if a certificate authority is configured on the client (option -A of nutcpc). The certificate of the nuauth server will be verified, and the DNS name must match the CN field of the certificate. See the Managing finer TLS settings with NuFW section of this document for advanced TLS options of nutcpc and other components.

You can disable, at your own risks, the verifications:

Clients should provide a client certificate, signed by the same authority.

The nutcpc client supports multiple options to achieve a strict verification of nuauth certificates:

To sum up a typical nutcpc command line should look like:

nutcpc -H nuauth.nufw.org -A localCA-cacert.pem -K client.nufw.org-key.pem -C client.nufw.org-cert.pem -R localCA-crl.pem

It is possible to use the configuration file nuclient.conf to specify value for these options and be able to run client without having to specify all options on the commandline. A typical nuclient.conf should look like.

# Name of the nuauth server (fully qualified domain name, or IP address).
nuauth_ip=nuauth.nufw.org
# Certificate authority used to check the validity of nuauth certificate
nuauth_tls_ca=/etc/nufw/localCA-cacert.pem
# Certificate file used to negotiate the TLS connection to nuauth.
nuauth_tls_cert=/etc/nufw/client.nufw.org-cert.pem
# Key of the certificate file from the nuauth_tls_cert option.
nuauth_tls_key=/etc/nufw/client.nufw.org-key.pem
# Certificate revocation list file to use.
nuauth_tls_crl=/etc/nufw/localCA-crl.pem

To combine strict TLS usage and login/password authentication, the recommended setup for client certificate deploiement is to deploy a per-computer certificate with FQDN matching computer domain name with the associated CA and key in the configuration directory of NuFW (usually /etc/nufw/). By setting the correct values in /etc/nufw/nuclient.conf (as previously seen), the computer user will be able to run client without providing any options (omit for -U option which is needed if the local user name is different from the nuauth user name).

Certificates can be used to authenticate clients, if a user provides a client certificate during the TLS negotiation. Nuauth will extract the username based on the CN of the provided certificate. The username computation is made by taking the CN string till a slash or a comma is encountered. For example, for admin/email=admin@inl.fr, it will return admin. The obtained username must match a known user on the system. Nuauth will check the certificate, and if validated, will mark the user as authenticated (no password asked).

To activate this functionality, nuauth configuration file must include:

nuauth_tls_auth_by_cert=1

Note that, nuauth_tls_request_cert has to be set to 1 or 2 in the mean time. If set to 2, certificates authentication is mandatory.

If the LDAP server supports TLS connections, you should setup nuauth to have the LDAP acls checking module using LDAP over SSL.

To do so, edit nuauth.conf and modify LDAP port to 636 (LDAPs):

ldap_server_port=636

Then, edit /etc/ldap/ldap.conf to indicate the policy used for SSL connections. If you only want to encrypt data, you can simply add to ldap.conf:

TLS_REQCERT never

The recommended setup is to fill in ldap.conf with the path to certificate authority. ldap.conf should look like:

TLS_CACERT /etc/ldap/cacert-ldap.pem
TLS_REQCERT demand

Please note that the certificate must precisely match the hostname set in the ldap_server_addr option in nuauth.conf.

See the TLS section in LDAP Configuration guide, and OpenLDAP TLS FAQ for more information.

On client side, system needs to be trustworthy to perform valuable application and OS filtering. You must never forget that it is the application on client side which tells the application name as well as the operating system name and version: these informations CAN and WILL be spoofed if a malicious user installs a modified NuFW agent.

Thus, the value of application and OS filtering depends on the trust you have on the system which issues the authentication. On a secure system (for ex. SELinux) where users can not install software, this sort of filtering is "quite secure".

NuFW is free software, and as such does not duplicate features from other softwares, but prefer to integrate with them, to benefit from their experience, and specific features.

For example, NuFW is a native Prelude^[10] sensor, using the nuprelude module. This allows to send alerts (user login success or failure, connections, etc.) to Prelude, and use correlation, for ex., to combine a Network IDS like Snort^[11].

See Prelude user manual, and Configuring NuFW for Prelude for more information.

PAM is a very convenient way for extending authentication to "exotic" directories. In particular, PAM lets one interface nuauth on NT domains, Active Directory, Radius, etc.

To have nuauth authenticate users based on PAM/ldap, use the system user checking module in nuauth.conf:

nuauth_user_check_module="system"

In addition, PAM needs to be properly setup, which is external to NuFW, and basically out of the scope of this document. Here are a couple of files to set on Debian to get PAM/LDAP working with nuauth: /etc/pam.d/nuauth:

#This is to set PAM-LDAP, modify to suit your needs!
  auth    required      /lib/security/pam_env.so
  auth    sufficient    /lib/security/pam_ldap.so
  auth    required      /lib/security/pam_deny.so

  account required      /lib/security/pam_ldap.so

  session required      /lib/security/pam_limits.so
  session optional      /lib/security/pam_ldap.so

The /etc/nsswitch.conf file also needs to be tuned:

#This is to set PAM-LDAP, modify to suit your needs!
  passwd:         compat ldap
  group:          compat ldap
  

(leave the other lines unchanged). And you probably also need to tune the /etc/pam_ldap.conf file. This file works for us, provided there is no line beginning with "uri":

  host 127.0.0.1
  ldap_version 3
  scope one
  pam_password crypt
  nss_base_passwd         ou=Users,dc=nufw,dc=org?one
  nss_base_group          ou=Group,dc=nufw,dc=org?one
  

You also need to install and configure libnss-ldap. Configuration that works for us (still on Debian) in /etc/libnss-ldap.conf:

  host 127.0.0.1
  base replace_with_your_base
  ldap_version 3
  rootbinddn cn=admin,dc=replace_with_your_base
  #Optional, set if you need these:
  nss_base_passwd ou=users,dc=nufw,dc=org?one
  nss_base_group ou=groups,dc=nufw,dc=org?one
  

Of course, tune this to suit your needs, and be aware that these system instructions may not be accurate for other distributions!

On Debian/Ubuntu, you will need the following packages:

    krb5-user
    krb4-config
    samba
    winbind
   

The /etc/krb5.conf file should contain something like:

[libdefaults]
        default_realm = DOMAIN.NAME
# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

[realms]
        DOMAIN.NAME = {
                kdc = 10.0.122.5
                admin_server = 10.0.122.5
                default_domain = DOMAIN.NAME
        }

[domain_realm]
        .domain.name = DOMAIN.NAME
        domain.name = DOMAIN.NAME
        shortname = DOMAIN.NAME
        .shortname = DOMAIN.NAME
   

It is very important that your system is time-synchronized with the AD/NT server. You should setup NTP to achieve this!

The /etc/samba/smb.conf file should also be customized:

[global]
# Change this to the workgroup/NT-domain name your Samba server will part of
   realm = DOMAIN.NAME
   password server = AD-SERVER
   netbios name = NUAUTH-SERVER
   workgroup = SHORTNAME

# server string is the equivalent of the NT Description field
   server string = %h server sexa-prn1 (Samba, Ubuntu)

####### Authentication #######

   security = ads
   encrypt passwords = true
   guest account = nobody

############ Misc ############

   socket options = TCP_NODELAY
   domain master = no

# Some defaults for winbind (make sure you're not using the ranges
# for something else.)
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   template shell = /bin/bash

   template homedir = /home/%D/%U
   client use spnego = yes
   client ntlmv2 auth = yes
   restrict anonymous = 2
   

To join the Windows Domain:

kinit administrator@DOMAIN.NAME

net ads join -U administrator

The last command should display the short domain name, and should specify that the machine was successfully added to the domain.

Winbind (or winbindd) should be running on your system. You can check things are going fine by reading samba logs (probably in /var/log/samba/*).

You will then have to declare that you want to use winbind authentication for nuauth by cooking a /etc/pam.d/nuauth file:

#This is to set PAM-winbind, modify to suit your needs!
  auth    required      /lib/security/pam_env.so
  auth    sufficient    /lib/security/pam_winbind.so
  auth    required      /lib/security/pam_deny.so

  account required      /lib/security/pam_winbind.so

  session required      /lib/security/pam_limits.so
  session optional      /lib/security/pam_winbind.so

To be able to use winbind group fetching, the /etc/nsswitch.conf file should look like:

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns mdns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
   

NuWinC (NuFW Windows Client) provides NuFW authentication for Microsoft Windows 95/98/NT/2000/XP/2003/Vista. This software is available from INL. NuWinC can provide, when installed on machines of a Windows domain, a 100% transparent behavior, meaning users will not even notice it starting or running. For more information about NuWinC, see http://www.inl.fr/NuWINc,68.html.

Several clients run on Linux :

MacOS X is supported by the Nuapplet2 graphical client. The nutcpc command line client also runs on MacOS X.

nutcpc is known to work on FreeBSD. For other systems, test feedbacks are greatly welcome! Porting NuFW agents to *NIX systems should be fairly easy, too.

pam_nufw accepts the following command line options:

Default values:

PAM configuration files are located in /etc/pam.d/. Each program which uses PAM may have its own file (eg. /etc/pam.d/ssh and /etc/pam.d/kdm) ; it is up to the administrator to choose which programs should trigger the pam_nufw authentication. Of course, requisite are :

A typical configuration file looks like this:

 #%PAM-1.0
 auth    requisite       pam_nologin.so
 auth    required        pam_env.so
 @include common-auth
 auth optional pam_nufw.so server=nuauth.inl.fr port=4129
 @include common-account
 session required        pam_limits.so
 @include common-session
 session optional pam_nufw.so server=nuauth.inl.fr port=4129
 @include common-password

We use auth because we have to know user's password in order to authenticate on nuauth. The pam module closes the connection to nuauth when the application closes the pam session. You can comment out the session line to suppress disconnection at logout.

pam_nufw respects the nuclient.conf configuration file for all options. See section Hardening NuFW for more information about nuclient.conf usage and TLS setup.

As RHEL4 is shipped with a 2.6.9 kernel that is subject to the ip_queue problem mentioned later in this document. With this kernel the bug occurs systematically (at least on SMP machines).

There's an ip_queue bug on kernels prior to 2.6.12. It can hang the system when an ACCEPT decision is done on the INPUT chain. Thus DO NOT use a QUEUE target on INPUT with these kernels or it could freeze your computer. And anyway, you should use a recent kernel and NFQUEUE, as explained here-up in this howto.

NuFW should run seamlessly in bridge networking. However it seems a bug in some kernel does not allow the use of nfnetlink without problems. The following facts were reported (with NuFW 2.2.14, but NuFW versioning is not the matter) :