Re: [modauthkerb] mod_auth_kerb +aoache issue
There ought to be more information in the Apache error log. Also you can increase the log level if necessary. On Jul 3, 2008, at 9:16 PM, kul gupta wrote: Hello I am using mod_auth_kerb module( for apache webserver ) for authentication.I am facing the following issues(Issue (1) and Issue (2)) as described below- I also attaching the word document detailing the issues Apache server is in –Redhat Enterprise linux 5.0 KDC –in Redhat Enterprise linux 5.0 I have installed and configure Openssl0.9.8g apache 2.2.8 mod_auth_kerb 2.3 1)Apache with SSL is working fine and I am able to access https:\ \ruchita.com\index.html As per given in the INSATLL file of mod_auth_kerb we have done the settings of IE and mozilla as -- For Mozilla - I typed about:config in the URL bar and then set the value of network.negotiate-auth.trusted-uris to https://ruchita.com It then prompted me for username and password I entered my Kerberos username and password and enter Issue (1)-- After entering the details (username and password) it again prompted for the username and password. 2) For IE also i did the settings as given in n the INSATLL file of mod_auth_kerb I went to Local intranet Also edited the file- WINDOWS-system32-drivers-etc-host And added my linux machine(where the apache server is ) ip and its name in it. As 172.25.108.159 ruchita.com Issue (2) Now ,when I m trying to access http://ruchita.com, the output coming is Internal Server Error Also while accesing https://ruchita.com ,the output is Page cannot be displayed I will be highly thankful if someone can guide me for the same Thanks Kul mod_auth_kerb issues .doc - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ modauthkerb-help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/modauthkerb-help Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: mod_auth_kerb+ apacahe+mod_SSL
Questions relating to Apache and SSL have nothing to do with Kerberos. I think you would get much better help from a RedHat or Apache list. Once you get Apache+SSL working, I suggest you ask on [EMAIL PROTECTED] about any mod_auth_kerb issues. Is there a reason you're not using the Apache+SSL+mod_auth_kerb that already are provided by RedHat? This is still probably not your best forum, but I don't want to cut you off too short. On Jun 30, 2008, at 5:45 AM, kul gupta wrote: On 6/30/08, kul gupta [EMAIL PROTECTED] wrote: Hello I want to use the module mod_auth_kerb for the web authentication . Currently i m trying on RedHat enterprise linix 5.0 I have Openssl 0.9.8 g installed on it But when i m trying to install apachae with ssl (apache 2.2.8 ),i m getting some error. Without ssl apache is getting installed properly i did ./configure --enable-ssl --enable-mods-shared=all then make Now i m getting following errors /ab.c:382:undefined reference to`BIO_get_callback_arg' /ab.c:1144: undefined reference to`BIO_set_callback' /ab.c:1144: undefined reference to`BIO_set_callback' /ab.c:1145: undefined reference to`BIO_set_callback_arg' .libs/ab.o: In function `main': ab.c:2154: undefined reference to`SSL_CTX_set_info_callback' Please help me out in resloving this issue Thanks kul On 6/30/08, Henry B. Hotz [EMAIL PROTECTED] wrote: On Jun 29, 2008, at 9:15 AM, [EMAIL PROTECTED] wrote: Message: 1 Date: Sun, 29 Jun 2008 16:31:17 +0530 From: kul gupta [EMAIL PROTECTED] Subject: mod_auth_kerb+ apacahe+kerberos To: kerberos@mit.edu, [EMAIL PROTECTED], Russ Allbery [EMAIL PROTECTED], Tadoori (EXT), Vilas [EMAIL PROTECTED],Jeffrey Hutzelman [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hello I want to use the module auth_mod_kerb for the web authentication . Currently i m trying on RedHat enterprise linix 5.0 I have Openssl 0.9.8 g installed on it But when i m trying to install apachae with ssl ,i m getting some error. Without ssl apache is getting installed properly Is it necessary to have apache with ssl for working with auth_mod_kerb ?? If yes ,how can i proceed for the same I will highly appreciate if someone can help me on this issue. Thanks Regards KUL Not in the sense of just making the software work. It's a very good idea though. I'd say get ssl working first in a build with mod_so (dynamically loadable modules). Then add mod_auth_kerb afterwards. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Recommendations for Mixing Windows and non-Windows Domains?
If you run a Windows Domain and you also use BIND and MIT (or Heimdal) for DNS/Kerberos then you must have a strategy for preventing them from stepping on each other. Can I ask people for thumbnail's of how you-all do that? What raw services are handled by which servers? Are there magic settings on the clients that make it work? Significant services (which may need duplication or conflict resolution between Unix and AD): Forward DNS -- I suspect you serve separate DNS domains from BIND vice AD servers Reverse DNS -- Which platform gets which IP numbers, i.e. do you mix or segregate them? DHCP -- 1 or 2 DHCP services, provided by which? Does DHCP care about platform? DynDNS -- How is this integrated with DHCP (plus the above question). Kerberos -- krb5.conf or DNS SRV? Cross-realm -- Set up? Server-side referrals implemented (outside the DC that is)? Client configuration questions: advertised DNS servers -- BIND, DC, mix, pre-configured or DHCP supplied? cross-realm -- [domain_realm] section or DNS records maintained? I'm just listing the things that I can think of. Please tell me what I haven't thought of! If you want to reply privately, I will try to summarize to the list. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: GSSAPI Key Exchange Patch for OpenSSH 4.7p1
That does sound interesting. Count me in. On Sep 28, 2007, at 2:26 PM, Douglas E. Engert wrote: Sounds interesting. And yes, I would be interested in the cascading credentials delegation code. Does the delegation code depend on the key exchange code? What would it take to get both of these in to PuTTY? Simon Wilkinson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm pleased to (finally) announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for doing GSSAPI user authentication, this only allows the underlying security mechanism to authenticate the user to the server, and continues to use SSH host keys to authenticate the server to the user. For many sites who already have security infrastructures such as Kerberos deployed, managing large numbers of SSH host keys is an additional, unneccessary, burden. GSSAPI key exchange allows the use of security mechanisms such as Kerberos to authenticate the server to the user, removing the need for trusted ssh host keys, and allowing the use of a single security architecture. This patch adds support for the RFC4462 GSSAPI key exchange mechanisms to OpenSSH, along with adding some additional features to the GSSAPI code that is already in the tree. The patch implements: *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. (#1242) *) Support for the null host key type (#1242) *) Support for CCAPI credentials caches on Mac OS X (#1245) *) Support for better error handling when an authentication exchange fails due to server misconfiguration (#1244) *) Support for GSSAPI connections to hosts behind a round- robin load balancer (#1008) *) Support for GSSAPI connections to multi-homed hosts, where each interface has a unique name (#928) (bugzilla.mindrot.org bug numbers are in brackets) There are no code changes since the previous release. As usual, the code is available from http://www.sxw.org.uk/computing/patches/openssh.html I'm also interesting in hearing from people who might be interested in testing some new cascading credentials delegation code. When you renew your Kerberos credentials on the client, this code will automatically propagate these renewed credentials to the server, allowing the seamless renewal of credentials across ssh sessions distributed across many different machines. If you have an interest in testing this code in a non-production environment, please let me know! Cheers, Simon. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [modauthkerb] Saving credential with KrbSaveCredentials
On Aug 28, 2007, at 2:51 AM, Mikkel Kruse Johnsen wrote: Hi Rob The latest patch was a big mess and the way I made mod_auth_kerb use it's internal SPNEGO was not good. An options in configure should properbly be made (--enable-internal-spnego). But since the problem is not really with mod_auth_kerb but with MIT kerberos, I was hoping that someone on the kerberos list had responded. I am planing on filing a bug report on RHEL5 (it works on RHEL4 where it uses the internal SPNEGO). But have not done it yet. But feel free to send the patch upstream (I don't know what that involves). If upstream means MIT, then you send it to [EMAIL PROTECTED] Should include the output of krb5-config --version as a minimum. I suspect they have already fixed the bug, so the issue would be RedHat not keeping up with MIT. /Mikkel On Mon, 2007-08-27 at 11:55 -0400, Rob Crittenden wrote: Mikkel Kruse Johnsen wrote: Hi All I got it to work. It seems there is an error in the SPNEGO code on MIT Kerberos. When compiling mod_auth_kerb to use it's internal SPNEGO code everything works fine. This patch works for me as well. I simplified it significantly to just using the internal SPNEGO library, including the #ifndef GSSAPI_SUPPORTS_SPNEGO around cmp_gss_type() and including the acc_ret_flags option. Are you planning to submit this upstream? And finally, thanks for continuing to work on this until you figured it out! regards rob !DSPAM:46d2f40a216093430311512! Mikkel Kruse Johnsen Adm.Dir. Linet The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.
/mod_auth_kerb.c(1360):
[client 130.226.36.170] krb_save_credentials activated,
GSS_C_DELEG_FLAG available, referer: http://od.cbs.dk/phpinfo.php
[Fri Jul 27 09:09:50 2007] [error] [client 130.226.36.170] Cannot
store delegated credential (gss_krb5_copy_ccache: Invalid
credential was supplied (No error)), referer: http://od.cbs.dk/
phpinfo.php
/Mikkel
On Thu, 2007-07-26 at 22:38 +0200, Achim Grolms wrote:
On Thursday 26 July 2007 21:54, Douglas E. Engert wrote: Achim
Grolms wrote: On Thursday 26 July 2007 20:40, Henry B. Hotz
wrote: If I understand RFC2744 correct GSS_C_DELEG_FLAG
would not be set in that case? Achim
Agreed. That flag shouldn't be set AFAIK, though the value isn't
valid until negotiation is complete. That means before
trying to store delegated credentials and before checking
GSS_C_DELEG_FLAG mod_auth_kerb needs to check if
gss_accept_sec_context () returns major_status =
GSS_S_COMPLETE From my point of view this means that mod_auth_kerb
needs a change in code. I needs to be of that style: the
major_status of gss_accept_sec_context() needs to be checked
before checking GSS_C_DELEG_FLAG. This can be done this way: if
( major_status_accept = GSS_S_COMPLETE ) { if (conf-
krb_save_credentials) { if (delegated_cred !=
GSS_C_NO_CREDENTIAL) { . . . } } } major_status_accept is the
major_status returned by accept_sec_token Mikkel, can you give
this a try? Achim Received-SPF: pass (0: SPF record at
ispgateway.de designates 80.67.18.15 as permitted sender) !DSPAM:
46a9068820551136180008!
Mikkel Kruse Johnsen
Linet
Ørholmgade 6 st tv
2200 København N
Tlf: +45 2128 7793
email: [EMAIL PROTECTED]
www: http://www.linet.dk
mod_auth_kerb-5.3-deleg.patch
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.
On Jul 26, 2007, at 8:22 AM, Douglas E. Engert wrote: Attached is the Wireshark print output of the GET request showing the SPNEGO and GSSAPI In original trace, the client does request a ticket to delegate but it looks like it is not delegating it. It looks like it is: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5\r\n I Googled for: FireFox SPNEGO delegation and found among other articles: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp? topic=/com.ibm.websphere.express.doc/info/exp/ae/ tsec_SPNEGO_config_web.html Complete the following steps to ensure that your Firefox browser is enabled to perform SPNEGO authentication. At the desktop, log in to the windows active directory domain. Activate Firefox. At the address field, type about:config. In the Filter, type network.n Double click on network.negotiate-auth.trusted-uris. This preference lists the sites that are permitted to engage in SPNEGO Authentication with the browser. Enter a comma-delimited list of trusted domains or URLs. Note: You must set the value for network.negotiate-auth.trusted-uris. If the deployed SPNEGO solution is using the advanced Kerberos feature of Credential Delegation double click on network.negotiate- auth.delegation-uris. This preference lists the sites for which the browser may delegate user authorization to the server. Enter a comma-delimited list of trusted domains or URLs. Double check this one. The delegate flag is *not* set in the SPNEGO data in the auth request in the dump file you sent. Also there is no delegated ticket, just a service ticket. I don't know why the server thinks it's got a delegate flag when the client didn't send one. Click OK. The configuration appears as updated. Restart your Firefox browser to activate this configuration. Mikkel Kruse Johnsen wrote: Hi Douglas Im not sure what to look for, but here is the dump. If you are able to see anything. Done with wireshark. /Mikkel On Wed, 2007-07-25 at 09:36 -0500, Douglas E. Engert wrote: Looks like it should have worked. A wireshark trace of the packets would show a lot, as long as the session is not encrypted. It could be a size issue. AD can produce very large tickets if you are in many groups. It could be an enc-type issue, which the server does not understand It could be the client is not delegating. Wireshark could answer these. Mikkel Kruse Johnsen wrote: On Mon, 2007-07-23 at 16:27 -0500, Douglas E. Engert wrote: Mikkel Kruse Johnsen wrote: Hi Markus Yes that is what I want. I need the KRB5CCNAME (the credential) so I can login to my OpenLDAP SASL based server and PostgreSQL with kerberos. So what you need is the Kerberos credentials. I have an older version of mod_auth_kerb I assume your version has the routine store_gss_creds() which should be doing this for you and creating the name in the create_krb5_ccache(). and calling apr_table_setn(r-subprocess_env, KRB5CCNAME, ccname); Yes it does contain that function, I'm using mod_auth_kerb 5.3 Is KrbSaveCredentials being set in the conf file? Yes it is set. And I have set the: network.negotiate-auth.delegation-uris = cbs.dk,hhk.dk network.negotiate-auth.trusted-uris = cbs.dk,hhk.dk (Have tryied all kinds of combinations. This must be the right one. This controls the saving of credentials: if (conf-krb_save_credentials delegated_cred != GSS_C_NO_CREDENTIAL) store_gss_creds(...) Are the above routines being called. It seems that delegated_cred = GSS_C_NO_CREDENTIAL because the store_gss_creds is never called. Compiled the mod_auth_kerb with the attched and It is now called but I get in the log: [Wed Jul 25 11:53:27 2007] [debug] src/mod_auth_kerb.c(1358): [client 130.226.36.170] krb_save_credentials activated, GSS_C_DELEG_FLAG available, referer: http://od.cbs.dk/phpinfo.php [Wed Jul 25 11:53:27 2007] [error] [client 130.226.36.170] Cannot store delegated credential (gss_krb5_copy_ccache: Invalid credential was supplied (No error)), referer: http:// od.cbs.dk/phpinfo.php Is the client actually delegating a credential. So it seems that the credential is never delegated. Is the KRB5CCNAME being set in the environment of the subprocess. Don't know how to check this. The KRB5CCNAME is in the env. with the attached patch but the credetials is never saved to that file. /Mikkel /Mikkel On Mon, 2007-07-23 at 19:33 +0100, Markus Moeller wrote: Storing credentials in a krb5 cache pointing to KRB5CCNAME has nothing to do with delegation. You only need delegation if you wnat that Apache logs into a backend application with the users ID. Is that what you want ? If see you need to be very careful as iit gives yor apache server a lot of power if
Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.
Nothing wrong with what you suggest, but in theory the conf-
krb_save_credentials value doesn't need to be checked.
In practice, who knows? Lots of bugs out there.
On Jul 26, 2007, at 1:38 PM, Achim Grolms wrote:
On Thursday 26 July 2007 21:54, Douglas E. Engert wrote:
Achim Grolms wrote:
On Thursday 26 July 2007 20:40, Henry B. Hotz wrote:
If I understand RFC2744 correct GSS_C_DELEG_FLAG
would not be set in that case?
Achim
Agreed. That flag shouldn't be set AFAIK, though the value isn't
valid until negotiation is complete.
That means before trying to store delegated credentials
and before checking GSS_C_DELEG_FLAG
mod_auth_kerb needs to check if gss_accept_sec_context ()
returns major_status = GSS_S_COMPLETE
From my point of view this means that mod_auth_kerb
needs a change in code.
I needs to be of that style:
the major_status of
gss_accept_sec_context()
needs to be checked before checking GSS_C_DELEG_FLAG.
This can be done this way:
if ( major_status_accept = GSS_S_COMPLETE ) {
if (conf-krb_save_credentials) {
if (delegated_cred != GSS_C_NO_CREDENTIAL) {
.
.
.
}
}
}
major_status_accept is the major_status returned by
accept_sec_token
Mikkel, can you give this a try?
Achim
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [modauthkerb] Negotiate on Windows with cross-realm trust ADand MIT Kereros.
On Jul 25, 2007, at 2:55 AM, Mikkel Kruse Johnsen wrote: Is the KRB5CCNAME being set in the environment of the subprocess. Don't know how to check this. The KRB5CCNAME is in the env. with the attached patch but the credetials is never saved to that file. Protect CGI's and access a cgi that prints the environment. I think Apache comes with a couple: printenv (perl script), and test-cgi (sh script). I slightly customized the test-cgi as follows (for Solaris): - #!/bin/sh # disable filename globbing set -f echo Content-type: text/plain; charset=iso-8859-1 echo echo CGI/1.0 test script report: echo echo argc is $#. argv is $*. echo echo SERVER_SOFTWARE = $SERVER_SOFTWARE echo SERVER_NAME = $SERVER_NAME echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE echo SERVER_PROTOCOL = $SERVER_PROTOCOL echo SERVER_PORT = $SERVER_PORT echo REQUEST_METHOD = $REQUEST_METHOD echo HTTP_ACCEPT = $HTTP_ACCEPT echo PATH_INFO = $PATH_INFO echo PATH_TRANSLATED = $PATH_TRANSLATED echo SCRIPT_NAME = $SCRIPT_NAME echo QUERY_STRING = $QUERY_STRING echo REMOTE_HOST = $REMOTE_HOST echo REMOTE_ADDR = $REMOTE_ADDR echo REMOTE_USER = $REMOTE_USER echo AUTH_TYPE = $AUTH_TYPE echo KRB5CCNAME = $KRB5CCNAME echo CONTENT_TYPE = $CONTENT_TYPE echo CONTENT_LENGTH = $CONTENT_LENGTH echo echo Output from /usr/bin/klist: echo /usr/bin/klist -f 21 The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Different Heimdal/MIT behaviour of krb5_get_credentials ?
On Jun 1, 2007, at 12:00 PM, Markus Moeller wrote: Henry B. Hotz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On May 31, 2007, at 11:25 AM, Markus Moeller wrote: I have a AD forest with MM.COM with domains DOM1.MM.COM,DOM2.MM.COM and SUB.DOM2.MM.COM which all trust each other. To test the availability of service tickets I created the following short program: Any particular reason you didn't use kvno (MIT) and kgetcred (Heimdal)? Not really, only I am not sure if it will achieve what I want. My final goal is to determine easily for a user/application if a domain has trust to another. My thought was that the user does a kinit to his domain DOM1 (or an application kinit against a keytab) and then tries to get a krbtgt for the unknown domain DOM2. If he gets the tgt they have trust if not they don't. Does this make sense ? Sure it does. You could do that with the utilities I listed too, but writing your own code you've got more visibility into what's happening. I'm sure you realize it could fail for more reasons than just lack of a trust relationship also. I've found I can't get away from these little hip-picket test programs when I need to debug things. Name canonicalization and DNS (or NIS) interactions seem especially problematic in the real world for me. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Different Heimdal/MIT behaviour of krb5_get_credentials ?
On May 31, 2007, at 11:25 AM, Markus Moeller wrote: I have a AD forest with MM.COM with domains DOM1.MM.COM,DOM2.MM.COM and SUB.DOM2.MM.COM which all trust each other. To test the availability of service tickets I created the following short program: Any particular reason you didn't use kvno (MIT) and kgetcred (Heimdal)? To properly debug the problem you probably want to look at the kdc logs to see what actually got requested as compared to what's available. You can also get that info from a tcpdump/snoop, but it's not as easy. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Use of des-cbc-md4
Anybody know of *anything* out there that actually uses the des-cbc- md4 encryption type? IIRC there was something Microsoft-ish that did at one time, but I wonder if it still exists. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Migrating a Kerberos Realm
On Nov 2, 2006, at 9:03 AM, [EMAIL PROTECTED] wrote: Date: Wed, 1 Nov 2006 22:21:53 -0500 From: Ken Raeburn [EMAIL PROTECTED] Subject: Re: Migrating a Kerberos Realm To: John Hascall [EMAIL PROTECTED] Cc: kerberos@mit.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 1, 2006, at 22:04, John Hascall wrote: If anyone is thinking of going down this road, be aware that there are some crappy client implementations out there (* looks in the direction of WebCT Vista and coughs *) that don't handle a non-default salt correctly... And here I was, thinking it would be a good idea to pick random salt strings on password changes, to make certain attacks more costly Ken The other Ken says that part of the client code isn't well exercised. ;-) OTOH, it sounds like a fun idea to me. Do the cryptosystem RFC's specify the default salt? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
LDAP Schema Design Suggestions?
No, I'm not talking about using LDAP to store the back-end for a KDC. I'm wondering if there are any thoughts or wisdom related to RFC 2307 (or successors) about how to store meta-information about Kerberos principals. That RFC defines schema's for machines and things with IP numbers. I also need to associate an owner for non-people principals. Probably incomplete list of information needed for non-people principals: Owner (either a uid for a given search base, or else a real-person principal) Backup Owner (in case the primary vanishes) Renewal Date (so we can clean up, and maybe rotate keys) Maybe a reference to the machine entry, if it isn't part of the machine entry already. For a machine, maybe a list of service principals extant? Excuse the stream-of-consciousness presentation. Trying to put this in more formal requirements: A machine may have multiple IP numbers. An IP number may have multiple service principals. A service principal has (at least) an owner, backup owner, and renewal date. (Maybe some duplicated info from the Kerberos DB.) A service principal may be used to bind to LDAP (to get info about users). Are there any standard object classes (besides what's in 2307) that I might use? Any suggestions, comments? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: LDAP Schema Design Suggestions?
On Oct 24, 2006, at 7:35 PM, Nicolas Williams wrote: On Tue, Oct 24, 2006 at 06:19:04PM -0700, Henry B. Hotz wrote: No, I'm not talking about using LDAP to store the back-end for a KDC. I'm wondering if there are any thoughts or wisdom related to RFC 2307 (or successors) about how to store meta-information about Kerberos principals. That RFC defines schema's for machines and things with IP numbers. I also need to associate an owner for non-people principals. Users don't make good owners. They change job descriptions, go on extended vactions/sabatticals, leave, die, are laid off, are fired... IMO groups make much better owners. Nico -- Yeah, OK. I just don't have an organizationally meaningful alternative available. Other people on the list should take note though. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberized DBMS's Available
If I understand the Java world well enough that would be the basis for a type 1 JDBC driver. PG already has a type 4 (fully native) driver. I think that would be considered a valid, but undesirable solution. Thanks for the comment. On Oct 7, 2006, at 9:05 AM, [EMAIL PROTECTED] wrote: Date: Fri, 6 Oct 2006 02:14:04 +0200 From: Markus Schaaf [EMAIL PROTECTED] Subject: Re: Kerberized DBMS's Available To: kerberos@MIT.EDU Message-ID: [EMAIL PROTECTED] Henry B. Hotz [EMAIL PROTECTED] wrote: I'm looking for a DBMS that supports Kerberos for user authentication = and has a JDBC client. It appears that I may have to write the =20 support myself, unless someone can add something I haven't been able =20 to find out. PostgreSQL -- supports Kerberos directly with the MIT API. No SASL/=20 GSSAPI support so Kerberos support doesn't work with the JDBC client, = or on Windows (unless you build against KfW presumably). Kerberos authentication from a XP client (using cached AD credentials) to a Postgresql server running on NetBSD is working fine here. I use ODBC and psql only, so I can't comment on JDBC. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Kerberized DBMS's Available
I'm looking for a DBMS that supports Kerberos for user authentication and has a JDBC client. It appears that I may have to write the support myself, unless someone can add something I haven't been able to find out. The big three I know about are: MySQL -- market leader, but no Kerberos support. Also AFAIK no ability to use the identity from an SSH or SSL tunnel. SASL/GSSAPI patches probably acceptable if offered. PostgreSQL -- supports Kerberos directly with the MIT API. No SASL/ GSSAPI support so Kerberos support doesn't work with the JDBC client, or on Windows (unless you build against KfW presumably). GSSAPI patches probably acceptable if done cleanly. Oracle -- supports Kerberos directly using some pre-release MIT code independent of available any outside Kerberos libraries. Not sure if our site license allows export of the client, or if they have a Kerberos aware JDBC client. I expect not for at least one of those. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Remembering Master Password
On Sep 23, 2006, at 9:05 AM, [EMAIL PROTECTED] wrote: Date: Sat, 23 Sep 2006 08:42:51 CDT From: John Hascall [EMAIL PROTECTED] Subject: Re: Remembering Master Password To: Jason C. Wells [EMAIL PROTECTED] Cc: kerberos@mit.edu Message-ID: [EMAIL PROTECTED] In big bold letters we are warned to NOT FORGET the password to the database. For years I have kept my password faithfully documented and I have _never_ used it. Why do I need to remember my database master password? You have two options with your master password. One is to keep a copy on disk (what you seem to have done) and the other is to be prompted for it each time the KDC starts. In any event if you forget (and lose the file with) the master password your KDC DB is useless as it can not be decrypted to be used. Can I randomize the database master password similar to using - randkey on my service principals? I don't think I've seen a procedure documented to do that, if you really want to do that, I'd try it on a test realm first for sure! John Heimdal uses a standard keytab file for the master password. In Heimdal kadmin you can do: add -r M/K del_enc M/K all encryption types except the one you want ext_key -k master key stash location M/K delete M/K Heimdal also supports multiple master key versions in the keytab, and can re-encrypt the database with a new master key by doing hprop -- encrypt --stdout | hpropd --stdin. If someone wanted to add those features to MIT I'm sure they would like the contribution. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
MySQL and Kerberos
Anyone know how to use Kerberos with MySQL? I thought I once saw a kludge where you could use Kerberos with some kind of tunneling mechanism and make the server pick up the username from the tunnel. I can't seem to find any reference to that with Google now, though. Anyone actually considering adding code themselves? ;-) The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Remembering Master Password
On Sep 27, 2006, at 11:10 AM, Jeffrey Hutzelman wrote: On Wednesday, September 27, 2006 08:52:52 AM -0700 Henry B. Hotz [EMAIL PROTECTED] wrote: Heimdal uses a standard keytab file for the master password. In Heimdal kadmin you can do: add -r M/K del_enc M/K all encryption types except the one you want mod --kvno==desired next version # M/K ;-) ext_key -k master key stash location M/K delete M/K You can, but if you do that multiple times, you'll end up with multiple keys with the same kvno. Since Heimdal records for each record the version of the master key that was used to encrypt it (if any), it can handle multiple keys and do a gradual transition. But that won't work if you keep reusing the same version. Also, that's rather convoluted compared to ktutil add -r -p M/K So it is. You can't delete it from the master DB afterwards with ktutil, but I guess you're advocating just leaving it there so you don't have to track the version number yourself? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MySQL and Kerberos
Does the MySQL server have any provision for external identification of users at all? Beyond this point maybe the question belongs on a MySQL list. Thanks for answering though. On Sep 27, 2006, at 11:13 AM, Evan Vittitow wrote: The best idea I could come up with was to Kerberize PHPMyAdmin. At one time I wanted to add Kerberos support to eGroupware, PHPGroupware, PHPldapadmin, and PHPMyAdmin The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Remembering Master Password
On Sep 27, 2006, at 1:38 PM, Jeffrey Hutzelman wrote: On Wednesday, September 27, 2006 01:26:22 PM -0700 Henry B. Hotz [EMAIL PROTECTED] wrote: On Sep 27, 2006, at 11:10 AM, Jeffrey Hutzelman wrote: On Wednesday, September 27, 2006 08:52:52 AM -0700 Henry B. Hotz [EMAIL PROTECTED] wrote: Heimdal uses a standard keytab file for the master password. In Heimdal kadmin you can do: add -r M/K del_enc M/K all encryption types except the one you want mod --kvno==desired next version # M/K ;-) ext_key -k master key stash location M/K delete M/K You can, but if you do that multiple times, you'll end up with multiple keys with the same kvno. Since Heimdal records for each record the version of the master key that was used to encrypt it (if any), it can handle multiple keys and do a gradual transition. But that won't work if you keep reusing the same version. Also, that's rather convoluted compared to ktutil add -r -p M/K So it is. You can't delete it from the master DB afterwards with ktutil, but I guess you're advocating just leaving it there so you don't have to track the version number yourself? 'ktutil add' doesn't talk to the server at all; it only manipulates the keytab. So, the entry never gets added to the database. I stand corrected. change or get interact with kadmind. I'm assuming from your omission that add will look at the existing kvno's and create the next one? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Remembering Master Password
On Sep 27, 2006, at 2:00 PM, Jeffrey Hutzelman wrote: On Wednesday, September 27, 2006 01:54:30 PM -0700 Henry B. Hotz [EMAIL PROTECTED] wrote: I'm assuming from your omission that add will look at the existing kvno's and create the next one? Well, the man page claims it will prompt for anything you don't specify; I'm not sure I believe that wrt enctypes, but I bet it's true for the kvno. So yes, you'd have to list the existing keytab and pick a new kvno. -- Jeff Just tried it. (I happen to be setting up a new dev realm.) It will prompt for enctype and kvno. I don't think I explicitly told it what realm it was, but I did give it the file and principal of course. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Debugging connections through load balancers.
I've got a kerberized service that worked fine before I started trying to use it through a load balancer. (I'm saying that for background, not because I didn't think it should matter.) So the current situation is that I've changed /etc/hosts and /etc/ nodename to contain the FQDN of the balancer. The server *thinks* its name is the balancer's name. A connection to the balancer does get to the real server. The server's keytab has entries for both its real name and the balancer's name. Doesn't work. (Interestingly a direct connection that bypasses the balancer still works; I wouldn't have expected that.) So how do I go about debugging something like this? My next step would be to snoop the connection and feed it to ethereal, probably with lots of keys available so it can decode everything. Is there anything better to try? Is there any way to get the kerberos libs to say what (if anything) they are trying to get out of the keytab? If it matters, the service is Sun LDAP 5.2 on Solaris 9. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC
On May 16, 2006, at 2:32 PM, [EMAIL PROTECTED] wrote: Message: 9 Date: Tue, 16 May 2006 17:32:45 -0400 From: Jeff Blaine [EMAIL PROTECTED] Subject: Re: Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC To: kerberos@mit.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Nicolas Williams wrote: On Tue, May 16, 2006 at 04:01:11PM -0400, Jeff Blaine wrote: I'm confused, then, Nicolas. As I read the output, there are 2 keys stored for these principals: 1 using Triple DES cbc mode with HMAC/sha1 1 using DES cbc mode with CRC-32 And the first matching enctype is supposed to be used, which would be des-cbc-crc (and des3-hmac-sha1 would not, as it is not common to the client and server. What does kadmin -q getprinc host/[EMAIL PROTECTED] say? I bet the des3-hmac-sha1 key comes before the des-cbc-crc key. Yes, it does. I think there is an FAQ on this: best to make sure the service principals only have key types that are understood by the service's Kerb libraries. On Heimdal you would normally create the entry and then delete the unwanted encryption key types (if necessary). I think the mechanism is different for Sun or MIT servers: you specify the enc type you want as part of the add? I wouldn't prohibit des3 across the board just because you have some Sun machines that haven't been upgraded to Solaris 10. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Oracle Kerberos Implementation Info Needed
The Oracle Kerberos implementation appears to be different from the Solaris implementation it sits on top of. There isn't much info on the core differences in the Oracle documentation I've seen and we haven't gotten much out of our support contract, at least yet. What I've seen is the okinit program (on Solaris 10) seems to support the full range of encryption types when just given a username. This works. However when you give it a keytab (as in okinit -k -t file user) it acts very differently. Generally says the enctype is unsupported. Sometimes the mismatch is due to not having the right enctype in the keytab. Sometimes it's there but the request is restricted to single-DES. I think I've gotten okinit to work with des3, but certainly the dbms clients don't request the right tickets. I'm sorry I don't remember all the details of what didn't work, but does anyone have any information on what might be needed to set up Kerberos support for an Oracle database. The Oracle doc's seem pretty incomplete. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT + Heimdal + openssh == cross realm difficulties
On Feb 9, 2005, at 12:53 AM, Priit Randla wrote: Henry B. Hotz wrote: It's not clear to me why the MIT and Heimdal realms need to be different. The reason is quite embarassing, actually - total re-branding. Total renamification :-) from AAA to BBB. Lotsa host/* principals to recreate and change. And 24/7/365 as usual. So I have to simply accept that those two realms have to exist and work together for some unspecified time. You can import an MIT database into Heimdal with hprop. Google for the details, but you export a MIT dump file with some specific options and then use hprop to read it into Heimdal. Dit it. Unfortunately, all password policies will get lost in the process. Which reminds me that I didn't see a way to create and use policies under Heimdal... Major PIA if these aren't implemented. Priit There is no generic policy framework. There's just a plug-in interface to let you do your own code, which is what I did. There's an example plug-in that includes cracklib in the (current) distribution. While the policies are nice to have for simple set-ups I find them messy and they can't match the requirements I have from on high. Likewise password history won't import because Heimdal doesn't do that. (The example has an inefficient implementation that I didn't use.) Before you take on the work of changing realms you might make sure that rest of the things that won't import are things that actually exist on the Heimdal side. Also since both MIT and Heimdal will compile/run on pretty much any Unix you might consider if it's better/easier to just stick with what you've got. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT + Heimdal + openssh == cross realm difficulties
It's not clear to me why the MIT and Heimdal realms need to be
different.
You can import an MIT database into Heimdal with hprop. Google for the
details, but you export a MIT dump file with some specific options and
then use hprop to read it into Heimdal. There's some place in
Switzerland that is running Heimdal slaves to MIT masters in order to
respond to AFS authentication requests. (Note there is currently no
code to go the other direction.)
Also Heimdal and MIT clients will happily use the other's servers.
On Feb 2, 2005, at 12:56 AM, [EMAIL PROTECTED] wrote:
Date: Wed, 02 Feb 2005 10:54:31 +0200
From: Priit Randla [EMAIL PROTECTED]
To: kerberos@mit.edu
Subject: MIT + Heimdal + openssh == cross realm difficulties
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 12
Hello,
I already posted following message to heimdal-discuss mailinglist,
but, as the
problem involves also MIT Kerberos 5, I'll try my luck here also...
Maybe somebody here is able to help me with my problem involving
Heimdal, MIT and openssh...
Currently we've got a mixed Kerberos 5 infrastructure in place - MIT
Kerberos5 + Windows AD stuff.
Usual stuff - user data on LDAP, password verification with Kerberos.
Our applications are relying on ticket-forwarding extensively, so
whatever we do, ticket forward has to work.
Now, as we're changing our Linux-platform to SuSe, we're going to
migrate to Heimdal. Unfortunately ;-) until
we're finished with migration, we've got to run both MIT and Heimdal
clients and kdc's - so I've got to implement
some kind of cross realm trust between our 3 Kerberos realms (MIT,
Heimdal, AD).
As a first step, i'd like to get cross-realm authentication to work for
openssh with gssapi.
What I've got:
MIT kdc and clients are version 1.3.4
Heimdal kdc and clients are 0.6.1rc3 as found in SuSe 9.0
I tried various versions of openssh, currently i've got
latest-and-greatest 3.9p1 with patches for #918 and #922 from bugzilla
on both MIT and Heimdal based computers.
Let's say I've got realms: AAA default on MIT based machines, BBB on
Heimdal ones.
What I've done:
1. Installed Heimdal kdc, created realm BBB and some principals for
users and involved hosts.
2. Battled pam on SuSe to obtain TGT on login, verified, that ticket
forward works within realm BBB.
3. Created principals for cross-realm authentication: krbtgt/[EMAIL PROTECTED]
and
krbtgt/[EMAIL PROTECTED] on both MIT and Heimdal kdc's,
verified that kvno's, enctypes and passwords are all the same.
4. Verified, that both ssh_config contains options GSSAPIAuthentication
yes,GSSAPIDelegateCredentials yes ; sshd_config
has GSSAPIAuthentication yes.
5. Verified that I can do kgetcred krbtgt/[EMAIL PROTECTED] and krbtgt/[EMAIL PROTECTED],
tgt for [EMAIL PROTECTED] is forwardable, others aren't.
Now, when I attempt ssh connection as [EMAIL PROTECTED] on 172.26.209.15 using
MIT to machine srv1.bbb which uses Heimdal, i got following debug
information:
...
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug2: we sent a gssapi-with-mic packet, wait for reply
debug1: Delegating credentials
debug1: Miscellaneous failure
Requested effective lifetime is negative or too short ( -
Kerberos
error KRB5KDC_ERR_NEVER_VALID )
debug1: Trying to start again
and ssh prompts for a password.
MIT kdc (AAA) log says:
Feb 1 10:25:39 [EMAIL PROTECTED] krb5kdc[20593]: AS_REQ (7 etypes {18 17 16 23
1
3 2}) 172.26.209.15: ISSUE: authtime 1107246339,
etypes {rep=1 tkt=1 ses=1}, [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED]
Feb 1 10:26:35 [EMAIL PROTECTED] krb5kdc[20593]: TGS_REQ (7 etypes {18 17 16 23
1 3 2}) 172.26.209.15: ISSUE: authtime 1107246339, etypes {rep=1 tkt=1
ses=1}, [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED]
Feb 1 10:26:35 [EMAIL PROTECTED] krb5kdc[20593]: TGS_REQ (7 etypes {18 17 16 23
1 3 2}) 172.26.209.15: ISSUE: authtime 1107246339, etypes {rep=1 tkt=1
ses=1}, [EMAIL PROTECTED] for krbtgt/[EMAIL PROTECTED]
Heimdal kdc (BBB) logs says:
TGS-REQ [EMAIL PROTECTED] from IPv4:172.26.209.15 for host/[EMAIL PROTECTED]
[renewable, forwardable]
Client not found in database: [EMAIL PROTECTED]: No such entry in the database
cross-realm AAA - BBB
sending 131 bytes to IPv4:172.26.209.15
krb5.conf has both realms described on all involved computers and
ticket
forward works for AAA-AAA and BBB-BBB.
Where should I look next? Anything? Kindly please ... :-).
Priit
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: How to Force a Kerb 4 Request
Except for the environment variable thing that's exactly what I did. (I put the file in /Library/Preferences/edu.mit.Kerberos.) I didn't do it myself, but someone else was able to use a close relative of my krb5.conf file with RHEL 3. The kinit command *required* the -4 option even though the JPL realm was defined to be K4 only. On Nov 27, 2004, at 8:47 AM, Alexandra Ellwood wrote: Mac OS X's kinit does not support the -4 option because it is incompatible with the way the Kerberos Login Library manipulates tickets. In particular, the KLL defines the concept of a valid ticket cache as one which contains valid TGTs for all versions of Kerberos defined by the machine's Kerberos configuration (aka edu.mit.Kerberos). If we gave users the option of getting only v4 tickets for a realm which supports both v4 and v5, other applications would display this ticket cache as invalid and confuse the user. If you need to solve this problem for a specific user, try creating a special edu.mit.Kerberos file which has dns_fallback = no set in [libdefaults] and only a v4 configuration (ie: [v4 realms] and [v4 domain_realm] only). Then set the KRB5_CONFIG environment variable to point to that file and run kinit. I haven't tried this with all versions of Kerberos for OS X, but it should work. Note however that you may get the confusing behavior I described above if you attempt to use other applications (such as Kerberos.app) to examine the tickets. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: How to Force a Kerb 4 Request
I just went back to a known-good krb5.conf from Jaguar; stripped out all the extraneous realm definitions; added the dns_fallback = no line; and retested. I can now get kerberos 4 tickets on Panther from an AFS kaserver. Obviously I missed something. I will note that the code *still* does a dns lookup. 15:43:30.892937 IP dhcp-149-196-226.jpl.nasa.gov.60962 ns2.jpl.nasa.gov.domain: 37782+ SRV? _kerberos-iv._udp.JPL.NASA.GOV. (48) I suppose it works because there is no Kerb 4 service record for Active Directory. I've had no end of testing trouble with AD hijacking my attempts to use test servers with the real domain/REALM names. Is there another fallback option that applies to Kerb 4? Can I put that option into a realm definition so I still do lookups for non-JPL realms? I really don't want to bother you folks too much about Kerberos 4. Sorry. Kerb 4 should die. It's just that there's this little project here that won't let me deploy Kerb 5 until after they land their probe on Titan in January. On Nov 30, 2004, at 8:24 AM, Alexandra Ellwood wrote: On Nov 30, 2004, at 4:25 AM, Henry B. Hotz wrote: Except for the environment variable thing that's exactly what I did. (I put the file in /Library/Preferences/edu.mit.Kerberos.) I didn't do it myself, but someone else was able to use a close relative of my krb5.conf file with RHEL 3. The kinit command *required* the -4 option even though the JPL realm was defined to be K4 only. That should not be necessary on OS X. KfM should notice that you don't have a v5 config and only get you v4 tickets. Is that what you are seeing? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
How to Force a Kerb 4 Request
It appears that with 1.3.x you can't force it to make a kerberos 4 auth request. I've tried putting only info in the [v4 realms]-like sections and disabling the DNS lookup on OSX 10.3, but then a kinit just fails. Is there any MIT equivalent to Heimdal kinit -4? Yes, I know this is a *BAD* idea and you-all hate it. I just have a test case I need to support. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: How to Force a Kerb 4 Request
Looks like Heimdal, not MIT. What do you get with kinit --version? (Heimdal will print a version message. MIT will ignore the option and just try to authenticate you anyway.) I was looking for an MIT equivalent, which I suspect might not exist. On Nov 23, 2004, at 1:32 PM, Rachel Elizabeth Dillon wrote: From the kinit manpage in the most recent Debian version, which is 1.3.x: OPTIONS -5 get Kerberos 5 tickets. This overrides whatever the default built-in behavior may be. This option may be used with -4 -4 get Kerberos 4 tickets. This overrides whatever the default built-in behavior may be. This option is only available if kinit was built with Kerberos 4 compatibility. This option may be used with -5 I don't have a test server for Kerberos 4, but it works fine with my MIT account. Check your build for Kerberos 4 compatibility? Best of luck, -r. On Tue, Nov 23, 2004 at 01:26:24PM -0800, Henry B. Hotz wrote: It appears that with 1.3.x you can't force it to make a kerberos 4 auth request. I've tried putting only info in the [v4 realms]-like sections and disabling the DNS lookup on OSX 10.3, but then a kinit just fails. Is there any MIT equivalent to Heimdal kinit -4? Yes, I know this is a *BAD* idea and you-all hate it. I just have a test case I need to support. -- -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
krb5.conf variations, was: Renewable Tickets
On Oct 25, 2004, at 4:04 PM, [EMAIL PROTECTED] wrote: First, I'd like to mention I was mistaken when I said the 'libdefaults' section, I meant 'appdefaults', such as: [appdefaults] ticket_lifetime = 30days renew_lifetime = 180days or alternatively, within a 'kinit' subgroup. I'm running with: [appdefaults] renewable = true [libdefaults] renew_lifetime = 7d on my Solaris clients and it seems to do the right thing (against a Heimdal kdc). Looking at the Solaris 9 krb5.conf man page I see max_renewable_life as an [appdefaults] option, but nothing else. Perhaps the renew_lifetime line isn't needed? I suspect the renew_lifetime line is a carryover from some other krb5.conf. In Heimdal it can go in either section and 7d is OK (vice 7days). An MIT 1.3 man page does not mention max_renewable_life, and puts renew_lifetime in [libdefaults] only. I suppose I shouldn't complain. Everyone really is pretty compatible if you're willing to deal with the details. That indicates serious effort on the part of all the implementors, free and commercial alike. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos behind load balancer?
My basic objection to a load balancer is that Kerberos was designed to do its own failover without one. Kerberos was also originally designed to require FQDN's to uniquely map to the destination IP numbers. Violations of those assumptions deserved to fail because they might indicate some attempted crack. While things have changed a lot, I would not be sanguine about avoiding all the possible side effects. I would be concerned independent of any specific problems which have been identified. On Oct 6, 2004, at 5:23 PM, [EMAIL PROTECTED] wrote: Well, the answer to this question is complex. We don't think a load-balancer will be required for our deployment, but it would simplify the end-user experience. I think many of us still don't understand why you say this. Let me attempt to clarify. My assumptions are (pretty much what Ken H suggested): 1) The user's get given a standard krb5.conf file with all the (real or potential) slave kdc's and the master kdc listed. There is no mentionable overhead for configuring extra kdc entries on all clients ahead of time. 2) You're using standard Kerberos software like MIT, Heimdal, Sun, or Microsoft. 3) Your app's use the libraries from 2). Then all applications will try all the kdc's listed in the krb5.conf before failing. No load balancer or DNS tricks needed. The only place you might loose is when the master goes down. Then admin and password change access fails. But it would fail anyway! (I presume you weren't going to have a password change get sent to a random kdc. That would make normal password changes usually fail.) (I'm not trying to be insulting here, just very, very clear and basic.) Password change and admin access do not need the same reliability that normal authentication does. I suspect you could do without for a few days and hardly feel it. I get it that DNS changes and unusual entries are a problem. Here's a suggestion: Don't use the load balancer for normal operations (see 1 above). If and only if the Kerberos master fails, then use the load balancer to redirect traffic to your stand-in master. You'll probably have to play some games with name resolution on the stand-in to make everything work, and I recommend you test the contingency plans carefully. Does this help? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Heimdal or MIT kerberos
On Oct 4, 2004, at 9:02 AM, [EMAIL PROTECTED] wrote: Date: Sun, 03 Oct 2004 22:40:50 -0700 From: Frank Cusack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Heimdal or MIT kerberos Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Precedence: list Message: 2 On Mon, 04 Oct 2004 10:55:49 +0800 sam [EMAIL PROTECTED] wrote: I m not sure which kerberos I should use. They're both good. Don't sweat it too much. Heimdal does not have a functioning replay cache, so if your app needs that you must go with MIT. Very true, but it depends on the app whether it matters or not. Heimdal doesn't support password history checking either, but there's public code to add that if you don't run a very large site. Apache kerberization is a long hard road. You're much better off going with pubcookie or some such system. http://middleware.internet2.edu/webiso/ is a good page that points to lots of web sso software. Hmmm. If you use a recent Mozilla-derivative and mod_auth_kerb with Apache it seems to handle the basics. Haven't checked interop with MS products. Which one you choose may depend on whether you need some add-on. There are a couple of hardware pre-authentication devices supported only with MIT patches, but the PKINIT patches are only for Heimdal. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Solaris pam_krb5 session cleanup
The pam_krb5 session module is supposed to clean up your credentials on logout (if you are the last logout for that session). I had a Solaris 9 machine which did that. Now I have a different S9 machine which doesn't. Any suggestions for what to look for? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris 8 sending K4 requests instead of K5
Bingo! I just fixed it on my test machines, but left it out of the setup procedure that I gave to the VV folk. On Aug 25, 2004, at 6:22 AM, Kevin Coffman wrote: One of my tester's Solaris 8 Kerberos clients is sending Kerberos 4 requests (req's on port 750 anyway). Another solaris 8 machine is doing port 88 requests. Any suggestions why? Is /etc/services different on the two machines? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: arcfour not really there?
Heimdal arcfour == MIT rc4. Also there's the chaining method missing. I'm guessing it ought to be something like cpw -e rc4-cbc-hmac. On Aug 4, 2004, at 9:03 AM, [EMAIL PROTECTED] wrote: Date: Tue, 3 Aug 2004 17:11:10 -0400 From: David Botsch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: arcfour not really there? Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed; charset=ISO-8859-1 MIME-Version: 1.0 Precedence: list Message: 1 Using 1.3.3, can't seem to get arcfour to work (have written about this in the past): kadmin: cpw -e arcfour-hmac:normal bozo change_password: Invalid argument while parsing keysalts arcfour-hmac This happens for all of the arcfour encryption types / salt combos. Thoughts? Thnx. -- David William Botsch Consultant/Advisor II CCMR Computing Facility [EMAIL PROTECTED] The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
Glad you figured it out. I was going to check through the info you gave me on the host principal/keytab, but I guess that wasn't the issue. On Sol 9 a plain kinit will still get the host service ticket; I think it just doesn't throw away the tgt if the host service ticket doesn't work. There is a philosophical issue with whether pam_krb5 should be optional (as Sun and I set it up) or required (sufficient, so it really controls login). The former is clearly correct for a laptop, while the latter is probably correct for a multi-user lab machine. I absolutely agree that all the pam interactions are unfortunately complex for such a critical configuration. We just discovered a few months ago that one of the standard pam configurations we had been using allowed console login as root without a password! It was crazy how hard it was to figure out how to do the other things we needed without exposing the hole. (Thankfully it did not allow network access, and the machines were in locked rooms!) On Jul 29, 2004, at 6:51 PM, Eliot Lebsack wrote: Henry, I just managed to get it working. It turns out that you can't just uncomment the krb5 entries in the /etc/pam.conf file. You also need to make sure that krb5 is sufficient for the auth rule for the service, in this case login. You may need to play with the relationship with pam_unix.so as well, since pam_unix.so may fail the authentication without getting to the krb5 stage to let it do its magic. Sun really needs to do a better job in explaining the interplay between the pam_unix and pam_krb5 modules in /etc/pam.conf. RedHat's authconfig tool sets this up automagically, and I've never had to muck with any of my pam.d files until now. As far as I can tell, the tickets are being issued at login, and destroyed at logout correctly. This is awfully nice. Now, I think the next step is to install the full SEAM packages to get the kerberized telnet server and client. Thanks again for your attention on this issue. Regards, Eliot -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 5:55 PM To: Eliot Lebsack Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) You still haven't told me what happens when you try a kinit as a non-root user on your Solaris 8 machine. That was step one of the debugging procedure I gave you. On your Sol8 machine, while logged in as an ordinaray user please show me: 1) klist before 2) kinit 3) klist after and show me the corresponding entries in the kdc log file from the kerberos server. If you show me this information I can probably help you. On Jul 28, 2004, at 12:48 PM, Eliot Lebsack wrote: Henry, I just went back and tried the following, as the non-root user on another set of machines: command result 1. kinit(successfully) 2. klist(get the initial krbtgt/REALM@REALM) 3. telnet -f somehost (log in) 4. somehost: exit (log out) 5. klist(have two tickets: krbtgt, and host/somehost) As the root user on the solaris 8 machine, I did the following, with NO tickets in the root cache: 1. kinit -k (no answer) 2. klist(get the initial krbtgt/REALM@REALM) When I telnet to the solaris machine from my linux box as non-root user, with a valid initial ticket, the failure occurs as shown in my debug output: sol8test = my solaris 8 machine. Jul 28 15:47:19 sol8test login: [ID 427203 auth.debug] pam_authenticate: error Authentication failed Jul 28 15:47:19 sol8test login: [ID 705685 auth.debug] PAM-KRB5: pam_sm_authenticate Jul 28 15:47:25 sol8test PAM: [ID 599088 auth.debug] pam_close_session: error Authentication token manipulation error Eliot -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 1:16 PM To: Eliot Lebsack Cc: [EMAIL PROTECTED] Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) On Jul 28, 2004, at 5:34 AM, Eliot Lebsack wrote: Henry, Thanks for going through this with me. In response to your questions: 1) Can the user (once logged in) do a kinit? (If not check krb5.conf permissions, and contents.) When I su - username from root, and do a kinit, the ticket is granted by the KDC correctly. Like I said, if kinit works from root, but not from a user account then it's most likely a permissions problem. kinit should work even if the host principal/keytab is messed up. If you have more than one version of kerberos (and kinit) then that could also be a source of problems. This is your basic problem. Worry about it before spending much time on the others. See comments on pam debugging below. Permissions problems on Solaris may not get reported intelligibly, unfortunately. If I try step 3 as user instead of root I get Unknown code 13 for instance. 2) Can the user (once kinit'ed) get a host service ticket? (Try
Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
as host/[EMAIL PROTECTED]) 4) Does the host service ticket agree with the one in the local /etc/krb5/krb5.keytab? (Not sure exactly how to check this. The Solaris ktutil doesn't show much info. Presumably if both 2 and 3 work it should be OK, but they might be different kvno's.) Don't know if Sol 8 is completely like Sol 9, but the pam modules need the host principal to work for full functionality on 9. Isn't there a debug option for the pam modules? On Jul 27, 2004, at 6:29 AM, Eliot Lebsack wrote: Henry, I checked all of the permissions, and they check out. However, this does not fix the problem. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE CorporationBedford, MA -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 6:20 PM To: Eliot Lebsack Cc: [EMAIL PROTECTED] Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) Right, that's the problem. You need to set -rw-r--r-- (644) for krb5.conf. Those permissions are correct for krb5.keytab. Both should be root owned. On Jul 26, 2004, at 1:05 PM, Eliot Lebsack wrote: Henry, Just checked - the permissions are -rw--- (0600). Still have the same problem. The /etc/krb5/krb5.keytab file is also set with the same permissions. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE CorporationBedford, MA -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 3:17 PM To: [EMAIL PROTECTED] Cc: Eliot Lebsack Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) If it works as root, but not as a user, then it sounds like a permissions problem. Is /etc/krb5/krb5.conf world-readable? On Jul 26, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote: Date: Mon, 26 Jul 2004 09:55:02 -0400 From: Eliot Lebsack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Solaris pam-krb5 client and MIT krb5 KDC on Linux Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 Good morning. I've set up a KDC on a RHEL 3 box with NIS as the name service. All of my Linux boxes have no problem authenticating against this configuration. When I attempted to migrate my Solaris 8 (2/02) Ultra 80 to this authentication/name service combination, using the on-board (non-SEAM) kerberos authentication tools which are run when reconfiguring a system (running sys-unconfig, then rebooting), I entered the fields for Kerberos as those used by my Linux machines. I went ahead and synced up my /etc/krb5/krb5.conf file with that used by the Linux clients. I uncommented the pam.conf lines for the pam_krb5.so.1 module as directed by the documention I could find on the web. I've even generated a keytab for the host principle, and moved it into /etc/krb5/krb5.keytab. I've checked my DNS setup as well as NTP. Everything looks good. When I attempt to log onto the Solaris 8 machine as a regular user, forcing the machine to refer to NIS/Kerberos for more information, the pam_krb5 authentication module refuses to allow access. When I su - to the user from root, and do a kinit as the user, it successfully gets the Kerberos ticket. It appears that pam_krb5 is not entering the authentication process correctly, or that it is not negotiating with the KDC correctly. Has anyone else tried a similar configuration? I'm trying to do something real basic here; no kerberized NFS or anything like that. I also tried installing SEAM for Solaris 8, and still had the same problem. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer The MITRE CorporationBedford, MA - - - - The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] -- - - The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] --- - The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED
Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
1) Can the user (once logged in) do a kinit? (If not check krb5.conf permissions, and contents.) 2) Can the user (once kinit'ed) get a host service ticket? (Try telnet'ing to yourself at the external network address. I think that will do it. If not you need a second machine.) 3) Does the local keytab work? (Try kinit -k as root. klist should show you are kinit'ed as host/[EMAIL PROTECTED]) 4) Does the host service ticket agree with the one in the local /etc/krb5/krb5.keytab? (Not sure exactly how to check this. The Solaris ktutil doesn't show much info. Presumably if both 2 and 3 work it should be OK, but they might be different kvno's.) Don't know if Sol 8 is completely like Sol 9, but the pam modules need the host principal to work for full functionality on 9. Isn't there a debug option for the pam modules? On Jul 27, 2004, at 6:29 AM, Eliot Lebsack wrote: Henry, I checked all of the permissions, and they check out. However, this does not fix the problem. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE CorporationBedford, MA -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 6:20 PM To: Eliot Lebsack Cc: [EMAIL PROTECTED] Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) Right, that's the problem. You need to set -rw-r--r-- (644) for krb5.conf. Those permissions are correct for krb5.keytab. Both should be root owned. On Jul 26, 2004, at 1:05 PM, Eliot Lebsack wrote: Henry, Just checked - the permissions are -rw--- (0600). Still have the same problem. The /etc/krb5/krb5.keytab file is also set with the same permissions. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE CorporationBedford, MA -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 3:17 PM To: [EMAIL PROTECTED] Cc: Eliot Lebsack Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) If it works as root, but not as a user, then it sounds like a permissions problem. Is /etc/krb5/krb5.conf world-readable? On Jul 26, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote: Date: Mon, 26 Jul 2004 09:55:02 -0400 From: Eliot Lebsack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Solaris pam-krb5 client and MIT krb5 KDC on Linux Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 Good morning. I've set up a KDC on a RHEL 3 box with NIS as the name service. All of my Linux boxes have no problem authenticating against this configuration. When I attempted to migrate my Solaris 8 (2/02) Ultra 80 to this authentication/name service combination, using the on-board (non-SEAM) kerberos authentication tools which are run when reconfiguring a system (running sys-unconfig, then rebooting), I entered the fields for Kerberos as those used by my Linux machines. I went ahead and synced up my /etc/krb5/krb5.conf file with that used by the Linux clients. I uncommented the pam.conf lines for the pam_krb5.so.1 module as directed by the documention I could find on the web. I've even generated a keytab for the host principle, and moved it into /etc/krb5/krb5.keytab. I've checked my DNS setup as well as NTP. Everything looks good. When I attempt to log onto the Solaris 8 machine as a regular user, forcing the machine to refer to NIS/Kerberos for more information, the pam_krb5 authentication module refuses to allow access. When I su - to the user from root, and do a kinit as the user, it successfully gets the Kerberos ticket. It appears that pam_krb5 is not entering the authentication process correctly, or that it is not negotiating with the KDC correctly. Has anyone else tried a similar configuration? I'm trying to do something real basic here; no kerberized NFS or anything like that. I also tried installing SEAM for Solaris 8, and still had the same problem. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer The MITRE CorporationBedford, MA -- - - The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] --- - The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED
Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
If it works as root, but not as a user, then it sounds like a permissions problem. Is /etc/krb5/krb5.conf world-readable? On Jul 26, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote: Date: Mon, 26 Jul 2004 09:55:02 -0400 From: Eliot Lebsack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Solaris pam-krb5 client and MIT krb5 KDC on Linux Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 Good morning. I've set up a KDC on a RHEL 3 box with NIS as the name service. All of my Linux boxes have no problem authenticating against this configuration. When I attempted to migrate my Solaris 8 (2/02) Ultra 80 to this authentication/name service combination, using the on-board (non-SEAM) kerberos authentication tools which are run when reconfiguring a system (running sys-unconfig, then rebooting), I entered the fields for Kerberos as those used by my Linux machines. I went ahead and synced up my /etc/krb5/krb5.conf file with that used by the Linux clients. I uncommented the pam.conf lines for the pam_krb5.so.1 module as directed by the documention I could find on the web. I've even generated a keytab for the host principle, and moved it into /etc/krb5/krb5.keytab. I've checked my DNS setup as well as NTP. Everything looks good. When I attempt to log onto the Solaris 8 machine as a regular user, forcing the machine to refer to NIS/Kerberos for more information, the pam_krb5 authentication module refuses to allow access. When I su - to the user from root, and do a kinit as the user, it successfully gets the Kerberos ticket. It appears that pam_krb5 is not entering the authentication process correctly, or that it is not negotiating with the KDC correctly. Has anyone else tried a similar configuration? I'm trying to do something real basic here; no kerberized NFS or anything like that. I also tried installing SEAM for Solaris 8, and still had the same problem. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer The MITRE CorporationBedford, MA The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
Right, that's the problem. You need to set -rw-r--r-- (644) for krb5.conf. Those permissions are correct for krb5.keytab. Both should be root owned. On Jul 26, 2004, at 1:05 PM, Eliot Lebsack wrote: Henry, Just checked - the permissions are -rw--- (0600). Still have the same problem. The /etc/krb5/krb5.keytab file is also set with the same permissions. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE CorporationBedford, MA -Original Message- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 3:17 PM To: [EMAIL PROTECTED] Cc: Eliot Lebsack Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack) If it works as root, but not as a user, then it sounds like a permissions problem. Is /etc/krb5/krb5.conf world-readable? On Jul 26, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote: Date: Mon, 26 Jul 2004 09:55:02 -0400 From: Eliot Lebsack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Solaris pam-krb5 client and MIT krb5 KDC on Linux Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1 Good morning. I've set up a KDC on a RHEL 3 box with NIS as the name service. All of my Linux boxes have no problem authenticating against this configuration. When I attempted to migrate my Solaris 8 (2/02) Ultra 80 to this authentication/name service combination, using the on-board (non-SEAM) kerberos authentication tools which are run when reconfiguring a system (running sys-unconfig, then rebooting), I entered the fields for Kerberos as those used by my Linux machines. I went ahead and synced up my /etc/krb5/krb5.conf file with that used by the Linux clients. I uncommented the pam.conf lines for the pam_krb5.so.1 module as directed by the documention I could find on the web. I've even generated a keytab for the host principle, and moved it into /etc/krb5/krb5.keytab. I've checked my DNS setup as well as NTP. Everything looks good. When I attempt to log onto the Solaris 8 machine as a regular user, forcing the machine to refer to NIS/Kerberos for more information, the pam_krb5 authentication module refuses to allow access. When I su - to the user from root, and do a kinit as the user, it successfully gets the Kerberos ticket. It appears that pam_krb5 is not entering the authentication process correctly, or that it is not negotiating with the KDC correctly. Has anyone else tried a similar configuration? I'm trying to do something real basic here; no kerberized NFS or anything like that. I also tried installing SEAM for Solaris 8, and still had the same problem. Regards, Eliot == Eliot Lebsack (781) 271-5830 Lead Communications Engineer The MITRE CorporationBedford, MA --- - The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Two-factor Authentication Options?
In the long run the Kerberos password is a problem because the human brain does not obey Moore's law. As I see it the solution is to use some form of two-factor authentication for the initial ticket exchange. So what options are there in that space? AFAIK none --- with the standard open source servers. There are patches available for MIT to support CRYPTOcard and SecureID. There are patches available for Heimdal to support X509 certificates (PKINIT). Anything else out there? While I'm on the subject, let me throw out an idea: smart card authentication that requires an existing tgt to authenticate. The user first gets an ordinary tgt for [EMAIL PROTECTED] Then (s)he uses that tgt in conjunction with with the smart card (IF details unspecificed) to acquire a tgt for either smith/[EMAIL PROTECTED], or [EMAIL PROTECTED] This isn't the forum to discuss a new proposal, but maybe someone knows of something? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Two-factor Authentication Options?
Given all the issues I didn't want to get into, maybe I shouldn't have mentioned SecureID. Since I did mention it, it's good to have your caveat on the record. Just trying to make sure I really know what exists. On Jul 15, 2004, at 11:27 AM, Ken Hornstein wrote: So what options are there in that space? AFAIK none --- with the standard open source servers. There are patches available for MIT to support CRYPTOcard and SecureID. There are patches available for Heimdal to support X509 certificates (PKINIT). Just as a note: if you want to go down the token road, SecurID isn't a good choice, because due to the API provided you don't gain any entropy that can be used to improve the password. Some sites don't seem to care about this, but you really do care about solving the crypto problem with passwords, it's something to think about. --Ken The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Performance testing Kerberos
We benchmarked significantly more than 50,000 authentications/hour against a Sun Ultra-1 running Solaris 8 and Heimdal 0.6.1. The database contained about 25,000 principals at the time. Does that help? I have no idea if MIT or Solaris 9 would be faster or slower. There's a long history of Kerberos being run on hand-me-down hardware and performing just fine. On Jul 8, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote: Date: Thu, 8 Jul 2004 10:07:17 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Performance testing Kerberos Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: list Message: 6 Is anyone aware of Kerberos being tested from a performance testing standpoint=3F=A0 My company is doing a proof of concept on a third party= version of Kerberos and would like to set some baseline parameters.=A0 I= use Mercury's Loadrunner for testing and am unable to find any information about Kerberos on the Mercury website.=A0 Any=A0input would = be greatly appreciated.=A0 =A0 Thanks=A0=A0 Doug Youngwith=20 Performance Test Engineering=20 Northwestern Mutual=20 [EMAIL PROTECTED] 414-665-6364=20 The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Digest, Vol 19, Issue 9
I don't think it's off-topic, but heimdal questions may get better answers from [EMAIL PROTECTED] This is a bit theoretical for me, but I think you will need to dump the database, upgrade the server (which may use a different backend db utility, even if the db hasn't changed), and then restore the database. All principals should remain intact and tickets issued under one version should generally work with the other one. If you have multiple servers then you should be able to avoid service interruption if you upgrade them one at a time. I wouldn't guarantee that you can mix/match hprop/hpropd between versions (though it might work). As someone else wrote you are best off if you set up some test servers and try the specific upgrade scenario you want to use. On Jul 7, 2004, at 7:50 AM, [EMAIL PROTECTED] wrote: Date: Mon, 05 Jul 2004 15:07:55 -0500 From: Chris Schadl [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Upgrading from Heimdal 0.4 to 0.6 Message-ID: [EMAIL PROTECTED] Precedence: list Message: 5 Apologies in advance if this is off-topic. I'm going to be upgrading my kerberos clients and KDC from heimdal version 0.4e to 0.6.2. I was wondering if I will need to do anyting like re-create or modify my existing principals created under 0.4, and I was also wondering if the 0.6.2 clients (which will be the first to be upgraded) will still be able to authenticate against the 0.4e KDC during the transition period. Thanks, Chris Schadl The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Bug in Kerberos JDK 1.4.2 / Windows XP ?
I'm sure there are doc's on this, but can you configure the workstation to add a correct-for-MIT/Heimdal default realm? (name canonicalization? or is that only on the server end?) On Jun 8, 2004, at 8:19 AM, [EMAIL PROTECTED] wrote: From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Monday, June 07, 2004 4:29 PM To: [EMAIL PROTECTED] Subject: Re: Bug in Kerberos JDK 1.4.2 / Windows XP ? I believe that you are running into the problem of authenticating as the name the user logged in with. Remember that Windows tries to be case insensitive whereas Kerberos is case sensitive. You must log into Windows using the name [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Jeffrey Altman Rouiller Claude wrote: Isn't there a problem with the case (upper case / down case) of the service principal names of the tickets placed in the JAAS subject? Or maybe the problem is in Windows XP? I've described the problem in http://forum.java.sun.com/thread.jsp? forum=60thread=528692tstart=0trange= 15 http://forum.java.sun.com/thread.jsp? forum=60thread=528692tstart=0trange =15 . Claude The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT vs. Heimdal/Sun: Decrypt integrity check failed
In Heimdal the way to do this is: 1) Create the principal with kadmin add -r princ (IIRC this creates a principal without the multiple key salt's because there is no corresponding password, and therefore no applicable key salt. You get a principal with a better key and less confusion.) 2) kadmin del_enctype ... (Delete the enctypes that aren't supported by your target platform. If you're not sure try deleting all of them except des-cbc-md5.) 3) kadmin ext -k keytab princ And securely copy the keytab where it belongs. Note you have to do this step last because step 2 changes the kvno of the key. I think you can do this in one step with the Heimdal ktutil on the remote machine. I've done the above to get keytabs for Solaris that work fine, and I never installed Heimdal on the Solaris client (until much later). On Jun 3, 2004, at 10:53 PM, [EMAIL PROTECTED] wrote: Date: Fri, 04 Jun 2004 00:01:32 -0400 From: Tom Yu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: MIT vs. Heimdal/Sun: Decrypt integrity check failed Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] (Karsten Petersen's message of Thu, 3 Jun 2004 13:38:25 + (UTC)) References: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Precedence: list Message: 8 kapet == Karsten Petersen [EMAIL PROTECTED] writes: kapet Karsten Petersen wrote: we have a KDC (Heimdal 0.6.2) running for a test. kinit works, it successfully provides users with krb4 and krb5 TGTs. kapet Because we want to migrate our AFS to Heimdal Kerberos5, we have the kapet AFS-salt (and the v4-salt) activated on the kdc. 0. A service principal was created on the KDC. kapet And this principal got by default not only v5-salted keys, but also v4- kapet and AFS-salted. I suspect this is at least part of your problem. The keytab contains 10 different encryptions of the service key. kapet 3 x des-cbc-crc kapet 3 x des-cbc-md4 kapet 3 x des-cbc-md5 kapet 1 x des3-cbc-hmac 1. GSS client- and server-app on the GSS test machine both use MIT Kerberos5 1.3.1. This works like a charm. kapet Yeah, because it took the des3-cbc-hmac key. If forced to some other kapet encryption type, it did not work too. When you set up the des3-cbc-hmac key, did you only specify one salt type? It looks like that is the case. kapet After deleting the principal on the server, recreating it only with kapet v5-salted keys and exporting it again - everything worked. So where is the problem? kapet It seems to me that MIT Kerberos5 1.3.1 is not able to handle keytab kapet files with several keys of the same encryption type (but different kapet salts). kapet Or is there some magical krb5.conf option I did not find yet? The Kerberos protocol has no inherent way to tell the application server which of several keys for the same encryption type to use to decrypt the ticket. The ticket only indicates thet encryption algorithm, and not which of several keys suitable for the encryption algorithm. The code that reads the request from the client will search the keytab for the first key which matches the encryption type and kvno specified in the ticket. If this is not the same key which the KDC used to encrypt the ticket, you will get an error. The MIT KDC will pick the first listed key of the highest kvno in the principal entry for encrypting the ticket. I'm not sure what Heimdal does in this case. If you intend a principal to be used as a service principal, it is probably safest to ensure that it only has one key per encryption type. It could be argued that the rd_req operation should attempt to use all keys in the keytab which match the encryption type and kvno of the ticket, but this is not currently done in the MIT code. ---Tom The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
MIT/Heimdal(/Microsoft) Equivalencies
MIT rc4 == Heimdal arcfour == preferred Microsoft encryption type? The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos Digest, Vol 16, Issue 29
On Apr 21, 2004, at 6:13 AM, [EMAIL PROTECTED] wrote: Date: Wed, 21 Apr 2004 08:54:25 -0400 From: Dan Million [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: KFW 2.6.1 Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Precedence: list Message: 11 Jeffrey Altman wrote: To disable the request of Kerberos 4 tickets in Leash, access the Options-Leash Properties... dialog and uncheck the Request Krb4 credentialscheckbox. We tried this, and it still can't get KRB5 tickets. It acts like it's doing the same thing as kinit when we don't use the -5 option. I saw something like this with KfW 2.5. I had to delete the krb 4 config files and reset the options to default before it would obey the option. (Or something like that. We were just starting out and had iterated through a bunch of invalid configurations.) The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: SEAM krb API
According to something I read on sunsolve, on Solaris 8 Sun forgot to remove the Kerberos 4 man pages when they removed the Kerberos 4 libraries and other code. To reinforce what other people have said: 1) there is no native API for Kerberos on Solaris, you use GSSAPI, and 2) there is no mechanism within GSSAPI for acquiring an initial tgt for a client, you use kinit or pam_krb5. (Of course if you didn't believe a sun.com answer I don't know why you'd believe a nasa.gov one on those points. ;-) On Apr 20, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote: Date: Tue, 20 Apr 2004 09:34:03 -0400 From: Wyllys Ingersoll [EMAIL PROTECTED] To: melissa_benkyo [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: SEAM krb API Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 8 melissa_benkyo wrote: hello all, does seam support kerberos API calls? I need to implement a kerberos I'm pretty sure this has already been answered several times, but the answer is no. The Kerberos API is not exposed to programmers when using SEAM. client app that needs to get initial credentials and So far based on my investigation, SEAM doesn't seem to have kerberos api calls. I found krb_get_cred but I believe these are kerberos 4 API calls and besides I dont' have a libkrb. hehehe so that is a problem too. Yup, thats old and broken Kerberos V4 code that should not be used (you must be using Solaris 8, cuz that stuff is not in Solaris 9 or later). -Wyllys The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: setup kerberos client
On Apr 12, 2004, at 5:12 PM, [EMAIL PROTECTED] wrote: Date: 12 Apr 2004 14:36:33 -0700 From: [EMAIL PROTECTED] (melissa_benkyo) To: [EMAIL PROTECTED] Subject: setup kerberos client Message-ID: [EMAIL PROTECTED] Precedence: list Message: 5 Hello all, its me againnn. :D I'm having trouble setting up a kerberos client on solaris 8. I'm running a kdc on a linux machine. and I want to use gss-server on the linux machine and run gss-client on the solaris machine. is this possible? steps that I did: 1) add_principal host/solaris_machine_name@REALM.COM 2) ktadd -k /etc/krb5.keytab host/solaris_machine_name@REALM.COM 3) ktadd -k /tmp/host.keytab host/solaris_machine_name@REALM.COM [to the same thing for sample1/solaris_machine_name@REALM.COM 4) ftp the host.keytab and sample1.keytab to the solaris machine 5) gss-server -port 4 -verbose sample1 output: GSS-API error acquiring credentials: Miscellaneous failure GSS-API error acquiring credentials: No principal in keytab matches desired name But if I use the sample/linux_macine output: GSS-API error acquiring credentials: Wrong rpincipal solaris client side 6) kinit kerberos user (OK!) 7) gss-client -port 4 sample hello world can someone please tell me what I did wrong? thanks! The solaris server error message is what you get if it can't use the keytab. Solaris 8 only supports DES-CBC-CRC and DES-CBC-MD5. 1) Make sure those are the only encryption types for the server principal in on the KDC. 2) Re-create the keytab, making sure the kvno as well as the encryption types match. I expect the client error is a result of the server error. The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Can't change kerberos password on Active Directory with kpasswd
Actually SEAM works just fine with a Heimdal (and therefore MIT and
MS?) KDC, but there are a several caveats:
1) You need to have the latest Kerberos patches from Sun installed.
There's a compatibility bug that's fixed along with the security
fixes.
2) You need to have an entry for kpasswd_protocol = SET_CHANGE.
See the Sun krb5.conf man page to check my spelling, etc.
3) On Solaris 9 you need an entry for kpasswd_server or it will do a
DNS lookup before it falls back to the admin_server entry. (Not
documented, but pretty obvious if you look at snoop.)
4) Your Kerberos principal must match an otherwise-defined account
on the machine. You can't just change some random principal's
password.
I've seen 1 and 4 on Solaris 8, and 3 on Solaris 9. 2 is common to
both. Solaris 7 and earlier has Kerberos 4, not K5/SEAM. No
experience with Solaris 10 (yet).
At 6:18 PM -0400 4/4/04, [EMAIL PROTECTED] wrote:
Date: Fri, 2 Apr 2004 13:11:38 -0500
From: Tareq Alrashid [EMAIL PROTECTED]
To: 'Tyson Oswald' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Can't change kerberos password on Active Directory with kpasswd
Message-ID: [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
Content-Type: multipart/signed;
protocol=application/x-pkcs7-signature;
micalg=SHA1;
boundary==_NextPart_000_0086_01C418B4.070D0450
MIME-Version: 1.0
Precedence: list
Reply-To: [EMAIL PROTECTED]
Message: 9
This is a multi-part message in MIME format.
--=_NextPart_000_0086_01C418B4.070D0450
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Make sure you are using MIT Kerberos 'kpasswd', and NOT the Sun SEAM 1.0.
I was bitten with this a year ago, while authentication works using Sun's
tools
their kpasswd is NOT compatible with MIT's.
hth,
Tareq
-
[EMAIL PROTECTED] - ITS Middleware
10900 Euclid Avenue, CRAWFORD 422, Cleveland, OH 44106-7072
USA - VOICE:1-216-368-3559, FAX:1-216-368-3165
|---Original Message-
|--From: [EMAIL PROTECTED]
|--[mailto:[EMAIL PROTECTED] On Behalf Of Tyson Oswald
|--Sent: Friday, April 02, 2004 09:47
|--To: [EMAIL PROTECTED]
|--Subject: Can't change kerberos password on Active Directory
|--with kpasswd
|--
|--Hello,
|--
|--I have setup kerberos (to Aactive Directory) authentication
|--on Solaris 8 with SEAM 1.0. I can authenticate withut any
|--problems, but if I try and use kpasswd to change my
|--kerberos password I get the following error 'kpasswd:
|--unable to get host based service name for realm
|--myRealm.net'. My /etc/krb5/krb5.conf file looks like
|--
|--[libdefaults]
|--default_realm = MYREALM.NET
|--default_tkt_enctypes = des-cbc-md5
|--default_tgs_enctype = des-cbc-md5
|--
|--[realms]
|--MYREALM.NET = {
|--kdc = 192.168.0.252:88
|--}
|--
|--I have looked on google and didn't see any references to
|--this error. Any help would be greatly appreciated.
|--
|--thank you,
|--
|--Tyson Oswald
|--
|--
|--Kerberos mailing list [EMAIL PROTECTED]
|--https://mailman.mit.edu/mailman/listinfo/kerberos
|--
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Password synching
At 9:40 AM -0600 3/12/04, Digant Kasundra wrote: Is anyone aware of any product that can sync passwords between an MIT Kerberos KDC and MS Active Directory? Alf Wachsmann at SLAC is doing this with Heimdal. Personally I'd rather only have the passwords (keys actually) stored in one of the two, and I'd rather it wasn't the commercial product. Institutional requirements differ though. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] I agree completely. We want to move away from AD and over to Kerb. But the password syncing was a compromise between us (the Unix guys) and Windows guys. We plan to do it on a non-permanent basis as a way of (a) migrating passwords from Windows to Kerb by trapping password change events over the next 3 or 4 months and (b) continuing to allow non-Kerb (NTLM only) apps to still login with the same one username/one password. If either of you can help me out, I'd be greatful. For short-term help you need to talk to Alf. In addition to the documented hook, which let's you check/veto passwords, you need a second one where you record acceptable changes. Alf did a patch for the second and I believe he has working code to actually implement the synchronization. I hope he doesn't mind my advertising what he's done. For more on my own ideas see the Kerberos Feature Request thread I started on kerbdev and the Heimdal list about a month ago. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Docs on string-to-key routines?
At 12:40 PM -0500 3/12/04, Jeffrey Hutzelman wrote: Note that it sounds like the OpenAFS code you were looking at was actually src/des/strng_to_key.c, which implements the DES string-to-key function, not the AFS one. The AFS string-to-key code is in src/kauth/client.c. Correct. I looked for files with key in the name. That explains why they looked so different. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Password synching
At 12:00 PM -0500 3/11/04, [EMAIL PROTECTED] wrote: Date: Thu, 11 Mar 2004 00:46:53 -0600 From: Digant Kasundra [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Password synching Message-ID: [EMAIL PROTECTED] Content-Type: text/plain MIME-Version: 1.0 Precedence: list Message: 1 Is anyone aware of any product that can sync passwords between an MIT Kerberos KDC and MS Active Directory? Alf Wachsmann at SLAC is doing this with Heimdal. Personally I'd rather only have the passwords (keys actually) stored in one of the two, and I'd rather it wasn't the commercial product. Institutional requirements differ though. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: WebISO: the killer kerberos app?
There's also kx509. At 12:00 PM -0500 3/8/04, [EMAIL PROTECTED] wrote: Date: Mon, 08 Mar 2004 08:38:05 -0500 From: Wyllys Ingersoll [EMAIL PROTECTED] To: Russ Allbery [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: WebISO: the killer kerberos app? Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Reply-To: [EMAIL PROTECTED] Message: 2 On Thu, 2004-03-04 at 20:43, Russ Allbery wrote: Christopher Kranz [EMAIL PROTECTED] writes: It occurred to me that if you think of the web client as the credentials cache Kerberos could easily be used as a WebISO solution. The web client connects to the web app. If you don't already have a service ticket you get redirected to a login server that will prompt you for your Kerberos password and get a TGT for you if you do not already have one. So in a sense the web client plus the login server combined looks like the traditional Kerberos client. The login server contacts the KDC and gets a TGT and creates a service ticket for the web app. It ships these back to the web client as cookies. The web client now has credentials to give to the web app. If the client connects to another Kerberized web app it is again redirected to the login server but this time it can use the stored TGT to obtain a service ticket for the new web application. This is exactly the design of Stanford's WebAuth v3. :) See: http://webauthv3.stanford.edu/ Isn't this very similar to the what Passport and Project Liberty propose to use? Basically, its a variation of the secure cookie scheme. Netegrity does something similar as well. Is there a comparison anywhere between webauthv3 and the WebISO used by the above mentioned projects? I would be very interested in the comparison, just to know who is doing what, exactly, and what the benefits are for each system. One thing I dislike about webauth is that it is using raw KRB5 as opposed to the more portable and extensible GSSAPI interface. Why was GSSAPI not chosen? Using raw KRB5 protocol means tying one to a particular Kerberos implementation (MIT, Heimdal, Solaris, Microsoft). GSSAPI is a standard interface and is thus more portable across platforms and does not restrict a site to only using one Kerberos implementation. It also does not restrict one to using Kerberos as the secure authentication protocol. What about projects that just add support for new authentication methods like the Auth Negotiate scheme that Microsoft uses? Work is being done by the Mozilla project to support Kerberos auth via GSSAPI in a compatible manner: http://bugzilla.mozilla.org/show_bug.cgi?id=17578 -- Wyllys Ingersoll wyllys.ingersoll AT sun DOT com -- Date: Mon, 08 Mar 2004 10:40:26 -0500 From: Sam Hartman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: Russ Allbery [EMAIL PROTECTED] Subject: Re: WebISO: the killer kerberos app? Message-ID: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] (Wyllys Ingersoll's message of Mon, 08 Mar 2004 08:38:05 -0500) References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Precedence: list Message: 3 Wyllys == Wyllys Ingersoll [EMAIL PROTECTED] writes: Wyllys Isn't this very similar to the what Passport and Project Wyllys Liberty propose to use? Basically, its a variation of the Wyllys secure cookie scheme. Netegrity does something similar Wyllys as well. There's also the free software pubcookie. My personal recommendation for webauth right now seems to be supporting both gssapi negotiate and pubcookie. I'd prefer a stronger solution than gssapi negotiate. The HTTP SASL draft is being last called, so perhaps we'll get our wish. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
LDAP/Kerberos Integration
Sorry about not fixing the subject in the last email. At 12:16 PM -0500 1/31/04, Sam Hartman wrote: Henry == Henry B Hotz [EMAIL PROTECTED] writes: Henry Well, what we do here is have the LDAP server do a kinit Henry against the central kerberos server for authentication. Henry Native kerberos is a lot more convenient for the users, but Henry you can solve the security issues without it on a Henry case-by-case basis. If that's actually what you do, then you have even bigger security problems. A kinit, without verifying the resulting ticket against a host or service key is completely vulnerable to spoofed KDCs. The code was done years ago by someone who doesn't work here anymore, but no I don't think it uses a keytab. In any case both machines are physically secure and the KDC is contacted over a private network connection. I think the risk is small. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
I don't disagree with your proposal at all. Sounds good. It should make it easier to fix/change things in the future. But. . . Isn't the reason this keeps coming up that AFS client doesn't (can't?) behave like a normal Kerberos application and just get it's own service ticket when it needs one (based on an existing tgt)? The real reason this doesn't happen is that tickets are stored in a file in /tmp, but it's a different set of file system code inside the kernel that would need to access it to request the service ticket. Can't we figure a way to just make the kernel module get the service ticket (token) automatically, or fail if there is no tgt? That would make the whole problem go away and AFS would no longer need the special attention it does now. I note that on MacOS X tickets are stored in a MACH security context which acts a lot like a PAG. Furthermore it's accessible inside the kernel. Doesn't Windows have some similar in-memory storage mechanism? Has anyone thought about how congruent PAGs and terminal sessions are? I think X11 defined the latter, and Kerberos has tried to tie in to them rather than import the PAG concept. At 11:21 AM -0600 1/26/04, Douglas E. Engert wrote: Rather then implementing kafs in MIT Kerberos, I would like to suggest an alternative which has advantages to all parties. The OpenSSH sshd needs to do two things: (1) sets a PAG in the kernel, (2) obtains an AFS token storing it in the kernel. It can use the Kerberos credentials either obtained via GSSAPI delegation, PAM or other kerberos login code in the sshd. The above two actions can be accomplished by a separate process, which can be forked and execd by the sshd and passed the environment which may have a KREB5CCNAME pointing at the Kerberos ticket cache Other parameters such as the home directory could also be passed. This would then allow simple code in OpenSSH that does not depend on OpenAFS, Hiemdal or MIT code to fork/exec the process that does all the work. This would be called by the process that would eventially become the user's shell process and is run as the user. OpenSSH could be built on systems that may or may not have AFS installed and run on a system with or without AFS. The decision is based on the existence of the executable and any options in sshd_config. In its simplest form, all that is needed is: system(/usr/ssh/libexec/aklog -setpag) This is a little over simplified as there should be a test if the executable exists, processing of some return codes, making sure the environment is set, setting some time limit. etc. But the point is there is no compile dependence on OpenAFS, MIT or Hiemdal by the OpenSSH sshd, and any failure of the process will not effect the sshd. We have been using something like this for years which issues a syscall to set a PAG for the current process, then fork/exec ak5log. Our current mode to OpenSSH in session.c is as simple as: krb5_afs_pag_env(NULL, env); It is currently built with the MIT Kerberos code for historic reasons, but could be seperate as it has no real dependency on the MIT code. I would hope that the members of the OpenSSH community who use OpenAFS, Hiemdal and/or MIT could agree on a simple command line interface that would encourage the builders of OpenSSH to always have this enabled. -- Douglas E. Engert [EMAIL PROTECTED] Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes
At 9:07 PM +0100 1/22/04, Harald Barth wrote: I think that OpenSSL != OpenSSH. Correct. I got the install order wrong. The right order is OpenSSL, Heimdal, OpenSSH. Harald. OK, so how do you install OpenSSL with RFC 2712 support enabled? -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Using cracklib with the KDC
At 12:00 PM -0400 10/12/03, Sam Hartman wrote: Henry == Henry B Hotz [EMAIL PROTECTED] writes: Henry Does the MIT code have a user hook in the change password Henry function where I can link in cracklib? No. Nicolas Williams from Sun has proposed that the right way to do this is for the KDC to use libpam on systems that have it and to use the password stack to run modules like cracklib. This seems like an interesting approach to try, but we have not yet implemented it. I agree that doing the check in PAM on the client side is interesting, but it fulfills a different goal. In my case the goal is institutional enforcement of some QA on passwords. That means it has to be done at the server end, like Heimdal does it. I suppose that I have the option of looking through the source code and implementing it myself. I was just hoping it was easier than that. (Consider this a feature request.) -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Using cracklib with the KDC
Does the MIT code have a user hook in the change password function where I can link in cracklib? -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: bad ticket
Is it possible you built ssh with kerberos 4 support instead of kerberos 5 support? At 12:00 PM -0400 7/16/03, [EMAIL PROTECTED] wrote: Date: Wed, 16 Jul 2003 17:06:31 +0200 From: Jeremy Fressard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: bad ticket Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed MIME-Version: 1.0 (Apple Message framework v552) Content-Transfer-Encoding: 7bit Precedence: list Message: 2 Hello, I have install kerberos v5 on a solaris9 and i have a problem, I create in my krb5.keytab host/[EMAIL PROTECTED] After I install SSH with the kerberos option, but when I try a ssh comand it want host/[EMAIL PROTECTED], where is my .laas.fr ??? When i create host/[EMAIL PROTECTED], that work perfectly. I think the problem is GSSAPI which not make the good request!! If something have an idea??? I have a Mac os x 10.2 in front of me and this one get the good ticket (host/[EMAIL PROTECTED]), maybe it have another GSSAPI library which work corectly??) (Sorry for my english) Thanks -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
OSX Panther Configuration
Are there documents that describe how to configure Kerberos for OSX 10.3 (Panther) yet? I tried copying my /Library/Preferences/edu.mit.Kerberos file over and that wasn't enough for the Kerberos GUI to work. (I got an error something like user not in database. The configuration should have pointed to an AFS kaserver and used Kerberos 4. I deleted the reference to the LoginLogout plugin, otherwise no change. It worked under Jaguar.) -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [EMAIL PROTECTED], or [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
