- g00se.org uses Kerberos for authentification.
- Kerberos offers Single-Sign-On.
Showing posts with label Kerberos. Show all posts
Showing posts with label Kerberos. Show all posts
Tuesday, January 1, 2008
OpenSSH using Kerberos via GSSAPI
I missed to activate a small and tiny feature during the update to Debian Etch: OpenSSH with GSSAPI support. What does sat mean?
Cyrus and Exim4 authentification using Kerberos via GSSAPI
Today I used my spare time to let the SMTP and the IMAP server of g00se.org using the GSSAPI for authentification.
The necessary cyrus-sasl libaries were already installed. So I really don't know which are exactly required. I suppose the cyrus-sasl gssapi libary should meet all requirements. I needed to install the exi4-daemon-heavy instead of the light one. The the heavy one does support authentification using the cyrus-sasl libary.
I created the principals imap/g00se.org and smtp/g00se.org and put them into the default keytab.
And modified the configuration files of both services to let them propose GSSAPI as alternate authentification mechanism:
(cyrus): imapd.conf:
sasl_mech_list: PLAIN GSSAPI
and
(exim4): [/etc/exim4/conf.d/auth/01_exim4-config_gssapi]
gssapi_server:
driver = cyrus_sasl
public_name = GSSAPI
server_mech = gssapi
server_hostname = g00se.org
#server_realm = G00SE.ORG
server_set_id = $auth1
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
Thanks to Sean for a short and easy description.
PS: Exim4 does use the splitted configuration file option of Debian. So you can put the lines anywhere into the authentification section.
The necessary cyrus-sasl libaries were already installed. So I really don't know which are exactly required. I suppose the cyrus-sasl gssapi libary should meet all requirements. I needed to install the exi4-daemon-heavy instead of the light one. The the heavy one does support authentification using the cyrus-sasl libary.
I created the principals imap/g00se.org and smtp/g00se.org and put them into the default keytab.
And modified the configuration files of both services to let them propose GSSAPI as alternate authentification mechanism:
(cyrus): imapd.conf:
sasl_mech_list: PLAIN GSSAPI
and
(exim4): [/etc/exim4/conf.d/auth/01_exim4-config_gssapi]
gssapi_server:
driver = cyrus_sasl
public_name = GSSAPI
server_mech = gssapi
server_hostname = g00se.org
#server_realm = G00SE.ORG
server_set_id = $auth1
.ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
.endif
Thanks to Sean for a short and easy description.
PS: Exim4 does use the splitted configuration file option of Debian. So you can put the lines anywhere into the authentification section.
Apache with Kerberos authentification
Special thanks to the guys who invented mod_auth_kerb. I removed the PAM authentification modules, which I only used as wrapper to get Kerberos auth through PAM and replaced it with mod_auth_kerb.
Here is the small configuration:
Krb5Keytab /etc/apache2/krb5.keytab
KrbAuthRealms G00SE.ORG
KrbServiceName HTTP
<Directory /x>
AuthType Kerberos
Require valid-user
</Directory>
That's all! Cool.
The Firefox bundled into my OpenSUSE 10.3 does already contain all necessary configurations. I only needed to add g00se.org to network.negotiate-auth.trusted-uris in about:config. So he does accept the offer to do GSSAPI authentification with these URIS. And that's pretty cool. At least I need to figure a way to get my M$ system use such cool stuff.
Here is the small configuration:
Krb5Keytab /etc/apache2/krb5.keytab
KrbAuthRealms G00SE.ORG
KrbServiceName HTTP
<Directory /x>
AuthType Kerberos
Require valid-user
</Directory>
That's all! Cool.
The Firefox bundled into my OpenSUSE 10.3 does already contain all necessary configurations. I only needed to add g00se.org to network.negotiate-auth.trusted-uris in about:config. So he does accept the offer to do GSSAPI authentification with these URIS. And that's pretty cool. At least I need to figure a way to get my M$ system use such cool stuff.
Sunday, December 2, 2007
Exim4 and Saslauthd [service=]
Hello! Since I upgraded g00se.org from Debian Sarge to Etch the authentification mechanism of my exim mail server doesn't run properly. I used as I descriped early the saslauthd to authentificate against the pam. Everything went fine. I believed, but a few weeks later (I used all the time my webinterface to send mails.) the exim couldn't use the same credentials as the imap server. The saslauthd always claimed that my credentials are false and so exim awnsered with a SMTP Error 535: Authentification failure. Tonight I managed to look into the problem and it's source. I checked the saslauthd using testsaslauthd. If I used: testsaslauthd -s smtp -u XXX - p XXX everything went fine and the saslauthd replied with credentials ok. But if I issued testsaslauthd -s "" -u XXX - p XXX I got a pam authentification error. I tried the same using exim and same behavior appeared, exim doesn't set the name of the service and so all authentification will fail. The problem is that the saslauthd will try to authenticate against a pam configuration which is not available.
Note: I have in /etc/pam.d/ a file called smtp which defines the pam behavior for my smtp service ;). The messages (/var/log/auth.log): Dec 3 00:55:50 h1206589 saslauthd[22244]: do_auth : auth failure: [user=XXX] [service=] [realm=] [mech=pam] [reason=PAM auth error] Dec 3 01:18:45 h1206589 saslauthd[22247]: do_auth : auth success: [user=XXX] [service=imap] [realm=] [mech=pam] As you can see the name of the service is in the first log empty. I found a solution you can tell the exim how to call the saslauthd (Snip of the authentification part of my exim service): plain_saslauthd_server: driver = plaintext public_name = PLAIN server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}} server_set_id = $auth2 server_prompts = : .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endif login_saslauthd_server: driver = plaintext public_name = LOGIN server_prompts = "Username:: : Password::" # don't send system passwords over unencrypted connections server_condition = ${if saslauthd{{$auth1}{$auth2}}{1}{0}} server_set_id = $auth1 .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endif Now tell exim that he have to use a service for saslauthd change: server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}} into server_condition = ${if saslauthd{{$auth2}{$auth3}{smtp}}{1}{0}}. smtp have to be the name of the pam configuration file. That's all. Everythings work as expected.
Sunday, February 11, 2007
Authentification Server via Kerberos (Heimdal) and LDAP backend
Today morning I configured heimdal KDC and as storage the openldap slapd. Slapd stores the user information and holds the kerberos authentification information. The public URI is ldaps://g00se.org. Kerberos realm: G00SE.ORG. KDC: g00se.org The openldap server uses TLS and authenfication and authorisation with the SASL GSSAPI (package (debian): libsasl2-modules-gssapi-heimdal). First I installed slapd (slapd and the above package). Added the krb5-kdc.schema. Configurated SASL support and added authorisation rules. With slapadd -f "backup.ldif" I installed my backup (without internal kerberos accounts). Modified /etc/default/slapd to let the slapd listen on ldaps:// and ldapi://. Reloaded the configuration. Second I installed the heimdal-kdc. Configured the realm. Configured database backend to use the ldapi:// socket. Reloaded. Init the realm and create necessary kerberos host accounts (with random keys): kadmin -l > init G00SE.ORG > add -r host/g00se.org > ext_keytab host/g00se.org > add -r ldap/g00se.org > ext_keytab ldap/g00se.org Reloaded everything and the authenfication server was up and running! Have a nice one!!
Authenfication client via Kerberos (Heimdal) and LDAP backend
To use the provided authenfication mechanism from g00se.org on g00se.org :D I installed libpam-heimdal and configured nss. Kerberos configuration: cat /etc/krb5.conf [libdefaults] default_realm = G00SE.ORG default_keytab_name = /etc/krb5.keytab ticket_lifetime = 28800 default_etypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 default_etypes_des = des3-hmac-sha1 des-cbc-crc des-cbc-md5 [realms] G00SE.ORG = { kdc = g00se.org admin_server = g00se.org } [domain_realm] g00se.org = G00SE.ORG .g00se.org = G00SE.ORG The pam configuration to use the heimdal KDC: cat /etc/pam.d/kerberos #@include common-auth #@include common-account auth required pam_krb5.so account required pam_krb5.so Configuration of the nss-ldap plugin: cat /etc/libnss-ldap.conf uri ldaps://g00se.org/ ldap_version 3 base dc=g00se,dc=org scope sub pam_filter objectclass=account pam_login_attribute uid pam_min_uid 1000 pam_max_uid 2000 nss_base_passwd ou=People,dc=g00se,dc=org?one nss_base_group ou=group,dc=g00se,dc=org?oneh Let nss know that there is a second source which provide authorisation data. cat /etc/nsswitch.conf passwd: compat ldap group: compat ldap That's all! As root you can now check if everything runs: getent passwd and you will see all your local accounts and the provided central ones! I hope everything is cool!!!
Subscribe to:
Posts (Atom)