Archive for the 'Systèmes sales' Category

Client Windows XP, KFW, KDC Unix et Mozilla

Published on September 21, 2009 in AdminSys, Systèmes sales and Sécurité. 0 Comments Tags: , , , , , , .

Un petit post pour mémoire sur le fonctionnement d’un client Windows XP avec KFW (Kerberos For Windows) et les outils Mozilla. Mon but est de proposer une authentification Kerberos aux utilisateurs itinérants : non raccordés à un domaine, compte local à la machine et authentification (au moment du login) non liée au KDC. KFW est un utilitaire distribué par le MIT qui permet d’intégrer une couche GSSAPI “traditionnelle” dans Windows. En effet, Windows utilise une variante fermée de la GSSAPI qui se nomme SSPI (Security Support Provider Interface). L’installation de KFW n’est pas compliquée (suivant, suivant et terminer). Une fois installée, on doit configurer le fichier krb5.ini (qui ressemble comme deux goutes d’eau au krb5.conf). Voici un exemple minimal :

[libdefaults]
	default_realm = MONDOMAINE.FR
 
[realms]
        MONDOMAINE.FR = {
                kdc = kdc.mondomaine.fr
        }
 
[domain_realm]
	.monrealm.fr = MONDOMAINE.FR
	mondomaine.fr = MONDOMAINE.FR

Ensuite, il suffit de cliquer pour obtenir les credentials (TGT). Ensuite, pour les applications Mozilla il faut faire un petit réglage. En effet, Firefox et Thunderbird utilisent par défaut la SSPI. On peut forcer l’utilisation de la GSSAPI en désactivant le SSPI. Pour ce faire, dans “Outils”, “Options” et “Editeur de configuration” placez le network.auth.use-sspi à false.

MacOS 10.5 et OpenLDAP START_TLS

Published on June 24, 2008 in AdminSys, Linux, Systèmes sales and Sécurité. 0 Comments Tags: , , , , , , .

Voila deux jours que je tentais de forcer une authentification depuis MacOS 10.5 sur un serveur slapd configuré en start_tls. Le start_tls fonctionnait avec le /etc/openldap/ldap.conf adéquat et les outils ldap* (search, modify …). Confiant, je lance le cliquodrome :

Aller -> utilitaires -> utilitaires d’annuaires :
Mon serveur LDAP apparaît avec un joli point vert (“ce serveur répond normalement”).

services -> LDAPv3 :
Activer : OK
Nom de la config : bla bla
Nom serveur : mybigldap
Mappage LDAP rfc 2307 (Unix)
SSL : OK
Propriétées activées :
- Chiffrer via SSL
- Utiliser le port personnalisé 389

C’est l’erreur, j’ai supposé (ne jamais supposer en administration système !) que ça allait se démerder et passer sur du start_tls côté client comme j’avais demandé le chiffrement SSL.

Seulement, côté serveur dans le /var/log/debug, aucune mention de start_tls.
Juste des message du style :

Jun 24 10:41:41 mybigldap slapd[15075]: conn=1000 fd=47 closed (connection lost)
Jun 24 10:41:56 mybigldap slapd[15075]: conn=999 fd=31 closed (connection lost)

Juste après les ACCEPT relatifs à mon client MacOS X.
En conclusion, ça se démerde pas, ça fait vraiment du SSL.
Il faut donc lancer une instance du serveur (voir /etc/default/slapd) en SSL (ldaps sur port 636).