Toevallig iemand die het voor elkaar heeft gekregen om het volgende volledig werkend te krijgen?
Openradius <-> openldap (TLS/SSL) <-> gssapi (sasl) <-> kerberos V
Het gaat dan voornamelijk om de interactie tussen kerberos V en openldap.
Openldap werkt perfect met TLS/SSL. Kerberos zelf werkt perfect. Als ik een ticket aanvraag in kerberos kan ik ook perfect zonder verdere authenticatie de ldap-server benaderen over TLS/SSL dmv gssapi. Ik kan inloggen op de machine via zowel de standaard auth via pam<->/etc/passwd,/etc/shadow alsook via pam<->kerberos. So far so good dus
In de ldap dir heb ik gespecificeerd dat UserPassword van het People object opgehaald moet worden via kerberos als de user een simple bind met de ldap server wil doen. (Een simple bind is natuurlijk een security risico als dat over een niet SSL/TLS lijn zou gebeuren richting kerberos, maar dat kan normaliter niet bij mij, omdat ldap alleen over TLS/SSL te benaderen is. Om nu te debuggen laat ik TLS/SSL echter even uitstaan).
Het ophalen via kerberos heb ik gedaan door bij het userpassword veld de volgende notatie te gebruiken: {KERBEROS}<principal_name>@<KERBEROS.REALM> , waarbij de velden tussen < > uiteraard aangepast zijn aan mijn situatie. Hetgeen dus ook perfect werkt als ik met diezelfde info kerberos direct benader. Dit zou er zorg voor moeten dragen dat het password via kerberos geleverd wordt.
Alles wat ik probeer mislukt. Ik krijg continu de melding dat ik invalid credentials (49) gebruik, wat er dus op duidt dat het wachtwoord of verkeerd is of dat er iets mis gaat bij de controle. Verder haal ik niet veel vreemds uit de output op het scherm (ldap draait op de voorgrond met volledige debug output).
Nu kan ik wel op gaan geven, maar ik ben aardig close
Misschien iemand die ervaring heeft met de combinatie openldap<->gssapi<->kerberos en die wat mogelijke invalshoeken kan bieden of wat links voor me heeft?
Ik ben nu zo gaar dat ik niet meer weet waar ik het moet zoeken geloof ik
Ik heb het idee dat de ldap-server geen enkel contact wil maken met kerberos voor het password. Probleem is alleen dat kerberos niet echt fatsoenlijk te debuggen is.
Doel van dit hele project is het beveiligen van mijn netwerk, waar onlangs een Wireless netwerk aangekoppeld is. Binnenkort zal dat netwerk een bereik hebben van een goede 500 meter. Je kan je dus voorstellen dat ik veiligheid nu een nog groter issue vind dan voorheen, omdat ik toen alleen te maken had met een netwerk waarvan de gebruikers volledig te vertrouwen waren. De standaard technieken voor draadloze netwerken WEP/MAC-filtering en SID-verbergen zijn natuurlijk erg makkelijk te kraken op een netwerk dat 24/7 aan staat en een aardig bereik heeft
Het idee is dus om het draadloze verkeer via een VPN met de radius-server te laten communiceren. Die radius-server heeft een hele zooi regels die bepaalde acties zullen toestaan of juist niet. Zo zullen mensen die op het systeem bekend zijn en toegang mogen hebben tot het wireless netwerk veel rechten krijgen en zo het hele netwerk kunnen gebruiken, terwijl een gast niks kan doen, voordat deze ingelogd heeft onder het gast-account op een webpagina (die automatisch voorgeschoteld wordt wanneer de gast een webpagina opent.). Uiteraard kan deze gast niet heel veel meer dan de DNS-server benaderen en wat web-surfen (voor een bepaalde maximale tijd).
De radius server gebruikt de ldap-server voor z'n info (net zoals een aantal andere services de ldap-server zullen gaan gebruiken). De ldap-server gebruikt op zijn beurt weer gssapi (sasl die alleen kerberos V authenticatie toestaat) om de kerberos V server te benaderen.
Uiteraard zou de ldap-server een veel eenvoudiger mechanisme kunnen gebruiken voor authenticatie (wat ik voorheen dan ook gedaan heb), maar ten eerste ben ik nogal security freak, ten tweede is het gewoon leuk om met dit soort dingen te experimenteren en ten derde ben ik al zo ver qua interactie tussen de componenten dat ik nu never nooit niet op wil geven 
ldap-server output bij verificatie:
ldapquery: ldapsearch -d -1 -x -D 'uid=niels,ou=People,cn=nklomp,cn=com' -W -b "" -s base -LLL -H ldap://ldap1.nklomp.com/ supportedSASLMechanisms
Rootdn: uid=niels,ou=People,cn=nklomp,cn=com
passwd: blaat
Wat extra info erbij:
• Systeem: Debian: een mixje van stable en testing met een zooi eigen compilaties
• Kernel: 2.4.21-openmosix met migshm patch voor migratie van shared memory
• Openldap2: 2.1.22
• Cyrus sasl2: 2.1.15
• MIT kerberos V: 1.3
• srv-records in DNS-config voor kerberos en ldap
• ldap/host principles aangemaakt in kerberos en staan in keytab
Openradius <-> openldap (TLS/SSL) <-> gssapi (sasl) <-> kerberos V
Het gaat dan voornamelijk om de interactie tussen kerberos V en openldap.
Openldap werkt perfect met TLS/SSL. Kerberos zelf werkt perfect. Als ik een ticket aanvraag in kerberos kan ik ook perfect zonder verdere authenticatie de ldap-server benaderen over TLS/SSL dmv gssapi. Ik kan inloggen op de machine via zowel de standaard auth via pam<->/etc/passwd,/etc/shadow alsook via pam<->kerberos. So far so good dus
In de ldap dir heb ik gespecificeerd dat UserPassword van het People object opgehaald moet worden via kerberos als de user een simple bind met de ldap server wil doen. (Een simple bind is natuurlijk een security risico als dat over een niet SSL/TLS lijn zou gebeuren richting kerberos, maar dat kan normaliter niet bij mij, omdat ldap alleen over TLS/SSL te benaderen is. Om nu te debuggen laat ik TLS/SSL echter even uitstaan).
Het ophalen via kerberos heb ik gedaan door bij het userpassword veld de volgende notatie te gebruiken: {KERBEROS}<principal_name>@<KERBEROS.REALM> , waarbij de velden tussen < > uiteraard aangepast zijn aan mijn situatie. Hetgeen dus ook perfect werkt als ik met diezelfde info kerberos direct benader. Dit zou er zorg voor moeten dragen dat het password via kerberos geleverd wordt.
Alles wat ik probeer mislukt. Ik krijg continu de melding dat ik invalid credentials (49) gebruik, wat er dus op duidt dat het wachtwoord of verkeerd is of dat er iets mis gaat bij de controle. Verder haal ik niet veel vreemds uit de output op het scherm (ldap draait op de voorgrond met volledige debug output).
Nu kan ik wel op gaan geven, maar ik ben aardig close
Misschien iemand die ervaring heeft met de combinatie openldap<->gssapi<->kerberos en die wat mogelijke invalshoeken kan bieden of wat links voor me heeft?
Ik ben nu zo gaar dat ik niet meer weet waar ik het moet zoeken geloof ik
Ik heb het idee dat de ldap-server geen enkel contact wil maken met kerberos voor het password. Probleem is alleen dat kerberos niet echt fatsoenlijk te debuggen is.
Doel van dit hele project is het beveiligen van mijn netwerk, waar onlangs een Wireless netwerk aangekoppeld is. Binnenkort zal dat netwerk een bereik hebben van een goede 500 meter. Je kan je dus voorstellen dat ik veiligheid nu een nog groter issue vind dan voorheen, omdat ik toen alleen te maken had met een netwerk waarvan de gebruikers volledig te vertrouwen waren. De standaard technieken voor draadloze netwerken WEP/MAC-filtering en SID-verbergen zijn natuurlijk erg makkelijk te kraken op een netwerk dat 24/7 aan staat en een aardig bereik heeft
Het idee is dus om het draadloze verkeer via een VPN met de radius-server te laten communiceren. Die radius-server heeft een hele zooi regels die bepaalde acties zullen toestaan of juist niet. Zo zullen mensen die op het systeem bekend zijn en toegang mogen hebben tot het wireless netwerk veel rechten krijgen en zo het hele netwerk kunnen gebruiken, terwijl een gast niks kan doen, voordat deze ingelogd heeft onder het gast-account op een webpagina (die automatisch voorgeschoteld wordt wanneer de gast een webpagina opent.). Uiteraard kan deze gast niet heel veel meer dan de DNS-server benaderen en wat web-surfen (voor een bepaalde maximale tijd).
De radius server gebruikt de ldap-server voor z'n info (net zoals een aantal andere services de ldap-server zullen gaan gebruiken). De ldap-server gebruikt op zijn beurt weer gssapi (sasl die alleen kerberos V authenticatie toestaat) om de kerberos V server te benaderen.
Uiteraard zou de ldap-server een veel eenvoudiger mechanisme kunnen gebruiken voor authenticatie (wat ik voorheen dan ook gedaan heb), maar ten eerste ben ik nogal security freak, ten tweede is het gewoon leuk om met dit soort dingen te experimenteren en ten derde ben ik al zo ver qua interactie tussen de componenten dat ik nu never nooit niet op wil geven
ldap-server output bij verificatie:
ldapquery: ldapsearch -d -1 -x -D 'uid=niels,ou=People,cn=nklomp,cn=com' -W -b "" -s base -LLL -H ldap://ldap1.nklomp.com/ supportedSASLMechanisms
Rootdn: uid=niels,ou=People,cn=nklomp,cn=com
passwd: blaat
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
| str2filter "(objectclass=*)"
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
begin get_filter
PRESENT
ber_scanf fmt (m) ber:
ber_dump: buf=0x08128790 ptr=0x08128790 end=0x0812879d len=13
0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 ..objectclass
end get_filter 0
conn=0 fd=12 ACCEPT from IP=192.168.100.13:35220 (IP=192.168.100.13:389)
daemon: added 12r
daemon: activity on:
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 12r
daemon: read activity on 12
connection_get(12)
connection_get(12): got connid=0
connection_read(12): checking for input on id=0
ber_get_next
ldap_read: want=9, got=9
0000: 30 35 02 01 01 60 30 02 01 05...`0..
ldap_read: want=46, got=46
0000: 03 04 24 75 69 64 3d 6e 69 65 6c 73 2c 6f 75 3d ..$uid=niels,ou=
0010: 50 65 6f 70 6c 65 2c 63 6e 3d 6e 6b 6c 6f 6d 70 People,cn=nklomp
0020: 2c 63 6e 3d 63 6f 6d 80 05 62 6c 61 61 74 ,cn=com..blaat
ber_get_next: tag 0x30 len 53 contents:
ber_dump: buf=0x081292c0 ptr=0x081292c0 end=0x081292f5 len=53
0000: 02 01 01 60 30 02 01 03 04 24 75 69 64 3d 6e 69 ...`0....$uid=ni
0010: 65 6c 73 2c 6f 75 3d 50 65 6f 70 6c 65 2c 63 6e els,ou=People,cn
0020: 3d 6e 6b 6c 6f 6d 70 2c 63 6e 3d 63 6f 6d 80 05 =nklomp,cn=com..
0030: 62 6c 61 61 74 blaat
do_bind
ber_get_next
ldap_read: want=9 error=Resource temporarily unavailable
ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
ber_scanf fmt ({imt) ber:
ber_dump: buf=0x081292c0 ptr=0x081292c3 end=0x081292f5 len=50
0000: 60 30 02 01 03 04 24 75 69 64 3d 6e 69 65 6c 73 `0....$uid=niels
0010: 2c 6f 75 3d 50 65 6f 70 6c 65 2c 63 6e 3d 6e 6b ,ou=People,cn=nk
0020: 6c 6f 6d 70 2c 63 6e 3d 63 6f 6d 80 05 62 6c 61 lomp,cn=com..bla
0030: 61 74 at
ber_scanf fmt (m}) ber:
ber_dump: buf=0x081292c0 ptr=0x081292ee end=0x081292f5 len=7
0000: 00 05 62 6c 61 61 74 ..blaat
>>> dnPrettyNormal: <uid=niels,ou=People,cn=nklomp,cn=com>
=> ldap_bv2dn(uid=niels,ou=People,cn=nklomp,cn=com,0)
<= ldap_bv2dn(uid=niels,ou=People,cn=nklomp,cn=com,0)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=niels,ou=People,cn=nklomp,cn=com,272)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=niels,ou=people,cn=nklomp,cn=com,272)=0
<<< dnPrettyNormal: <uid=niels,ou=People,cn=nklomp,cn=com>, \
<uid=niels,ou=people,cn=nklomp,cn=com>
do_bind: version=3 dn="uid=niels,ou=People,cn=nklomp,cn=com" method=128
conn=0 op=0 BIND dn="uid=niels,ou=People,cn=nklomp,cn=com" method=128
send_ldap_result: conn=0 op=0 p=3
send_ldap_result: err=49 matched="" text=""
send_ldap_response: msgid=1 tag=97 err=49
ber_flush: 14 bytes to sd 12
0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1....
ldap_write: want=14, written=14
0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1....
conn=0 op=0 RESULT tag=97 err=49 text=
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 12r
daemon: read activity on 12
connection_get(12)
connection_get(12): got connid=0
connection_read(12): checking for input on id=0
ber_get_next
ldap_read: want=9, got=0
ber_get_next on fd 12 failed errno=0 (Success)
connection_read(12): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=12 for close
connection_close: conn=0 sd=12
daemon: removing 12 |
Wat extra info erbij:
• Systeem: Debian: een mixje van stable en testing met een zooi eigen compilaties
• Kernel: 2.4.21-openmosix met migshm patch voor migratie van shared memory
• Openldap2: 2.1.22
• Cyrus sasl2: 2.1.15
• MIT kerberos V: 1.3
• srv-records in DNS-config voor kerberos en ldap
• ldap/host principles aangemaakt in kerberos en staan in keytab
offtopic:
Woei, eerste techtopic van Nelske
Woei, eerste techtopic van Nelske
[ Voor 10% gewijzigd door Verwijderd op 27-08-2003 18:37 ]
:strip_icc():strip_exif()/u/29534/moto-icon.jpg?f=community){kind=icon}
