Mark,
I went ahead, applied the patch and followed your guidance regarding
EXTRAAUTHENTICATORS=gss and built a binary using "make lrh
EXTRAAUTHENICATORS=gss". The problem is that I see no evidence of a
kerberos auth capability when I query the imap daemon. See the
following, I've included lots of ugly details:
[EMAIL PROTECTED] ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_50614_eyvUwR
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
09/27/06 16:01:56 09/28/06 02:01:56 krbtgt/[EMAIL PROTECTED]
renew until 09/28/06 02:01:57
Kerberos 4 ticket cache: /tmp/tkt50614
klist: You have no tickets cached
[EMAIL PROTECTED] ~]$ openssl s_client -connect localhost:993
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=Irvine/O=University of California
Irvine/OU=NACS/CN=imap.uci.edu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Irvine/O=University of California
Irvine/OU=NACS/CN=imap.uci.edu
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Irvine/O=University of California
Irvine/OU=NACS/CN=imap.uci.edu
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Irvine/O=University of California
Irvine/OU=NACS/CN=imap.uci.edu
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Premium Server
CA/[EMAIL PROTECTED]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfzCCAuigAwIBAgIQaR5slJ53VbEqKruW/bDmNjANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA2MDIwODAwMDAwMFoXDTA4MDIyNjIzNTk1OVow
gYMxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZJ
cnZpbmUxKDAmBgNVBAoTH1VuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYSBJcnZpbmUx
DTALBgNVBAsTBE5BQ1MxFTATBgNVBAMTDGltYXAudWNpLmVkdTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEArG96gcUKiIV630duT6ZZY/0tI3Oz6VFdDwtk7mCG
MYoB/IfLxfuA7LUY6kkzNvWzv23bs75fKYGN7t8cyj3dInWcpT9WY5ardXDVhCPl
5Ovv5DPUesPOX0q/OWgpz5XdjZJcka7BherYceLgJIyYwFNGYSfYTPnV18RJsFS2
QOkCAwEAAaOBpjCBozAMBgNVHRMBAf8EAjAAMEAGA1UdHwQ5MDcwNaAzoDGGL2h0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVTZXJ2ZXJQcmVtaXVtQ0EuY3JsMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAyBggrBgEFBQcBAQQmMCQwIgYI
KwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wDQYJKoZIhvcNAQEFBQAD
gYEAuvNzb63/maWYPnRtEL0hhrYcNt8aF00stW3ADfjxDM15Fdoy1IjjtcJOFg4F
d8z2O2Q7yNGojV6Q5vIhcNXr2Pv4dqQUsycOFk/bFCCTjUcedI51IbC/4/UBxJ2K
tAGsQVEPWxHCUO81w+0wZY+1QJWBblO8qXFvRcDSrbLNuZo=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Irvine/O=University of California
Irvine/OU=NACS/CN=imap.uci.edu
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Premium Server
CA/[EMAIL PROTECTED]
---
No client certificate CA names sent
---
SSL handshake has read 1061 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
FD69A398B66B993F4247FFE1124FC665590B4510698D7D41BDA63509563C197A
Session-ID-ctx:
Master-Key:
420A2889089B9A4838A04B1D1B244B4577C1C3E06F40D0372C95412100FE1F134F57B904C71B96399A4B7103680CBD0F
Key-Arg : None
Krb5 Principal: None
Start Time: 1159398147
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=PLAIN
AUTH=LOGIN] localhost.localdomain IMAP4rev1 2006a.369 at Wed, 27 Sep
2006 16:02:27 -0700 (PDT)
0 capability
* CAPABILITY IMAP4REV1 LITERAL+ IDLE UIDPLUS NAMESPACE MAILBOX-REFERRALS
BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT
MULTIAPPEND SASL-IR LOGIN-REFERRALS AUTH=PLAIN AUTH=LOGIN
0 OK CAPABILITY completed
Shouldn't I see AUTH=gssapi or something to that effect. I question this
because it doesn't seem to find my ticket even though I clearly have one
according to klist. Or maybe I'm doing this all wrong :-) Is this a
better way to test this?
thanks,
David
Mark Crispin wrote:
On Tue, 26 Sep 2006, David Severance wrote:
I was working getting 2006a running and ran into this compile time
problem:
osdep.c: In function `checkpw':
osdep.c:116: error: syntax error before '-' token
Thank you. Somehow, the imap-2006a/src/osdep/unix/ckp_gss.c file was
damaged. The following patch fixes it, and will be in imap-2006b:
*** ckp_gss.c~ 2006-08-30 18:34:07.000000000 -0700
--- ckp_gss.c 2006-09-26 13:45:41.000000000 -0700
***************
*** 59,65 ****
* to have separate client principals for different services,
but many
* other sites vehemently object...
*/
! !krb5_parse_name (ctx,kerb_cp_svr_name ? cltnam : pw->-pw_name,
&crd->client) &&
!krb5_parse_name (ctx,svrnam,&service) &&
!krb5_build_principal_ext (ctx,&crd->server,
--- 59,65 ----
* to have separate client principals for different services,
but many
* other sites vehemently object...
*/
! !krb5_parse_name (ctx,kerb_cp_svr_name ? cltnam : pw->pw_name,
&crd->client) &&
!krb5_parse_name (ctx,svrnam,&service) &&
!krb5_build_principal_ext (ctx,&crd->server,
I'm looking to get to an install that can hopefully use an already
granted kerberos ticket (from the original ssh login) and if there
isn't one (because it's a remote imapd only connection) use the pam
process to auth itself. Of course, maybe I'm going about this the
wrong way too.
That isn't what PASSWDTYPE=gss does.
PASSWDTYPE=gss says that, when validating a plaintext password, use
the user's Kerberos password rather than the password from /etc/passwd
(or PAM).
On most modern systems, passwords are validated with PAM, and if you
want to use the Kerberos password instead of the /etc/passwd password,
you would generally do this in a PAM configuration rather than build
imapd to look up the Kerberos password manually.
As for what you want to do, it should suffice to build the server with
EXTRAAUTHENTICATORS=gss. This will enable the GSSAPI SASL
authenticator, and if the client has a Kerberos ticket it can then use
GSSAPI SASL to authenticate to the server. [Of course, this assumes
that the client also supports GSSAPI.]
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
--
David Severance
Network and Academic Computing Services
(949) 824-7552
[EMAIL PROTECTED]
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
