Il laboratorio del progetto ISI

Descrivi qui gli esperimenti in corso. Usa questa pagina per annotare prove riuscite o fallite.

Splash screen

• splash screen per grub/isolinux:
  

ARGO via live-helper Howto

Documentazione preliminare sui tentativi per utilizzare il progetto DebianLive per la costruzione di Argo: IsiDebianLive

Single Sign On

Innanzitutto vorrei fare alcune premesse doverose.

Attualmente il progetto ISI prevede che le utenze siano tutte centralizzate in una directory ldap, e tutti i client, siano linux, windowsXP o Windows98 (questi via samba) si autenticano usando le medesime credenziali. Tutto questo ha comunque ancora alcuni difetti, infatti, se è vero che la password è una sola per tutti i servizi, è anche vero che questa deve essere reimmessa ogni volta. Ad esempio quando si vuole accedere ad internet, nel caso sia stato configurato squid per tracciare le utenze. La prospettiva di non tracciare le utenze, con un branco di 500 alunni che si aggirano per la rete scolastica, non è evidentemente praticabile. La soluzione: kerberos. Perché? perché con kerberos è possibile organizzare un sistema di vero single sign on: l'autenticazione avviene una sola volta all'inizio (e come vedremo, senza che le password girino per la rete, altra cosa non disprezzabile) dopodiché si ottiene un ticket, spendibile con i vari servizi per poterci autenticare, la qual cosa viene gestita dai vari software (ad. es. IE o Firefox nei confronti di squid).

La seconda premessa che vorrei fare è che mi sento un po' come un kamikaze lanciato con il suo computer verso un muro da abbattere, infatti non so al momento se quello che ho in mente riuscirò a realizzarlo, ma sono sicuro che dalle macerie che potrei creare qualcuno di più preparato (Massimo e Sandro ci siete? ;-P ) saprà generare qualcosa di concreto e stabile così come è stato per il progetto ISI sin qui. Perciò non aspettatevi che questa sia una guida completa, semplicemente perchè non lo è. Sono solo appunti iniziali rivolti a chi si occupa del progetto ISI e che sa cosa siano e come funzionino ldap, bind, samba, pam, nss, squid ed è a digiuno del solo kerberos. Ma allora perchè non seguire una guida di quelle che si trovano in internet? bravi: trovatela, io non ci sono riuscito, almeno a trovarne una che spiegasse esattamente quello che voglio io.

Le seguenti sono precisazioni di carattere tecnico:

Il software che ho usato è: Kubuntu come SO: perchè è basato su debian e ISI è basato su debian e nello stesso tempo è sufficientemente aggiornato per poter usufruire di pacchetti con tutte le nuove caratteristiche.

Openldap per il database degli utenti: perchè è lì che si trovano già gli utenti ISI

Heimdal Kerberos: preferito al MIT Kerberos perchè può facilmente salvare il suo database in Ldap e perchè è fortemente consigliato dai creatori di Samba 4

Samba 4: non esiste ancora! ma è quello che servirà per far sì che anche Samba possa comportarsi esattamente come Win2000 rilasciando i tickets

Infine: in rete è possibile trovare della documentazione su come collegare ldap e kerberos, ma vorrei sottolineare che le possibili configurazioni sono più di una, ad esempio è possibile tenere separati i due database kerberos e ldap e fare in modo che ldap cerchi le password degli utenti in kerberos, oppure fare in modo che kerberos salvi il suo database in ldap. Quest'ultima è la mia scelta. Perciò, chi avesse ad esempio letto l'ottimo documento di Simone Piccardi "Sigle Sign-On con Kerberos e Ldap", noterà delle differenze nella configurazione del server.

E adesso partiamo.

Pacchetti deb necessari

per Heimdal Kerberos: libsasl2-modules-gssapi-heimdal heimdal-clients heimdal-kdc heimdal-server

Per Openldap: ldap-server ldap-utils

Per permettere a nss e pam di usare ldap e kerberos: libpam-ldap libnss-ldap libpam-heimdal

quando si installano i pacchetti ldap viene fatta una prima configurazione, metteteci cose del tipo valbruna.lan per ldap e cn=manager,dc=valbruna,dc=lan come amministratore. Per kerberos mettete come Realm in maiuscolo qualcosa del tipo VALBRUNA.LAN

Configurazione di ldap

il server ldap legge le sue impostazioni dal file /etc/ldap/slapd.conf ed è quindi necessario apportarvi delle modifiche. Oltre alle solite impostazioni se ne devo aggiungere delle altre. Per aggiungere delle voci necessarie a kerberos nel database ldap è necessario includere lo schema krb5-kdc.schema (che potete recuperare su internet). Fare attenzione a decommentare alcune linee di questo file (perchè fossero commentate non lo so, ma senza decommentarle la creazione del database kerberos in ldap non era possibile, almeno per me). Alla fine di questo paragrafo trovate quello che uso io.

le linee riguardanti i certificati devono puntare ovviamente a dei certificati validi e creati in modo che come dn contengano esattamente il nome del server, nel mio caso zagor.valbruna.lan. Scriverò qualcosa su come creare i certificati? forse. Per il momento potete guardare qui creare i certificati

le due linee con saslRegexp servono a rimappare l'utente (uid=0+gid=0) che da kerberos, via ldapi (cioè localmente) si collega ad ldap (per scrivere e leggere i dati)

sasl_host zagor.valbruna.lan è il nome del server

sasl_realm VALBRUNA.LAN è il nome del Realm kerberos (in sostanza il nome del dominio)

password-hash {CLEARTEXT} il motivo è riportato appena sopra nello stesso file.

 
include     /etc/ldap/schema/core.schema
include     /etc/ldap/schema/cosine.schema
include     /etc/ldap/schema/inetorgperson.schema
include     /etc/ldap/schema/java.schema
include     /etc/ldap/schema/krb5-kdc.schema
include     /etc/ldap/schema/nis.schema
# Define global ACLs to disable default read access.
# Where the dynamically loaded modules are stored
modulepath   /usr/lib/ldap
moduleload   back_bdb
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral   ldap://root.openldap.org
pidfile     /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args
TLSCACertificateFile    /etc/ssl/certs/cacert.pem
TLSCertificateFile      /etc/ldap/ssl/ldapcert.pem
TLSCertificateKeyFile   /etc/ldap/ssl/ldapkey.key
# Misc options
# Maximum number of entries to return from a search operation. Useful
# to prevent trolling of directory by spammers, etc.
sizelimit   20
# Maximum size of the primary thread pool.
threads     8
# Allows acceptance of LDAPv2 bind requests (required for mozilla)
allow bind_v2
#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend bdb
checkpoint 512 30
#######################################################################
#######################################################################
# ldbm database definitions
#######################################################################
#
# Example Corporation database configuration
#
database    bdb
suffix      "dc=valbruna,dc=lan"
rootdn      "cn=manager,dc=valbruna,dc=lan"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# lo messa in  chiaro per semplicità nella prova....non lo farei in un  server in produzione
rootpw      segreto
saslRegexp
        "uidnumber=0\\\+gidnumber=.*,cn=peercred,cn=external,cn=auth"
   "cn=manager,dc=valbruna,dc=lan"
saslRegexp 
        "uidnumber=0\\\+gidnumber=.*,cn=peercred,cn=external,cn=auth"
        "krb5PrincipalName=kadmin/admin@VALBRUNA.LAN"
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory   /var/lib/ldap-esempio
# Indexes to maintain
index   default     eq,pres
index   objectClass             eq
index   cn,sn,givenname,mail    eq,pres,sub
index   uid,uidNumber,gidNumber
#index  memberUid,uniqueMember  -- This version of OpenLDAP does not support indexing of uniqueMember
index   memberUid
index   krb5PrincipalName,krb5PrincipalRealm
# SASL configuration
sasl_host   zagor.valbruna.lan
sasl_realm  VALBRUNA.LAN
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
    by self write
    by users read
    by anonymous auth
    by * none
# Clear text password, as we will be using {SASL}principal@REALM
password-hash {CLEARTEXT}

ora vediamo di configurare il file /etc/ldap/ldap.conf

BASE    dc=valbruna,dc=lan
URI     ldap://localhost
TLS_CACERTDIR   /etc/ssl/certs

Infine ecco il file krb5-kdc.schema che uso io

# $OpenLDAP: pkg/ldap/servers/slapd/schema/krb5-kdc.schema,v 1.1.2.1 2021/09/05 18:28:34 kurt Exp $
# $Id: hdb.schema,v 1.3 2022/02/22 21:51:53 lukeh Exp $
# Definitions for a Kerberos V KDC schema
# OID Base is iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) padl(5322) kdcSchema(10)
#
# Syntaxes are under 1.3.6.1.4.1.5322.10.0
# Attributes types are under 1.3.6.1.4.1.5322.10.1
# Object classes are under 1.3.6.1.4.1.5322.10.2
# Syntax definitions
#krb5KDCFlagsSyntax SYNTAX ::= {
#   WITH SYNTAX            INTEGER
#--        initial(0),             -- require as-req
#--        forwardable(1),         -- may issue forwardable
#--        proxiable(2),           -- may issue proxiable
#--        renewable(3),           -- may issue renewable
#--        postdate(4),            -- may issue postdatable
#--        server(5),              -- may be server
#--        client(6),              -- may be client
#--        invalid(7),             -- entry is invalid
#--        require-preauth(8),     -- must use preauth
#--        change-pw(9),           -- change password service
#--        require-hwauth(10),     -- must use hwauth
#--        ok-as-delegate(11),     -- as in TicketFlags
#--        user-to-user(12),       -- may use user-to-user auth
#--        immutable(13)           -- may not be deleted         
#   ID                     { 1.3.6.1.4.1.5322.10.0.1 }
#}
#krb5PrincipalNameSyntax SYNTAX ::= {
#   WITH SYNTAX            OCTET STRING
#-- String representations of distinguished names as per RFC1510
#   ID                     { 1.3.6.1.4.1.5322.10.0.2 }
#}
# Attribute type definitions
attributetype ( 1.3.6.1.4.1.5322.10.1.1
   NAME 'krb5PrincipalName'
   DESC 'The unparsed Kerberos principal name'
   EQUALITY caseExactIA5Match
   SINGLE-VALUE
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.5322.10.1.2
   NAME 'krb5KeyVersionNumber'
   EQUALITY integerMatch
   SINGLE-VALUE
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.3
   NAME 'krb5MaxLife'
   EQUALITY integerMatch
   SINGLE-VALUE
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.4
   NAME 'krb5MaxRenew'
   EQUALITY integerMatch
   SINGLE-VALUE
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.5
   NAME 'krb5KDCFlags'
   EQUALITY integerMatch
   SINGLE-VALUE
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
attributetype ( 1.3.6.1.4.1.5322.10.1.6
   NAME 'krb5EncryptionType'
   EQUALITY integerMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
###   ORDERING generalizedTimeOrderingMatch
attributetype ( 1.3.6.1.4.1.5322.10.1.7
   NAME 'krb5ValidStart'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.5322.10.1.8
   NAME 'krb5ValidEnd'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   SINGLE-VALUE )
attributetype ( 1.3.6.1.4.1.5322.10.1.9
   NAME 'krb5PasswordEnd'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
   SINGLE-VALUE )
# this is temporary; keys will eventually
# be child entries or compound attributes.
attributetype ( 1.3.6.1.4.1.5322.10.1.10
   NAME 'krb5Key'
   DESC 'Encoded ASN1 Key as an octet string'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
attributetype ( 1.3.6.1.4.1.5322.10.1.11
   NAME 'krb5PrincipalRealm'
   DESC 'Distinguished name of krb5Realm entry'
   SUP distinguishedName )
attributetype ( 1.3.6.1.4.1.5322.10.1.12
   NAME 'krb5RealmName'
   EQUALITY octetStringMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
# Object class definitions
objectclass ( 1.3.6.1.4.1.5322.10.2.1
   NAME 'krb5Principal'
   SUP top
   AUXILIARY
   MUST ( krb5PrincipalName )
   MAY ( cn $ krb5PrincipalRealm ) )
objectclass ( 1.3.6.1.4.1.5322.10.2.2
   NAME 'krb5KDCEntry'
   SUP krb5Principal
   AUXILIARY
   MUST ( krb5KeyVersionNumber )
   MAY ( krb5ValidStart $ krb5ValidEnd $ krb5PasswordEnd $
              krb5MaxLife $ krb5MaxRenew $ krb5KDCFlags $
              krb5EncryptionType $ krb5Key ) )
objectclass ( 1.3.6.1.4.1.5322.10.2.3
   NAME 'krb5Realm'
   SUP top
   AUXILIARY
   MUST ( krb5RealmName ) )

prima di lanciare /etc/init.d/slapd è necessario mettere questa opzione in /etc/default/slapd: OPTS="-h 'ldap:// ldaps:// ldapi://'"

e con questo la configurazione di ldap è fatta, si tratta ora di caricare alcuni dati. In particolare è da osservare la radice dn: ou=kerberos,dc=valbruna,dc=lan, dove verranno salvati i dati del database kerberos. Sperimentalmente si possono usare questi file ldiff:

per le voci principali:

# Organization
dn: dc=valbruna,dc=lan
objectClass: dcObject
objectClass: organization
dc: valbruna
description: The example corporation
o: Example Corporation Inc.
# Kerberos only principals (admin accounts, hosts,...)
dn: ou=kerberos,dc=valbruna,dc=lan
objectClass: organizationalUnit
objectClass: top
ou: kerberos
description: Kerberos only principals
# Groups
dn: ou=group,dc=valbruna,dc=lan
objectClass: organizationalUnit
objectClass: top
ou: group
description: Groups in example
# System related accounts
dn: ou=system,dc=valbruna,dc=lan
objectClass: organizationalUnit
objectClass: top
ou: system
description: System accounts
# People
dn: ou=people,dc=valbruna,dc=lan
objectClass: organizationalUnit
objectClass: top
ou: people
description: People in example

per i gruppi, molti dei quali, quasi tutti, inutili per una sperimentazione...ma non so ancora bene quali :-P

dn: cn=root,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: root
gidNumber: 0
dn: cn=sys,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: sys
gidNumber: 3
memberUid: adm
memberUid: bin
memberUid: root
dn: cn=adm,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: adm
gidNumber: 4
memberUid: daemon
memberUid: root
dn: cn=users,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: users
gidNumber: 100
memberUid: marco
dn: cn=nogroup,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: nogroup
gidNumber: 65533
dn: cn=nobody,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: nobody
gidNumber: 65534
dn: cn=ldap,ou=group,dc=valbruna,dc=lan
objectClass: posixGroup
objectClass: top
cn: ldap
gidNumber: 1002

almeno l'utente pippo vorremo mettercelo

dn: cn=pippo,ou=people,dc=valbruna,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: top
objectClass: krb5Principal
objectClass: krb5KDCEntry
krb5PrincipalName: pippo@VALBRUNA.LAN
krb5KeyVersionNumber: 1
krb5MaxLife: 86400
krb5MaxRenew: 604800
krb5KDCFlags: 126
cn: pippo
givenName: pippo
mail: pippo@valbruna.lan
sn: er pippo
uid: pippodn: cn=pippo,ou=people,dc=valbruna,dc=lan
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: top
objectClass: krb5Principal
objectClass: krb5KDCEntry
krb5PrincipalName: pippo@VALBRUNA.LAN
krb5KeyVersionNumber: 1
krb5MaxLife: 86400
krb5MaxRenew: 604800
krb5KDCFlags: 126
cn: pippo
givenName: pippo
mail: pippo@valbruna.lan
sn: er pippo
uid: pippo
uidNumber: 500
gidNumber: 100
homeDirectory: /home/pippo
loginShell: /bin/bash
uidNumber: 500
gidNumber: 100
homeDirectory: /home/pippo
loginShell: /bin/bash

Configurazione di bind

Questa parte non l'ho ben capita, nel senso che non so perchè sia necessario usare anche il dns e non basti qualche voce in hosts, ma così fan tutti (o quasi). Parte da verificare con più attenzione.

il file di zona locale, come potete vedere contiene alcune voci riferite proprio a kerberos e al server ldap (che poi è sempre zagor.valbruna.lan):

le zone vanno aggiunte ovviamente al file principale

 
;
; File di zona per valbruna.lan
;
; File di zona completo
;
@   IN   SOA zagor.valbruna.lan. root.zagor.valbruna.lan. (
              199802151       ; numero di serie, data di oggi +
                              ; # di serie di oggi
              8H              ; refresh, secondi
              2H              ; retry, secondi
              1W              ; expire, secondi
              1D )            ; minimum, secondi
;
         NS      zagor             ; Indirizzo Inet del name server
         MX      10 mail     ; Mail Exchanger Primario
         MX      20 mail   ; Mail Exchanger Secondario
;
; nomi reali
localhost       A       127.0.0.1
gw              A       192.168.1.1
                HINFO   "Cisco" "IOS"
                TXT     "Il router"
zagor           A       192.168.1.2
                MX      10 mail
                MX      20 mail
                HINFO   "Athlon" "Linux 2.6"
kdc             CNAME   zagor.valbruna.lan.
ldap            CNAME   zagor.valbruna.lan.
www             CNAME   zagor.valbruna.lan.
_kerberos TXT "VALBRUNA.LAN"
kerberos        CNAME   zagor.valbruna.lan.
_kerberos-master._udp  SRV 0 0 88 zagor
_kerberos-adm._tcp  SRV 0 0 749 zagor
_kpasswd._udp  SRV 0 0 464 zagor
_kerberos._udp IN SRV 0 0 88 zagor
_ldap._tcp IN SRV 0 0 389 zagor 

ovviamente va creato anche il file "gemello" db.192.168.1

 
;
; File di zona per valbruna.lan
;
; File di zona completo
;
@   IN   SOA zagor.valbruna.lan. root.zagor.valbruna.lan. (
              199802151       ; numero di serie, data di oggi +
                              ; # di serie di oggi
              8H              ; refresh, secondi
              2H              ; retry, secondi
              1W              ; expire, secondi
              1D )            ; minimum, secondi
;
         NS      zagor        ; Indirizzo Inet del name server
1               PTR     gw.valbruna.lan.
2               PTR     zagor.valbruna.lan.
4               PTR     mail.valbruna.lan.

Le zone vanno inserite nel file principale o in uno incluso al principale:

// Add local zone definitions here.
zone "valbruna.lan" {
        notify no;
        type master;
        file "/etc/bind/valbruna.lan";
};
zone "1.168.192.in-addr.arpa" {
        notify no;
        type master;
        file "/etc/bind/db.192.168.1";
};

Configurazione di kerberos

prima di creare il database di kerberos è necessario preparare i files di configurazione: Qui la situazione è semplice e nello stesso tempo complicata: esistono almeno due file di configurazione, ora, seguendo la logica di ldap, mi sarei aspettato che uno fosse per configurare il server kerberos e uno per configurare le variabili da passare ai vari client kerberos. Invece vedo che il file /etc/heimdal-kdc/kdc.conf che pensavo fosse per il server è praticamente vuoto, mentre il file /etc/krb5.conf sembra servire sia per il server che per i client. Riassumendo: Il file /etc/heimdal-kdc/ kdc.conf dovrebbe essere già pronto, mentre è necessario intervenire sul file /etc/heimdal-kdc/kadmind.acl che serve per permettere l'accesso al server, mettendoci la seguente riga

kadmin/[email protected]

(in realtà se si opera solo in locale, non credo che il file kadmind.acl serva a qualcosa, poichè il demon kadmind non viene usato)

infine è da preparare il file /etc/krb5.conf, da osservare dbname = ldap:ou=kerberos,dc=valbruna,dc=lan, se avete letto attentamente avrete già capito che stiamo dicendo a kerberos di salvare lì i suoi dati. Ma, dopo aver creato il database, si dovrà mettere dbname = ldap:dc=valbruna,dc=lan per fare in modo che trovi anche gli utenti sotto ou=People,dc=valbruna,dc=lan

[appdefaults]
# se avete problemi ad ottenere i tickets abilitate questa voce
# se i problemi scompaiono vuol dire che passate un indirizzo sbagliato al  server da parte del client
# ad esempio, nel mio caso era dovuto al fatto che in host avevo messo anche la riga 127.0.0.1 zagor.valbruna.lan
   no-addresses = false
[libdefaults]
   default_realm = VALBRUNA.LAN
# 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
# The following encryption type specification will be used by MIT Kerberos
# if uncommented.  In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#   default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
#   default_tkt_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
#   permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
# The following libdefaults parameters are only for Heimdal Kerberos.
   v4_instance_resolve = false
   v4_name_convert = {
      host = {
         rcmd = host
         ftp = ftp
      }
      plain = {
         something = something-else
      }
   }
   fcc-mit-ticketflags = true
[realms]
   VALBRUNA.LAN = {
      kdc = zagor.valbruna.lan
      admin_server = zagor.valbruna.lan
   }
[domain_realm]
   .valbruna.lan = VALBRUNA.LAN
   valbruna.lan = VALBRUNA.LAN
[kdc]
database = {
realm = VALBRUNA.LAN
dbname = ldap:ou=kerberos,dc=valbruna,dc=lan
mkey_file = /var/lib/heimdal-kdc/m-key
}
[login]
   krb4_convert = true
   krb4_get_tickets = false

E' ora possibile creare il database kerberos con i seguenti comandi:

per creare la masterkey

> kstash

per inizializzare il dominio, lanciamo kadmin con l'opzione l (cioè operiamo in locale come root e quindi senza password):

>kadmin -l

kamdin> init VALBRUNA.LAN

ora cambiamo la password a kadmin/admin , un utente che viene creato di dafault e che potrà usare kadmin anche da remoto (se viene avviato il server kadmind, ma non dovrebbe servire :-? )

kadmin>cpw kadmin/admin

kadmin>quit

se tutto ha funzionato (a me mai al primo colpo ) lanciando il comando

>kinit kadmin/admin

dovremmo recuperare il ticket per kadmin (che possiamo vedere con il comando klist) e quindi dovremmo poterci connettere al database come kadmin/admin:

>kadmin
kadmin> list *

ritorniamo al file /etc/krb5.conf e cambiamo la linea:

dbname = ldap:ou=kerberos,dc=valbruna,dc=lan

in

dbname = ldap:dc=valbruna,dc=lan

server riavviare kerberos? /etc/init.d/heimda-kdc restart

proviamo a cambiare la password a pippo:

>kadmin -l

kdadmin>cpw pippo

se tutto funziona abbiamo praticamente finito, altrimenti attaccatevi ai file di log e debug per ldap e kerberos

Configurazione di pam e nss

Per quanto riguarda pam (che si occupa di verificare le credenziali) è necessario intervenire sui file /etc/pam.d/common-* aggiungendo dopo la prima riga:

in common-passwd: password sufficient pam_krb5.so use_authok

in common-auth: auth sufficient pam_krb5.so use_first_pass

in common-account: account sufficient pam_krb5.so

Per nss (che al login si occupa di recuperare informazioni quali uid,gid, home, shell etc.), non vi è niente di nuovo rispetto alla configurazione già usata per ldap, infatti nss interroga ldap e non si cura di kerberos. Quindi in /etc/nsswitch.conf:

passwd:        ldap compat 
group:         ldap compat  
shadow:       ldap compat 

mentre in /etc/libnss-ldap.conf:

nss_base_passwd   ou=People,dc=valbruna,dc=lan?one
nss_base_shadow   ou=People,dc=valbruna,dc=lan?one
nss_base_group      ou=Group,dc=valbruna,dc=lan?one

ora, riavviando il server nscd, potremo fare il login come utente pippo.

E con questo per adesso ho finito, adesso per alcune settimane devo dedicarmi a moodle, ma sarò di ritorno appena possibile. Intanto se qualche anima pia del gruppo ISI decide di fare delle prove sulla base di quello che ho scritto, è gradito il commento e l'eventuale correzione/integrazione. Un suggerimento: se tutto funziona, è il caso di fare qualche prova con servizi kerberizzati tipo telnet e, se funziona, provare con cose più interessanti per noi, tipo NFS kerberizzato. Una considerazione: avrete notato che il campo password che usiamo solitamente in ldap è lasciato vuoto, ora da alcuni documenti in rete si vede che ldap potrebbe controllare le password degli utenti collegandosi a kerberos (che poi la ricontrolla nel suo campo in ldap!) in questo modo tutta l'attuale configurazione windows+samba3+ldap rimarrebbe immutata, ma avremmo la possibilità di usare kerberos per i client linux (e quindi risolvere il problema di NFS vero massimo?)

Squid + kerberos

Il problema al momento insormontabile sta proprio qui. Purtroppo :-(( Comunque mi sembra di capire che senza Samba4 non ci siano speranze e comunque Samba4 dovrebbe includere un suo kerberos (basato su heimdal) e un suo ldap interno (basato su openldap) con la possibilità di funzionare comunque con un database ldap esterno e/o un kerberos esterno. intanto ecco un link che ci fa capire che anche mozilla può disporre di un metodo di autenticazione via kerberos (IE dovrebbe già farlo di default). Questo significa che queste pagine servono solo a imparare qualcosa di kerberos, ma bisognerà aspettare.

http://weblogs.mozillazine.org/darin/archives/006185.html[firefox 1]] Mi metterò a studiare.

Samba + kerberos

Hai voglia....mi sa che prima che sono pronto è già uscito samba4 (in fondo sarebbe meglio così)

-- Marco Vaninetti - 05 Feb 2022

LTSP con Ubuntu

L'idea è quella di riciclare le macchine vecchie (che cominciano ad abbondare) utilizzando LTSP (Linux Terminal Server Project) e Ubuntu/Kubuntu come distro desktop. Per il momento raccolgo un pò di doc....

• http://linubuntu.blogspot.com/2006/12/ltsp-42.html
• http://linubuntu.blogspot.com/2006/12/ltsp-muecow.html
• http://ulisse.wordpress.com/ltsp-su-dapper/

Vmware-server

Scopo

Prerequisiti

Installare il server linux (Ubuntu-server)

Installare Vmware-server

Le macchine virtuali

iTalc

Home page del sito: http://italc.sourceforge.net/home.php

-- WebMaster - 03 Apr 2022