ANNUNCIO: L'aggiornamento dei pacchetti ISI produce importanti cambiamenti,
leggete questa nota 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....
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