From azhar at nervesis.com.my Fri Jan 2 07:33:03 2009 From: azhar at nervesis.com.my (Azhar K Mustapha) Date: Fri, 2 Jan 2009 20:33:03 +0800 Subject: Principal attributes and policy in LDAP Realm Message-ID: <000001c96cd6$425e7ea0$c71b7be0$@com.my> Dear all. I have been trying to use Kerberos with kdb ldap backend (openldap 2.4.11). I have using two ldap servers to emulate multimaster environment for Kerberos. There are some funny things happened. 1. If I don't enable multimaster replication using ldap, using kadmin. I can add a Kerberos user, and I can run 'getprinc' command of that user 2. If I enable the multimaster setting with ldap, using kadmin, I can add a Kerberos user, however, I will get segmentation fault when running 'getprinc' of that user. Later, I try to use gdb to notice behavior of kadmin. I found out the segmentation fault happens because in the multimaster setting, the number of keys generated for the users are 3 instead of 2 in a no multi-masterl condition, thus, giving a segmentation fault. Next, I theorize as below, 1. There is a problem with openldap 2.4.11 replication when it comes to replication binary data of krbPrincipalKey and krbExtraData (data corruption) 2. Or, there is a problem with kdb ldap itself. I think this problem is too fundamental for me to fix it myself. Therefore I am resorting to use the non-ldap storage for Kerberos backend Azhar From Nika at teletrain.nl Fri Jan 2 02:57:30 2009 From: Nika at teletrain.nl (Nika Gerson Lohman) Date: Fri, 2 Jan 2009 08:57:30 +0100 Subject: Problems unwrapping SPNEGO token for Single Signon (SSO) in WebLogic Server 8.1. Message-ID: First of all, a quick description of our issue. We've tried many different things, but cannot get WebLogic to unwrap the SPNEGO token so it authenticates using Kerberos. We received several errors while trying to debug, here's the one we see most: KDC has no support for encryption type (14) But we doubt it has anything to do with the encryption type, as these are set correctly everywhere. We've tried following some of the instructions on the BEA website (which contain several errors). One of them was also adding a host/ SPN (in krb5login.conf) but then, when using HTTP/ SPN we get the following error (it seems with multiple SPN's it only takes the first or last SPN that was set): Client not found in Kerberos database (6) Next try was using the host/ SPN but that results in the following error: Integrity check on decrypted field failed (31) We've tried changing the default_*_enctypes in KRB5.INI (We've removed the entries, and also tried only DES_CBC_MD5 and DES_CBC_CRC) but that did not change the behaviour. We've tried adding the AllowTGTSessionKey registry key on client and server, but that didn't change it either. We are not sure what details you need for this to debug, so here's what we've done to install the environment (please note that ip-addresses, domain, client and server names are made up and are different in real-life), We have two domains: Domain1 (DOMAIN1.COM) contains: Domain Controller "AD1" with IP 192.168.0.1 Domain Controller "AD2" with IP 192.168.1.1 Client "Client1" with IP 192.168.2.1 Domain2 (DOMAIN2.COM) contains: Domain Controller "AD3" with IP 10.0.0.1 Server (WebLogic) "Server1" with IP 10.0.1.2 Between Domain1 and Domain2 a firewall exists in which we've opened the relevant ports like LDAP (TCP 389), Kerberos (UDP 88), WebLogic (7001/7002).We do not see any firewall blocks on other ports... We've configured AD1 (Microsoft AD with KDC) as follows: 1. Account "SSOAccountAD" created 2. Password never expires 3. DES encryption on 4. Do not require Kerberos preauthentication off 5. Password "Password" was reset several times 6. ServicePrincipalName was set using this setspn -A HTTP/Server1.DOMAIN1.COM SSOAccountAD 1. ServicePrincipalName on AD1 was checked (and found to be ok) using this command: setspn -L SSOAccountAD 1. KTPass was executed: ktpass -princ HTTP/Server1 at DOMAIN1.COM -mapuser SSOAccountAD -pass Password 1. User Logon name was checked: HTTP/Server1 1. ServicePrincipalName on AD2 was checked (and found to be ok) using this command: setspn -L SSOAccountAD We've configured the WebLogic Server (Server1) as follows: 1. LDAP authentication was activated and test ok 2. Single Pass Negotiate Identity Asserter was created with Chosen Type "Authorization" 3. KRB5.INI file was created and added to %windir% (and C:\WINNT folder to be able to test with Java ktab and kinit which do not look in the %windir% folder): [libdefaults] default_realm = DOMAIN1.COM dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes=DES-CBC-CRC default_tgs_enctypes=DES-CBC-CRC [realms] DOMAIN1.COM = { kdc = 192.168.0.1 admin_server = 192.168.0.1 default_domain = DOMAIN1.COM } [domain_realm] .domain1.com = DOMAIN1.COM domain1.com = DOMAIN1.COM [appdefaults] autologin = true forward = true forwardable = true encrypt = true 1. We've installed JDK 1.5.0.12: jdk-1_5_0_12-windows-i586-p.exe 2. Keytab File was created (with password "Password"): ktab -k SSOKeyTabFile -a HTTP/Server1 at DOMAIN1.COM 1. Keytab File and Kerberos communication was tested using: kinit -k -t SSOKeyTabFile HTTP/Server1 at DOMAIN1.COM 1. Keytab File and Kerberos communication was tested using Java (incl. Debugging): java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Kinit -k -t SSOKeyTabFile HTTP/Server1 at DOMAIN1.COM 1. Keytab was listed: java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Klist 1. SSOKeyTabFile was copied to the WebLogic ProductionDomain folder 2. The krb5login.conf file was created and copied to the WebLogic ProductionDomain folder: com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/Server1 at DOMAIN1.COM" useKeyTab=true keyTab=SSOKeyTabFile storeKey=true debug=true; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required principal=" HTTP/Server1 at DOMAIN1.COM " useKeyTab=true keyTab=SSOKeyTabFile storeKey=true debug=true; }; 1. WebLogic service and startWeblogic.cmd were modified with the following parameters: -Djava.security.krb5.realm=DOMAIN1.COM -Djava.security.krb5.kdc=192.168.0.1 -Djava.security.auth.login.config=\krb5login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true -DDebugSecurityAdjudicator=true -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugSecurityAtz=true -Dweblogic.Debug.DebugSecurityATN=true -Dweblogic.StdoutSeverityLevel=64 -Dweblogic.StdoutDebugEnabled=true For the client pc (Client1) we've checked the browser settings: Automatic Logon only in Intranet Zone Enable Integrated Windows Authentication On the client we've used "kerbtray.exe" to see whether a kerberos token is created, and it is (although with the full domain name, HTTP/Server1.domain1.com). We've checked for Kerberos communication with Wireshark and see that the client does communicate, and passes the SPNEGO token to the WebLogic server, but we do not see any Kerberos communication on the WebLogic server. The server simply requests Authorisation again... If required we have the full wireshark traces of the WebLogic Server and the Client. We also have very detailed WebLogic tracing which I can provide. Kind Regards, Nika. Nika Gerson Lohman Senior Software Engineer Tele'Train Software BV, http://www.teletrain.nl Paasheuvelweg 1 1105 BE Amsterdam Telefoon: +31 (0)20 379 03 52 Fax: +31 (0)20 379 03 53 Private Fax: +31 (0)84 222 49 06 Mobiel: +31 (0)62 040 13 50 E-Mail: nika at teletrain.nl MSN: nika at teletrain.nl From morten at gatech.edu Sat Jan 3 16:55:13 2009 From: morten at gatech.edu (Morten S. Laursen) Date: Sat, 03 Jan 2009 22:55:13 +0100 Subject: Samba + Kerberos + LDAP Message-ID: <495FDEC1.8090806@gatech.edu> Hi For the last couple of days I've been working on getting Kerberos(MIT), Samba and LDAP(OpenLdap) working together. I have no PDC or active directory on site, I wish for the Kerberos/LDAP to be the only place where users should be stored (having especially passwords in multiple locations seems like to much of a hack). I need the Samba for file sharing with windows users (primarily Windows XP, but there is some Vista installations as well). I managed to connect using a Windows machine (XP), but not before I manually added my Kerberos server using ksetup. As I've become a little unsure if I've misunderstood anything, is it at all possible to connect to a samba server using MIT kerberos, without having to install any extra software or modify any configurations on the Windows machines? (quite often we have guests that need to connect, and therefore modifying their machines is a no go). I've tried scanning the network traffic, and the requests from an unaltered Windows client newer seem to reach the Kerberos server. I could really need a clarification on whether what I'm trying to accomplish is possible. And if you have any literature you would recommend as well I would appreciate it. Thank you in advance for any advice Morten S. Laursen Engineering College of Aarhus Dalgas avenue 2 8000-DK Aarhus C From vijivijayakumar at gmail.com Mon Jan 5 00:53:16 2009 From: vijivijayakumar at gmail.com (Viji V Nair) Date: Mon, 5 Jan 2009 11:23:16 +0530 Subject: Samba + Kerberos + LDAP In-Reply-To: <495FDEC1.8090806@gatech.edu> References: <495FDEC1.8090806@gatech.edu> Message-ID: <84c89ac10901042153o77805cdaj42711315c0b5616@mail.gmail.com> Hi, You can connect to a samba server using MIT kerberos, You can also configure windows to authenticate to an MIT kerberos server. There is new project called freeIPA, which integrates MIT kerberos, Fedora directory server and lots of other thing. Have a look at the same life will be easy for you. http://freeipa.org/page/Main_Page Thanks & Regards Viji On Sun, Jan 4, 2009 at 3:25 AM, Morten S. Laursen wrote: > Hi > For the last couple of days I've been working on getting Kerberos(MIT), > Samba and LDAP(OpenLdap) working together. > I have no PDC or active directory on site, I wish for the Kerberos/LDAP > to be the only place where users should be stored (having especially > passwords in multiple locations seems like to much of a hack). > I need the Samba for file sharing with windows users (primarily Windows > XP, but there is some Vista installations as well). I managed to connect > using a Windows machine (XP), but not before I manually added my > Kerberos server using ksetup. > As I've become a little unsure if I've misunderstood anything, is it at > all possible to connect to a samba server using MIT kerberos, without > having to install any extra software or modify any configurations on the > Windows machines? (quite often we have guests that need to connect, and > therefore modifying their machines is a no go). > I've tried scanning the network traffic, and the requests from an > unaltered Windows client newer seem to reach the Kerberos server. > I could really need a clarification on whether what I'm trying to > accomplish is possible. And if you have any literature you would > recommend as well I would appreciate it. > > Thank you in advance for any advice > Morten S. Laursen > Engineering College of Aarhus > Dalgas avenue 2 > 8000-DK Aarhus C > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > From mizmoose at gmail.com Mon Jan 5 17:16:19 2009 From: mizmoose at gmail.com (Esther Filderman) Date: Mon, 5 Jan 2009 17:16:19 -0500 Subject: Deadline- Jan 9! CFP: 2009 OpenAFS & Kerberos Best Practices Workshop Message-ID: This is a reminder that the Call for Participation for the 2009 OpenAFS & Kerberos Best Practices Workshop will end Friday January 9, 2009. We look forward to hearing about your talk! Submit your talk at: http://workshop.openafs.org/afsbpw09/cfp.html Acceptances will be made based upon quality, applicability, and fit with other submissions. Come talk to your peers about: * Completed projects * Best practices * Work in progress * Related research * Theories * Updates on previous talks or anything else of note involving AFS and/or Kerberos. The AFS & Kerberos Best Practices Workshop is a week long conference for the novice and the experienced. The week is filled with two full-day classes introducing AFS and Kerberos plus two and one half days of talks by your peers and colleagues. The workshop will be held at Stanford University, June 1st to 5th, 2009. Topics may include, but are not limited to: * AFS & Kerberos v5 * AFS & Kerberos v5 related tools * Best practices * Upgrade strategies * Benchmarking * Automation * Web integration * Administration delegation * Work on non-Unix platforms * Server scaling * Service monitoring * Work on new features * Performance tuning * Unique methods of AFS and/or Kerberos Backups Stay tuned for further information about scheduling, registration, travel and hotel arrangements, and other topics. The Workshop Organizers http://workshop.openafs.org/ From engemam at uni-muenster.de Wed Jan 7 09:45:49 2009 From: engemam at uni-muenster.de (Michael Engemann) Date: Wed, 7 Jan 2009 15:45:49 +0100 Subject: computer account change password with Windows 2008 domain Message-ID: Hi, we are also experiencing the bug in Windows Server 2008 that was mentionend on this list in April 2008 by Russ Allberry: * Microsoft broke password changes via the LDAP protocol with SASL GSSAPI binds in Windows 2008. In Windows 2003, provided that you didn't try to negotiate an SASL privacy layer, you could connect via TLS and authenticate with GSSAPI and query or set the password attribute directly. In Windows 2008, this no longer works; you always get the error from the server that you are not permitted to negotiate a privacy layer when using TLS, even though you're not trying to. We've already filed this as a bug. Are there probably any news about a fix or a known workaround? Thanks in advance, Michael From Tim.Alsop at CyberSafe.com Wed Jan 7 09:56:52 2009 From: Tim.Alsop at CyberSafe.com (Tim Alsop) Date: Wed, 7 Jan 2009 14:56:52 +0000 Subject: computer account change password with Windows 2008 domain In-Reply-To: References: Message-ID: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EEF@exchange.cybersafe.local> Hi, We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP when using Active Directory on Windows Server 2008. Thanks, Tim -----Original Message----- From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Michael Engemann Sent: 07 January 2009 14:46 To: kerberos at mit.edu Subject: computer account change password with Windows 2008 domain Hi, we are also experiencing the bug in Windows Server 2008 that was mentionend on this list in April 2008 by Russ Allberry: * Microsoft broke password changes via the LDAP protocol with SASL GSSAPI binds in Windows 2008. In Windows 2003, provided that you didn't try to negotiate an SASL privacy layer, you could connect via TLS and authenticate with GSSAPI and query or set the password attribute directly. In Windows 2008, this no longer works; you always get the error from the server that you are not permitted to negotiate a privacy layer when using TLS, even though you're not trying to. We've already filed this as a bug. Are there probably any news about a fix or a known workaround? Thanks in advance, Michael ________________________________________________ Kerberos mailing list Kerberos at mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos From engemam at uni-muenster.de Wed Jan 7 10:10:28 2009 From: engemam at uni-muenster.de (Michael Engemann) Date: Wed, 7 Jan 2009 16:10:28 +0100 Subject: AW: computer account change password with Windows 2008 domain In-Reply-To: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EEF@exchange.cybersafe.local> References: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EEF@exchange.cybersafe.local> Message-ID: Hi Tim, can you tell me than what am I doing wrong? Even a simple ldapsearch that was functioning for Windows 2003 throws an error for 2008: ldapsearch -Hldap://fqdn -b "" -s base -Omaxssf=0 -ZZ SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C09048A, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v1771 Thanks, Michael > -----Urspr?ngliche Nachricht----- > Von: Tim Alsop [mailto:Tim.Alsop at CyberSafe.com] > Gesendet: Mittwoch, 7. Januar 2009 15:57 > An: Michael Engemann; kerberos at mit.edu > Betreff: RE: computer account change password with Windows 2008 domain > > Hi, > > We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP > when using Active Directory on Windows Server 2008. > > Thanks, > Tim > > -----Original Message----- > From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On > Behalf Of Michael Engemann > Sent: 07 January 2009 14:46 > To: kerberos at mit.edu > Subject: computer account change password with Windows 2008 domain > > Hi, > > we are also experiencing the bug in Windows Server 2008 that was > mentionend on this list in April 2008 by Russ Allberry: > > * Microsoft broke password changes via the LDAP protocol with SASL > GSSAPI > binds in Windows 2008. In Windows 2003, provided that you didn't try > to > negotiate an SASL privacy layer, you could connect via TLS and > authenticate with GSSAPI and query or set the password attribute > directly. In Windows 2008, this no longer works; you always get the > error from the server that you are not permitted to negotiate a > privacy > layer when using TLS, even though you're not trying to. We've > already > filed this as a bug. > > Are there probably any news about a fix or a known workaround? > > Thanks in advance, > > Michael > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos From Tim.Alsop at CyberSafe.com Wed Jan 7 10:19:57 2009 From: Tim.Alsop at CyberSafe.com (Tim Alsop) Date: Wed, 7 Jan 2009 15:19:57 +0000 Subject: computer account change password with Windows 2008 domain In-Reply-To: References: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EEF@exchange.cybersafe.local> Message-ID: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EF1@exchange.cybersafe.local> Michael, I don't know what is wrong, but I do know that our product works fine with Windows Server 2008 and 2003. We use our own Kerberos and GSS-API library (not MIT or Heimdal), and Cyrus SASL with OpenLDAP. We have seen a similar problem where Active Directory on Windows Server 2003 has the LDAP Server signing policy set in the domain controllers group policy. This setting means that AD expects SSL/TLS to be used for signing, but when Kerberos/GSS/SASL/LDAP is used the signing is done using Kerberos keys instead. It seems that MS AD has a bug which effects use of SASL/LDAP bind when this policy setting is made. This is a discussed at http://technet2.microsoft.com/windowsserver/en/library/56044016-3123-4859-8fd9-c5a461a1c5c81033.mspx?mfr=true and I have included some output below which was shown when this policy setting is made. Not sure if this helps at all ? Perhaps your Win2k8 domain has a policy setting which is non-default and is causing your issue due to a similar bug ? SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Strong(er) authentication required (8) additional info: 00002028: LdapErr: DSID-0C09018A, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, vece Failed to connect to LDAP Server Error occurred in netjoin while performing netjoin operations ( 0x00005102 20738 ) Cannot open connection to LDAP Server Thanks, Tim -----Original Message----- From: Michael Engemann [mailto:engemam at uni-muenster.de] Sent: 07 January 2009 15:10 To: Tim Alsop; Michael Engemann; kerberos at mit.edu Subject: AW: computer account change password with Windows 2008 domain Hi Tim, can you tell me than what am I doing wrong? Even a simple ldapsearch that was functioning for Windows 2003 throws an error for 2008: ldapsearch -Hldap://fqdn -b "" -s base -Omaxssf=0 -ZZ SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C09048A, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v1771 Thanks, Michael > -----Urspr?ngliche Nachricht----- > Von: Tim Alsop [mailto:Tim.Alsop at CyberSafe.com] > Gesendet: Mittwoch, 7. Januar 2009 15:57 > An: Michael Engemann; kerberos at mit.edu > Betreff: RE: computer account change password with Windows 2008 domain > > Hi, > > We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP > when using Active Directory on Windows Server 2008. > > Thanks, > Tim > > -----Original Message----- > From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On > Behalf Of Michael Engemann > Sent: 07 January 2009 14:46 > To: kerberos at mit.edu > Subject: computer account change password with Windows 2008 domain > > Hi, > > we are also experiencing the bug in Windows Server 2008 that was > mentionend on this list in April 2008 by Russ Allberry: > > * Microsoft broke password changes via the LDAP protocol with SASL > GSSAPI > binds in Windows 2008. In Windows 2003, provided that you didn't try > to > negotiate an SASL privacy layer, you could connect via TLS and > authenticate with GSSAPI and query or set the password attribute > directly. In Windows 2008, this no longer works; you always get the > error from the server that you are not permitted to negotiate a > privacy > layer when using TLS, even though you're not trying to. We've > already > filed this as a bug. > > Are there probably any news about a fix or a known workaround? > > Thanks in advance, > > Michael > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos From Tim.Alsop at CyberSafe.com Wed Jan 7 10:40:55 2009 From: Tim.Alsop at CyberSafe.com (Tim Alsop) Date: Wed, 7 Jan 2009 15:40:55 +0000 Subject: computer account change password with Windows 2008 domain In-Reply-To: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EF1@exchange.cybersafe.local> References: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EEF@exchange.cybersafe.local> <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EF1@exchange.cybersafe.local> Message-ID: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902EF3@exchange.cybersafe.local> Michael, I have just been reminded/corrected that our product actually uses kpasswd protocol to change password, not ldap change password - sorry for any confusion caused by this mistake. This is perhaps why it works for us, but not for you. Maybe you could also use kpasswd ? Anyway, perhaps the info in my last post helps and this is related to a domain policy setting in some way ? Good luck, Tim -----Original Message----- From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Tim Alsop Sent: 07 January 2009 15:20 To: Michael Engemann; kerberos at mit.edu Subject: RE: computer account change password with Windows 2008 domain Michael, I don't know what is wrong, but I do know that our product works fine with Windows Server 2008 and 2003. We use our own Kerberos and GSS-API library (not MIT or Heimdal), and Cyrus SASL with OpenLDAP. We have seen a similar problem where Active Directory on Windows Server 2003 has the LDAP Server signing policy set in the domain controllers group policy. This setting means that AD expects SSL/TLS to be used for signing, but when Kerberos/GSS/SASL/LDAP is used the signing is done using Kerberos keys instead. It seems that MS AD has a bug which effects use of SASL/LDAP bind when this policy setting is made. This is a discussed at http://technet2.microsoft.com/windowsserver/en/library/56044016-3123-4859-8fd9-c5a461a1c5c81033.mspx?mfr=true and I have included some output below which was shown when this policy setting is made. Not sure if this helps at all ? Perhaps your Win2k8 domain has a policy setting which is non-default and is causing your issue due to a similar bug ? SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Strong(er) authentication required (8) additional info: 00002028: LdapErr: DSID-0C09018A, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, vece Failed to connect to LDAP Server Error occurred in netjoin while performing netjoin operations ( 0x00005102 20738 ) Cannot open connection to LDAP Server Thanks, Tim -----Original Message----- From: Michael Engemann [mailto:engemam at uni-muenster.de] Sent: 07 January 2009 15:10 To: Tim Alsop; Michael Engemann; kerberos at mit.edu Subject: AW: computer account change password with Windows 2008 domain Hi Tim, can you tell me than what am I doing wrong? Even a simple ldapsearch that was functioning for Windows 2003 throws an error for 2008: ldapsearch -Hldap://fqdn -b "" -s base -Omaxssf=0 -ZZ SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: 00002029: LdapErr: DSID-0C09048A, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v1771 Thanks, Michael > -----Urspr?ngliche Nachricht----- > Von: Tim Alsop [mailto:Tim.Alsop at CyberSafe.com] > Gesendet: Mittwoch, 7. Januar 2009 15:57 > An: Michael Engemann; kerberos at mit.edu > Betreff: RE: computer account change password with Windows 2008 domain > > Hi, > > We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP > when using Active Directory on Windows Server 2008. > > Thanks, > Tim > > -----Original Message----- > From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On > Behalf Of Michael Engemann > Sent: 07 January 2009 14:46 > To: kerberos at mit.edu > Subject: computer account change password with Windows 2008 domain > > Hi, > > we are also experiencing the bug in Windows Server 2008 that was > mentionend on this list in April 2008 by Russ Allberry: > > * Microsoft broke password changes via the LDAP protocol with SASL > GSSAPI > binds in Windows 2008. In Windows 2003, provided that you didn't try > to > negotiate an SASL privacy layer, you could connect via TLS and > authenticate with GSSAPI and query or set the password attribute > directly. In Windows 2008, this no longer works; you always get the > error from the server that you are not permitted to negotiate a > privacy > layer when using TLS, even though you're not trying to. We've > already > filed this as a bug. > > Are there probably any news about a fix or a known workaround? > > Thanks in advance, > > Michael > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos at mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos From Gopal_Prakriya at ml.com Wed Jan 7 11:11:58 2009 From: Gopal_Prakriya at ml.com (Prakriya, Gopal (A&E)) Date: Wed, 7 Jan 2009 11:11:58 -0500 Subject: kinit is not working Message-ID: <95172D7B900E384D9D05E2304F2E897B014E348D@MLNYC20MB055.amrs.win.ml.com> We are running kerberos V4, all our users passwords expired on Dec 31, 2008 Neither of these two kinit or kpasswd are working root at krb # /usr/local/krb4/bin/kinit Merrill Lynch (krb) Kerberos Initialization Kerberos name: gprakriy kinit: Principal expired (kerberos) Gopal Prakriya A & E Identity & Naming Services Work:609-274-1788 AIM: gprakriya -------------------------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. References to "Merrill Lynch" are references to any company in the Merrill Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this E-communication may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. -------------------------------------------------------------------------- From rra at stanford.edu Wed Jan 7 13:45:29 2009 From: rra at stanford.edu (Russ Allbery) Date: Wed, 07 Jan 2009 10:45:29 -0800 Subject: computer account change password with Windows 2008 domain In-Reply-To: (Michael Engemann's message of "Wed\, 7 Jan 2009 15\:45\:49 +0100") References: Message-ID: <87wsd73qgm.fsf@windlord.stanford.edu> Michael Engemann writes: > we are also experiencing the bug in Windows Server 2008 that was > mentionend on this list in April 2008 by Russ Allberry: > > * Microsoft broke password changes via the LDAP protocol with SASL GSSAPI > binds in Windows 2008. In Windows 2003, provided that you didn't try to > negotiate an SASL privacy layer, you could connect via TLS and > authenticate with GSSAPI and query or set the password attribute > directly. In Windows 2008, this no longer works; you always get the > error from the server that you are not permitted to negotiate a privacy > layer when using TLS, even though you're not trying to. We've already > filed this as a bug. > > Are there probably any news about a fix or a known workaround? The workaround is to use the password change protocol instead of using LDAP. That's what we modified our code to do, since so far as I know Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI privacy layers in their LDAP implementation is oddly broken in ways that are apparently difficult to fix, leading the server to think that you've always negotiated a privacy layer even if you haven't. At least that's my understanding of the problem.) -- Russ Allbery (rra at stanford.edu) From rwilper at stanford.edu Wed Jan 7 14:29:23 2009 From: rwilper at stanford.edu (Wilper, Ross A) Date: Wed, 7 Jan 2009 11:29:23 -0800 Subject: computer account change password with Windows 2008 domain In-Reply-To: <87wsd73qgm.fsf@windlord.stanford.edu> References: <87wsd73qgm.fsf@windlord.stanford.edu> Message-ID: The QoP negotiation issue is fixed by the hotfix with KB article 957072. This has been applied to our systems, but as of yet, I have not seen that this hotfix has been released publicly. So you would need to contact MS support for the hotfix -Ross -----Original Message----- From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Russ Allbery Sent: Wednesday, January 07, 2009 10:45 AM To: Michael Engemann Cc: kerberos at mit.edu Subject: Re: computer account change password with Windows 2008 domain Michael Engemann writes: > we are also experiencing the bug in Windows Server 2008 that was > mentionend on this list in April 2008 by Russ Allberry: > > * Microsoft broke password changes via the LDAP protocol with SASL GSSAPI > binds in Windows 2008. In Windows 2003, provided that you didn't try to > negotiate an SASL privacy layer, you could connect via TLS and > authenticate with GSSAPI and query or set the password attribute > directly. In Windows 2008, this no longer works; you always get the > error from the server that you are not permitted to negotiate a privacy > layer when using TLS, even though you're not trying to. We've already > filed this as a bug. > > Are there probably any news about a fix or a known workaround? The workaround is to use the password change protocol instead of using LDAP. That's what we modified our code to do, since so far as I know Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI privacy layers in their LDAP implementation is oddly broken in ways that are apparently difficult to fix, leading the server to think that you've always negotiated a privacy layer even if you haven't. At least that's my understanding of the problem.) -- Russ Allbery (rra at stanford.edu) ________________________________________________ Kerberos mailing list Kerberos at mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos From ioplex at gmail.com Wed Jan 7 14:45:38 2009 From: ioplex at gmail.com (Michael B Allen) Date: Wed, 7 Jan 2009 14:45:38 -0500 Subject: computer account change password with Windows 2008 domain In-Reply-To: <87wsd73qgm.fsf@windlord.stanford.edu> References: <87wsd73qgm.fsf@windlord.stanford.edu> Message-ID: <78c6bd860901071145t5d4f2c2xec80cbd9560f5c29@mail.gmail.com> On Wed, Jan 7, 2009 at 1:45 PM, Russ Allbery wrote: > Michael Engemann writes: > >> we are also experiencing the bug in Windows Server 2008 that was >> mentionend on this list in April 2008 by Russ Allberry: >> >> * Microsoft broke password changes via the LDAP protocol with SASL GSSAPI >> binds in Windows 2008. In Windows 2003, provided that you didn't try to >> negotiate an SASL privacy layer, you could connect via TLS and >> authenticate with GSSAPI and query or set the password attribute >> directly. In Windows 2008, this no longer works; you always get the >> error from the server that you are not permitted to negotiate a privacy >> layer when using TLS, even though you're not trying to. We've already >> filed this as a bug. >> >> Are there probably any news about a fix or a known workaround? > > The workaround is to use the password change protocol instead of using > LDAP. That's what we modified our code to do, since so far as I know > Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI > privacy layers in their LDAP implementation is oddly broken in ways that > are apparently difficult to fix, leading the server to think that you've > always negotiated a privacy layer even if you haven't. At least that's > my understanding of the problem.) Russ, Do you know if works when SASL confidentiality is used instead of TLS? Is there any method that works at all? I'm sure a lot of people would like know exactly what privacy establishment methods allow you to set unicodePwd over LDAP. Fortunately our product has always used the KPASSWD protocol for password setting, password changing and generating keytabs but I had also planned to offer LDAP password setting as an option. Hopefully there are other methods that work without TLS (TLS is kind of a pain anyway). Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ From rra at stanford.edu Wed Jan 7 15:03:32 2009 From: rra at stanford.edu (Russ Allbery) Date: Wed, 07 Jan 2009 12:03:32 -0800 Subject: computer account change password with Windows 2008 domain In-Reply-To: <78c6bd860901071145t5d4f2c2xec80cbd9560f5c29@mail.gmail.com> (Michael B. Allen's message of "Wed\, 7 Jan 2009 14\:45\:38 -0500") References: <87wsd73qgm.fsf@windlord.stanford.edu> <78c6bd860901071145t5d4f2c2xec80cbd9560f5c29@mail.gmail.com> Message-ID: <87priyyjcb.fsf@windlord.stanford.edu> "Michael B Allen" writes: > Do you know if works when SASL confidentiality is used instead of TLS? It does not. Microsoft's LDAP implementation requires TLS in order to view or change the password attribute. I don't know of any technical reason why SASL confidentiality wouldn't be sufficient (provided the negotiated strength were high enough), but their implementation doesn't appear to support this. > Is there any method that works at all? > I'm sure a lot of people would like know exactly what privacy > establishment methods allow you to set unicodePwd over LDAP. Under Windows 2008, so far as I can determine, the only supported way to set unicodePwd over LDAP is to use password binds with TLS. I don't believe this is intentional -- Microsoft acknowledges that it's a bug rather than a design intention -- but as long as the bug is present, it amounts to the same thing. -- Russ Allbery (rra at stanford.edu) From rwilper at stanford.edu Wed Jan 7 15:34:13 2009 From: rwilper at stanford.edu (Wilper, Ross A) Date: Wed, 7 Jan 2009 12:34:13 -0800 Subject: computer account change password with Windows 2008 domain In-Reply-To: <87priyyjcb.fsf@windlord.stanford.edu> References: <87wsd73qgm.fsf@windlord.stanford.edu><78c6bd860901071145t5d4f2c2xec80cbd9560f5c29@mail.gmail.com> <87priyyjcb.fsf@windlord.stanford.edu> Message-ID: I'll jump in again and state that Windows 2000 did not support setting unicodePwd using anything other than LDAPS, but Windows 2003 and 2008 do support using SASL with "auth-conf" (SASL confidentiality is now the default mechanism in the ADSI libraries) The MS documents are fairly confusing, but I have code that sets password using ADSI on port 389 after setting Kerberos encryption. password and unicodePwd cannot be viewed and I think that after Windows 2000, password cannot be set (only unicodePwd) Again, there are bugs in auth-conf and service principal binds (UPN with a "/") in Windows 2008 that require hotfixes and only the latter hotfix is public. (My plane is boarding now, gotta run) -Ross -----Original Message----- From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Russ Allbery Sent: Wednesday, January 07, 2009 12:04 PM To: Michael B Allen Cc: kerberos at mit.edu Subject: Re: computer account change password with Windows 2008 domain "Michael B Allen" writes: > Do you know if works when SASL confidentiality is used instead of TLS? It does not. Microsoft's LDAP implementation requires TLS in order to view or change the password attribute. I don't know of any technical reason why SASL confidentiality wouldn't be sufficient (provided the negotiated strength were high enough), but their implementation doesn't appear to support this. > Is there any method that works at all? > I'm sure a lot of people would like know exactly what privacy > establishment methods allow you to set unicodePwd over LDAP. Under Windows 2008, so far as I can determine, the only supported way to set unicodePwd over LDAP is to use password binds with TLS. I don't believe this is intentional -- Microsoft acknowledges that it's a bug rather than a design intention -- but as long as the bug is present, it amounts to the same thing. -- Russ Allbery (rra at stanford.edu) ________________________________________________ Kerberos mailing list Kerberos at mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos From sbuckley at MIT.EDU Wed Jan 7 16:22:48 2009 From: sbuckley at MIT.EDU (Stephen C. Buckley) Date: Wed, 7 Jan 2009 16:22:48 -0500 Subject: Kerberos Interoperability Testing Event, March 30-April 3, 2009 Message-ID: <071B8867-08BD-491E-BB17-FE9F7A6356B9@mit.edu> Friends, The MIT Kerberos Consortium will hold its first Interoperability Testing event March 30th - April 3rd, 2009. This event will be hosted by Microsoft Corporation on their Campus in Redmond, Washington. MIT is organizing this interoperability event to provide a neutral environment for software companies and other organizations to test their Kerberos implementations and Kerberized applications. We expect a lively and productive week where engineers from participating organizations can succeed in testing and debugging their code together. This event is open to all. Sponsors of the MIT Kerberos Consortium may attend this event at no cost. Other organizations who wish to participate will pay a fee to support this work. The amount of this fee will be determined individually, based on the complexity of the testing required, the size of the organization, and the number of attendees representing them. The design of this event will be largely determined by who plans to attend, and what their testing needs will be. Therefore, we ask that you send us an indication of interest in participation as soon as possible, and a detailed testing proposal no later than January 30th, 2009. This testing proposal should ideally include: - software you would like to test, - any issues you have encountered with interoperability, - platforms against which you would like test, - specific Kerberos features you would like to test, - any unique configuration(s) that you require for testing, - Access to external Internet and network/firewall requirements, - Possible number of attendees from your organization, To indicate your interest in attending or to submit your proposal, please contact Thomas Hardjono, Strategic Advisor to the MIT Kerberos Consortium, at hardjono at MIT.EDU. Thanks and hope to see you in Redmond this Spring. s _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Stephen C. Buckley Executive Director MIT Kerberos Consortium Massachusetts Institute of Technology http://www.kerberos.org From rra at stanford.edu Thu Jan 8 00:12:44 2009 From: rra at stanford.edu (Russ Allbery) Date: Wed, 07 Jan 2009 21:12:44 -0800 Subject: kadmin-remctl 2.3 released Message-ID: <877i56peib.fsf@windlord.stanford.edu> I'm pleased to announce release 2.3 of kadmin-remctl. kadmin-remctl provides a remctl backend that implements basic Kerberos account administration functions (create, delete, enable, disable, reset password, examine) plus user password changes and a call to strength-check a given password. It can also provide similar management of instances and creation, deletion, and management of accounts in MIT Kerberos, Active Directory, and an AFS kaserver where appropriate. Also included is a client for privileged users to use for password resets. Many of the defaults and namespace checks are Stanford-specific, but it can be modified for other sites. Changes from previous release: Properly add support for examining principals with instances we don't manage. Previous versions were supposed to support this but didn't due to a bug in argument passing. Improve the conversion of Kerberos v5 principal names to Kerberos v4 principal names for examine against an AFS kaserver, although it's still not as good as calling the Kerberos library routine would be. Attempt to determine if the library directory for remctl (and the directory for Kerberos and GSS-API libraries if krb5-config isn't found) is lib32 or lib64 instead of lib and set LDFLAGS accordingly. Based on an idea from the CMU Autoconf macros. Add --with-remctl-include, --with-remctl-lib, --with-gssapi-include, --with-gssapi-lib, --with-krb5-include, and --with-krb5-lib configure options to allow more specific setting of paths if necessary. Check at configure time that we can link with the remctl library we found. You can download it from: This package is maintained using Git; see the instructions on the above page to access the Git repository. Please let me know of any problems or feature requests not already listed in the TODO file. -- Russ Allbery (rra at stanford.edu) From pedro.cavalcante at fucapi.br Thu Jan 8 15:44:44 2009 From: pedro.cavalcante at fucapi.br (Pedro Cavalcante) Date: Thu, 08 Jan 2009 16:44:44 -0400 Subject: Cross Compile krb5 Message-ID: <1231447484.4098.7.camel@localhost> Hi everybody I'm trying to cross compile krb5 ?for sh4 (STLinux) and i stopped in this problem: "Cannot test for constructor/destructor support when cross compiling". My question is: Can I cross compile krb5 for any plataform? Could you share with me the solution? Thanks a lot. Pedro Cavalcante. From raeburn at MIT.EDU Thu Jan 8 18:47:37 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 8 Jan 2009 18:47:37 -0500 Subject: Cross Compile krb5 In-Reply-To: <1231447484.4098.7.camel@localhost> References: <1231447484.4098.7.camel@localhost> Message-ID: On Jan 8, 2009, at 15:44, Pedro Cavalcante wrote: > Hi everybody > > I'm trying to cross compile krb5 for sh4 (STLinux) and i stopped in > this problem: "Cannot test for constructor/destructor support when > cross > compiling". My question is: Can I cross compile krb5 for any > plataform? > Could you share with me the solution? It's not trivial, as you've noticed, but I think it should be possible. You may have to spent a little time working on some of the makefile rules, and setting a few configuration variables before starting. The autoconf-generated configure scripts generally have the ability to cache configuration information learned from the environment, to speed up later invocations. The file "config.cache" will be generated after a successful invocation, so you can look at the sort of stuff that goes in there if you do a native build on some system. In this case, the variable krb5_cv_attr_constructor_destructor is set to "yes" if you're using a compilation environment that supports "__attribute__((constructor))" to indicate functions that should be run at startup or library load time and "__attribute__((destructor))" for cleanup functions; generally that equates to whether you're using GCC, but not always. If you set it to "no", you may have to add support in config/shlib.conf and include/k5-platform.h to support the target, and it's a bit convoluted... Ken From mathew_rowley at cable.comcast.com Fri Jan 9 16:43:47 2009 From: mathew_rowley at cable.comcast.com (Mathew Rowley) Date: Fri, 09 Jan 2009 14:43:47 -0700 Subject: unable to decode stored principal key data (ASN.1 encoding ended unexpectedly) Message-ID: I have an MIT kerberos running with an OpenLDAP backend. There was a power outage last weekend, and today have noticed that I cannot kinit. The error I am receiving is: [root at krb01 openldap]# kinit mrowley kinit(v5): Generic error (see e-text) while getting initial credentials krb5kdc.log: Jan 09 16:38:43 krb01.security.lab.comcast.com krb5kdc[15758](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 10.252.152.73: LOOKING_UP_CLIENT: mrowley at KRB.COMCAST.COM for krbtgt/KRB.COMCAST.COM at KRB.COMCAST.COM, unable to decode stored principal key data (ASN.1 encoding ended unexpectedly) This is when trying to kinit on the kerberos server. This error occurs with any principal. The LDAP backend is working correctly, but can not be sure if any of the kerberos data has been corrupt. Has anyone seen this before, or have a way of fixing? If the error is in the ldap backend, I cannot simple slapcat the data out, then re-import because the corrupt data will still be there. The only thing I can think of is that the error is in one of the keytab files. Thanks for any help. When kinit, this is strace output of the server: Process 15758 attached - interrupt to quit select(22, [10 11 12 13 14 15 16 17 18 19 20 21], [], [], NULL) = 1 (in [13]) recvfrom(13, "j\201\3010\201\276\241\3\2\1\5\242\3\2\1\n\244\201\2610\201\256\240\7\3\5\0 \0\0\0\20\241"..., 4096, 0, {sa_family=AF_INET, sin_port=htons(32810), sin_addr=inet_addr("10.252.152.73")}, [16]) = 196 time(NULL) = 1231522663 time(NULL) = 1231522663 gettimeofday({1231522663, 432784}, NULL) = 0 time(NULL) = 1231522663 write(8, "0\202\0022\2\1\5c\202\2+\4\33o=comcast,dc=comcas"..., 566) = 566 time(NULL) = 1231522663 poll([{fd=8, events=POLLIN|POLLPRI|POLLERR|POLLHUP, revents=POLLIN}], 1, 300000) = 1 read(8, "0\202\1\225\2\1\5d", 8) = 8 read(8, "\202\1\216\4gkrbPrincipalName=mrowley at IP"..., 401) = 401 time(NULL) = 1231522663 poll([{fd=8, events=POLLIN|POLLPRI|POLLERR|POLLHUP, revents=POLLIN}], 1, 300000) = 1 read(8, "0\f\2\1\5e\7\n", 8) = 8 read(8, "\1\0\4\0\4\0", 6) = 6 time(NULL) = 1231522663 time(NULL) = 1231522663 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 write(3, "Jan 09 12:37:43 ipa01.security.l"..., 304) = 304 gettimeofday({1231522663, 435842}, NULL) = 0 time(NULL) = 1231522663 time(NULL) = 1231522663 sendto(13, "~\201\2670\201\264\240\3\2\1\5\241\3\2\1\36\242\21\30\017200901091737"..., 186, 0, {sa_family=AF_INET, sin_port=htons(32810), sin_addr=inet_addr("10.252.152.73")}, 16) = 186 gettimeofday({1231522663, 436423}, NULL) = 0 select(22, [10 11 12 13 14 15 16 17 18 19 20 21], [], [], NULL -- MAT From fkoop at fkoop.de Sat Jan 10 14:46:03 2009 From: fkoop at fkoop.de (Felix Koop) Date: Sat, 10 Jan 2009 20:46:03 +0100 Subject: kerberos log messages Message-ID: <1231616763.6189.1.camel@sabine.fkoop.de> Hi kerberos gurus, I have set up a kerberos server in a small environment. Now I am seeing several kind of log messages and I don't know if I should be concerned: AS_REQ (7 etypes {18 17 16 23 1 3 2}) : ISSUE: authtime 1231456921, etypes {rep=18 tkt=16 ses=16}, @ for krbtgt/@ TGS_REQ (1 etypes {1}) : ISSUE: authtime 1231486439, etypes {rep=16 tkt=1 ses=1}, @ for TGS_REQ (7 etypes {18 17 16 23 1 3 2}) : ISSUE: authtime 1231534749, etypes {rep=16 tkt=18 ses=18}, @ for host/@ Could someone please explain what these mean and if they are important? If there is any documentation that I should read, I would be grateful for a pointer. Thanks. -- Mit freundlichen Gr??en Felix Koop From mathew_rowley at cable.comcast.com Mon Jan 12 15:19:35 2009 From: mathew_rowley at cable.comcast.com (Mathew Rowley) Date: Mon, 12 Jan 2009 13:19:35 -0700 Subject: Kerberos Admin API? Message-ID: Is there any admin API (hopefully in java) out there? I want to build a web based interface to create/delete principals. Thanks. -- MAT From raeburn at MIT.EDU Mon Jan 12 15:49:44 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 12 Jan 2009 15:49:44 -0500 Subject: Cross Compile krb5 In-Reply-To: References: <1231447484.4098.7.camel@localhost> Message-ID: On Jan 8, 2009, at 18:47, Ken Raeburn wrote: > The autoconf-generated configure scripts generally have the ability > to cache configuration information learned from the environment, to > speed up later invocations. The file "config.cache" will be > generated after a successful invocation, so you can look at the sort > of stuff that goes in there if you do a native build on some system. Ah, and what I forgot to say here is that you can set these in the environment before running "configure" for your cross compilation, so that tests that can't be run for cross-compilation environments can have answers pre-set. I think you can also set the values in $prefix/share/config.site or $prefix/etc/config.site before running configure, too; they'll take effect for any autoconf-based configure script you run with the given installation prefix. Ken From tdanderberg at gmail.com Mon Jan 12 18:23:10 2009 From: tdanderberg at gmail.com (Tom Anderberg) Date: Mon, 12 Jan 2009 15:23:10 -0800 Subject: gss_display_status Message-ID: Hi all, I work on a security library that provides access to Kerberos through GSS-API. We are trying to log Kerberos errors using gss_display_status. We have noticed that the same error code can, at different times, produce either a helpful or an unhelpful error message. Sometimes this seems to depend on the Kerberos operations that have been performed. For example: Call gss_display_status with 0x96c73a22 and get "Unknown code krb5 34" Then call gss_acquire_cred (doesn't matter if it succeeds or fails) Repeat the initial call to gss_display_status and get "Request is a replay" However, there are platforms (such as Linux) where we always just get "Unknown code". Is there something that we need to do to initialize Kerberos before calling gss_display_status? Or is there some other explanation? Thanks, Tom From mikef at berkeley.edu Mon Jan 12 19:38:53 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Mon, 12 Jan 2009 16:38:53 -0800 (PST) Subject: AS_REQ Return code 60 for principal expired? In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 19 Dec 2008 at 14:35 (-0500), Tom Yu wrote: > Mike Friedman writes: > >> I've been doing some testing of my programs that use the MIT API >> against a KDC running 1.6.1 on a Linux system. On all prior systems >> where I've run a KDC, and according to the Kerberos docs, a principal >> expired condition should set a return code of 1. But on this test >> system, it seems I'm getting back a 60, which the docs define as a >> 'generic error'. > > I am unable to reproduce this condition. Is the krb5-1.6.1 KDC possibly > built using the --with-vague-errors option? Tom, Sorry for the delayed reply; I was on vacation for 3 weeks during the holiday period. I just ran a simple test, with my perl program that uses the MIT API for authentication. The results are very simple: 1. If the principal has not expired, authentication succeeds. 2. If the principal has expired, I get this error message from the KDC, specifically when I'm doing a krb5_mk_req: Generic error (see e-text) and a return code of 60. In the KDC log, for a failure, I see the following: In response to the AS_REQ: CLIENT EXPIRED: mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU, Client's entry in database has expired From the krb5_mk_req attempt: PROCESS_TGS: authtime 0, for krbproxy/oldsage.berkeley.edu at BERKELEY.EDU, No matching key in entry Yet, if the principal is not expired, I get this: In response to the AS_REQ: ISSUE: authtime 1231806450, etypes {rep=1 tkt=18 ses=1}, mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU Followed by, ISSUE: authtime 1231806450, etypes {rep=1 tkt=18 ses=1}, mikef at BERKELEY.EDU for krbproxy/oldsage.berkeley.edu at BERKELEY.EDU i.e., success, which seems to imply that my service keytab is set up OK. Unfortunately, this KDC was installed using a RedHat Linux pre-compiled RPM binary of MIT krb5-1.6.1, by someone other than me, so I can't answer your question about the '--with-vague-errors' option (which I had never heard of). Any ideas? Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklr4p0ACgkQFgKSfLOvZ1Qf+QCdGwedutT07DtCAj8L5j8XCh/Y ptMAn2o3L2IukGvda9m+hgHgzjn6YJ7/ =4yFG -----END PGP SIGNATURE----- From engemam at uni-muenster.de Tue Jan 13 11:46:21 2009 From: engemam at uni-muenster.de (Michael Engemann) Date: Tue, 13 Jan 2009 17:46:21 +0100 Subject: AW: computer account change password with Windows 2008 domain In-Reply-To: References: <87wsd73qgm.fsf@windlord.stanford.edu> Message-ID: Hi Ross, thank you very much for the information about the hotfix. May I ask if you have experienced any issues since applying the hotfix on your production servers? I ask because I wonder why this hotfix hasn't been released publicly yet. Thanks, Michael > -----Urspr?ngliche Nachricht----- > Von: Wilper, Ross A [mailto:rwilper at stanford.edu] > Gesendet: Mittwoch, 7. Januar 2009 20:29 > An: Russ Allbery; Michael Engemann > Cc: kerberos at mit.edu > Betreff: RE: computer account change password with Windows 2008 domain > > The QoP negotiation issue is fixed by the hotfix with KB article > 957072. > This has been applied to our systems, but as of yet, I have not seen > that this hotfix has been released publicly. So you would need to > contact MS support for the hotfix > > -Ross > > > -----Original Message----- > From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On > Behalf Of Russ Allbery > Sent: Wednesday, January 07, 2009 10:45 AM > To: Michael Engemann > Cc: kerberos at mit.edu > Subject: Re: computer account change password with Windows 2008 domain > > Michael Engemann writes: > > > we are also experiencing the bug in Windows Server 2008 that was > > mentionend on this list in April 2008 by Russ Allberry: > > > > * Microsoft broke password changes via the LDAP protocol with SASL > GSSAPI > > binds in Windows 2008. In Windows 2003, provided that you didn't > try to > > negotiate an SASL privacy layer, you could connect via TLS and > > authenticate with GSSAPI and query or set the password attribute > > directly. In Windows 2008, this no longer works; you always get > the > > error from the server that you are not permitted to negotiate a > privacy > > layer when using TLS, even though you're not trying to. We've > already > > filed this as a bug. > > > > Are there probably any news about a fix or a known workaround? > > The workaround is to use the password change protocol instead of using > LDAP. That's what we modified our code to do, since so far as I know > Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI > privacy layers in their LDAP implementation is oddly broken in ways > that > are apparently difficult to fix, leading the server to think that > you've > always negotiated a privacy layer even if you haven't. At least that's > my understanding of the problem.) > > -- > Russ Allbery (rra at stanford.edu) > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos From rwilper at stanford.edu Tue Jan 13 12:03:10 2009 From: rwilper at stanford.edu (Wilper, Ross A) Date: Tue, 13 Jan 2009 09:03:10 -0800 Subject: computer account change password with Windows 2008 domain In-Reply-To: References: <87wsd73qgm.fsf@windlord.stanford.edu> Message-ID: This hotfix is installed on 4 of our 5 forests and have not seen any issues with it. I will note that our production authentication forest is the one that it is not on since we have been delayed deploying Windows 2008 there. On the other hand, we put infrastructure and client development servers into our UAT forest which does have this patch - so we do have Exchange, Outlook, and many 3rd-party + home grown apps on both Windows and Unix hitting a patched environment. >From the chatter I heard during the case, they had to make some deep changes in LDAP to fix the behavior, but I am also surprised that the patch has still not gone public. I have been poking a bit. I just checked the patch list for Service Pack 2 and I do not see it listed there either. -Ross -----Original Message----- From: Michael Engemann [mailto:engemam at uni-muenster.de] Sent: Tuesday, January 13, 2009 8:46 AM To: Wilper, Ross A; Russ Allbery; Michael Engemann Cc: kerberos at mit.edu Subject: AW: computer account change password with Windows 2008 domain Hi Ross, thank you very much for the information about the hotfix. May I ask if you have experienced any issues since applying the hotfix on your production servers? I ask because I wonder why this hotfix hasn't been released publicly yet. Thanks, Michael > -----Urspr?ngliche Nachricht----- > Von: Wilper, Ross A [mailto:rwilper at stanford.edu] > Gesendet: Mittwoch, 7. Januar 2009 20:29 > An: Russ Allbery; Michael Engemann > Cc: kerberos at mit.edu > Betreff: RE: computer account change password with Windows 2008 domain > > The QoP negotiation issue is fixed by the hotfix with KB article > 957072. > This has been applied to our systems, but as of yet, I have not seen > that this hotfix has been released publicly. So you would need to > contact MS support for the hotfix > > -Ross > > > -----Original Message----- > From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On > Behalf Of Russ Allbery > Sent: Wednesday, January 07, 2009 10:45 AM > To: Michael Engemann > Cc: kerberos at mit.edu > Subject: Re: computer account change password with Windows 2008 domain > > Michael Engemann writes: > > > we are also experiencing the bug in Windows Server 2008 that was > > mentionend on this list in April 2008 by Russ Allberry: > > > > * Microsoft broke password changes via the LDAP protocol with SASL > GSSAPI > > binds in Windows 2008. In Windows 2003, provided that you didn't > try to > > negotiate an SASL privacy layer, you could connect via TLS and > > authenticate with GSSAPI and query or set the password attribute > > directly. In Windows 2008, this no longer works; you always get > the > > error from the server that you are not permitted to negotiate a > privacy > > layer when using TLS, even though you're not trying to. We've > already > > filed this as a bug. > > > > Are there probably any news about a fix or a known workaround? > > The workaround is to use the password change protocol instead of using > LDAP. That's what we modified our code to do, since so far as I know > Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI > privacy layers in their LDAP implementation is oddly broken in ways > that > are apparently difficult to fix, leading the server to think that > you've > always negotiated a privacy layer even if you haven't. At least that's > my understanding of the problem.) > > -- > Russ Allbery (rra at stanford.edu) > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos From mikef at berkeley.edu Tue Jan 13 13:16:55 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Tue, 13 Jan 2009 10:16:55 -0800 (PST) Subject: krb5-1.6.1 problems (on RedHat) (was: AS_REQ Return code 60 for principal expired?) In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now I'm having another problem with my 1.6.1 (RedHat Linux) test KDC. It seems that if I set the REQUIRES_PWCHANGE attribute for a principal and try to authenticate with an invalid password, I get back a return code of 31 ('decrypt integrity check failed'), instead of a 23 (password expired). The KDC log actually shows 'REQUIRED PWCHANGE' in the reply to the AS_REQ, yet I'm still getting a return code of 31! (My code depends on the RC=23 to verify that the REQUIRES_PWCHANGE attribute is, in fact, set. This code has been running successfully for years on earlier KDC versions, 1.4.2 currently, though not on Linux systems). I should also mention that during the period of my testing, the following messages are scattered through the KDC logs: o Authentication attempt failed: , GSS-API error strings are: o Unspecified GSS failure. Minor code may provide more information o Unknown code kdb5 27 o GSS-API error strings complete. (Note that the first message does not end with any GSS-API error strings, so I assume they are null values). It's hard for me to correlate each of the above messages with the specific actions I'm taking. But for the most part all I'm doing is authentication, which involves an AS_REQ, followed by a TGS_REQ using a special host service principal set up for this purpose. Just as with my other problem (see below), this doesn't happen on my production 1.4.2 system, using the same API code. I suppose that in both cases I could be doing something wrong when I point to the 1.6.1 system instead of the 1.4.2 (production) KDC. But since things work correctly on the former EXCEPT under the two conditions I've described thus far (expired principal and principal with REQUIRED_PASSPHRASE set), I'm suspicious that there's something amiss with the 1.6.1 system. It may be a problem with how that KDC is configured, which is why I'm posting this, to get some ideas of what to look for. Thanks. Mike ==================================================================== On Mon, 12 Jan 2009 at 16:38 (-0800), Mike Friedman wrote: > On Fri, 19 Dec 2008 at 14:35 (-0500), Tom Yu wrote: > >> Mike Friedman writes: >> >>> I've been doing some testing of my programs that use the MIT API >>> against a KDC running 1.6.1 on a Linux system. On all prior systems >>> where I've run a KDC, and according to the Kerberos docs, a principal >>> expired condition should set a return code of 1. But on this test >>> system, it seems I'm getting back a 60, which the docs define as a >>> 'generic error'. >> >> I am unable to reproduce this condition. Is the krb5-1.6.1 KDC >> possibly built using the --with-vague-errors option? > > Tom, > > Sorry for the delayed reply; I was on vacation for 3 weeks during the > holiday period. > > I just ran a simple test, with my perl program that uses the MIT API for > authentication. The results are very simple: > > 1. If the principal has not expired, authentication succeeds. > > 2. If the principal has expired, I get this error message from the KDC, > specifically when I'm doing a krb5_mk_req: > > Generic error (see e-text) > > and a return code of 60. > > In the KDC log, for a failure, I see the following: > > In response to the AS_REQ: > CLIENT EXPIRED: mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU, Client's entry in database has expired > > From the krb5_mk_req attempt: > PROCESS_TGS: authtime 0, for krbproxy/oldsage.berkeley.edu at BERKELEY.EDU, No matching key in entry > > Yet, if the principal is not expired, I get this: > > In response to the AS_REQ: > ISSUE: authtime 1231806450, etypes {rep=1 tkt=18 ses=1}, mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU > > Followed by, > ISSUE: authtime 1231806450, etypes {rep=1 tkt=18 ses=1}, mikef at BERKELEY.EDU for krbproxy/oldsage.berkeley.edu at BERKELEY.EDU > > i.e., success, which seems to imply that my service keytab is set up OK. > > Unfortunately, this KDC was installed using a RedHat Linux pre-compiled > RPM binary of MIT krb5-1.6.1, by someone other than me, so I can't > answer your question about the '--with-vague-errors' option (which I had > never heard of). > > Any ideas? > > Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkls2pcACgkQFgKSfLOvZ1TFAgCeIgFQ9QnTjLGYTe4AtpbEgsb6 FVAAnReDAdykAAruvqDoscb7KiBz3Ze+ =R0Bf -----END PGP SIGNATURE----- From kenh at cmf.nrl.navy.mil Tue Jan 13 13:29:21 2009 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Tue, 13 Jan 2009 13:29:21 -0500 Subject: krb5-1.6.1 problems (on RedHat) (was: AS_REQ Return code 60 for principal expired?) In-Reply-To: Message-ID: <200901131829.n0DITMr7025546@hedwig.cmf.nrl.navy.mil> >Now I'm having another problem with my 1.6.1 (RedHat Linux) test KDC. It >seems that if I set the REQUIRES_PWCHANGE attribute for a principal and >try to authenticate with an invalid password, I get back a return code of >31 ('decrypt integrity check failed'), instead of a 23 (password expired). >The KDC log actually shows 'REQUIRED PWCHANGE' in the reply to the AS_REQ, >yet I'm still getting a return code of 31! > >(My code depends on the RC=23 to verify that the REQUIRES_PWCHANGE >attribute is, in fact, set. This code has been running successfully for >years on earlier KDC versions, 1.4.2 currently, though not on Linux >systems). Dude, May I humbly suggest that maybe, just maybe, for something like you KDC you NOT rely on some pre-compiled binary compiled by god-knows-who with god-knows-what options? Judging by what you're posting, something seems to be majorly wrong here ... at least with error reporting. (And at the very least, you could always compile with debugging turned on to try to track down the problem). --Ken From mikef at berkeley.edu Tue Jan 13 13:38:48 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Tue, 13 Jan 2009 10:38:48 -0800 (PST) Subject: krb5-1.6.1 problems (on RedHat) (was: AS_REQ Return code 60 for principal expired?) In-Reply-To: <200901131829.n0DITMr7025546@hedwig.cmf.nrl.navy.mil> References: <200901131829.n0DITMr7025546@hedwig.cmf.nrl.navy.mil> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 13 Jan 2009 at 13:29 (-0500), Ken Hornstein wrote: > May I humbly suggest that maybe, just maybe, for something like you KDC > you NOT rely on some pre-compiled binary compiled by god-knows-who with > god-knows-what options? Judging by what you're posting, something seems > to be majorly wrong here ... at least with error reporting. > > (And at the very least, you could always compile with debugging turned > on to try to track down the problem). Ken, I couldn't agree more! In fact, I made this point yesterday at a meeting where the person who installed this KDC was present. I was emphatic that I would never run a production KDC like this, especially since over the years I've found it necessary either to modify the compile time configuration, or, more commonly, to troubleshoot problems like this. But, in fairness, this was intended to be a test KDC with very limited use and it has been working thus far, used by just one of my colleagues to test his applications that do basic admin functions, where the aforementioned problems have not arisen. I think I may have to do my current testing elsewhere, rather than trying to get this KDC functioning properly. Thanks. Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkls37gACgkQFgKSfLOvZ1QjugCbBhVMIuSayZKM1ie88a4C5qNz 2RoAni7KN0Lq78veaN7ol7JvQrNBMcNX =bLrU -----END PGP SIGNATURE----- From rra at stanford.edu Tue Jan 13 13:40:13 2009 From: rra at stanford.edu (Russ Allbery) Date: Tue, 13 Jan 2009 10:40:13 -0800 Subject: krb5-1.6.1 problems (on RedHat) In-Reply-To: (Mike Friedman's message of "Tue\, 13 Jan 2009 10\:16\:55 -0800 \(PST\)") References: Message-ID: <87r6379hiq.fsf@windlord.stanford.edu> Mike Friedman writes: > Now I'm having another problem with my 1.6.1 (RedHat Linux) test KDC. > It seems that if I set the REQUIRES_PWCHANGE attribute for a principal > and try to authenticate with an invalid password, I get back a return > code of 31 ('decrypt integrity check failed'), instead of a 23 (password > expired). Hm, that seems like correct behavior to me in the presence of preauth. Otherwise, you're leaking state about the account to a possible attacker. > (My code depends on the RC=23 to verify that the REQUIRES_PWCHANGE > attribute is, in fact, set. This code has been running successfully for > years on earlier KDC versions, 1.4.2 currently, though not on Linux > systems). Wouldn't it be better to provide your code with an interface where it can query that attribute directly instead of using the return code from a failed authentication? -- Russ Allbery (rra at stanford.edu) From raeburn at MIT.EDU Tue Jan 13 15:27:39 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 13 Jan 2009 15:27:39 -0500 Subject: krb5-1.6.1 problems (on RedHat) (was: AS_REQ Return code 60 for principal expired?) In-Reply-To: References: Message-ID: <8EB5F6F9-31B7-4FF9-B5DF-E2F5B2AFB92C@mit.edu> Still skimming messages in the thread today, but: On Jan 13, 2009, at 13:16, Mike Friedman wrote: > I should also mention that during the period of my testing, the > following > messages are scattered through the KDC logs: > > o Authentication attempt failed: , GSS-API > error strings are: > o Unspecified GSS failure. Minor code may provide more > information > o Unknown code kdb5 27 > o GSS-API error strings complete. > > (Note that the first message does not end with any GSS-API error > strings, > so I assume they are null values). Actually, the strings in between the "error strings are" and "error strings complete" messages *are* the major- and minor-code status messages. (Typically we get one of each, but the API is such that either or both could provide multiple strings, and they could each span multiple lines, hence no attempt to stick everything onto one line.) It probably would be a little more clear (though not really any more informative) if we added a prefix to those lines... Ken From john at iastate.edu Wed Jan 14 15:22:34 2009 From: john at iastate.edu (John Hascall) Date: Wed, 14 Jan 2009 14:22:34 CST Subject: krb5_sendauth vs NAGLE vs DelayedAck Message-ID: <31033.1231964554@malison.ait.iastate.edu> I don't recall having seen this discussed on this list and google doesn't seem to either, so... I just discovered that hard way that the way that krb5_sendauth/krb5_recvauth work tickles the nasty interaction between the TCP NAGLE and DelayedAck features which inserts two ~200ms delays into the process: 16994 accessd 1231948663.402557 CALL read(6,0xbfbffa54,4) 16994 accessd 1231948663.402561 GIO fd 6 read 4 bytes "\0\0\0\^S" 16994 accessd 1231948663.402567 CALL read(6,0xa1e0520,0x13) 16994 accessd 1231948663.592835 GIO fd 6 read 19 bytes "KRB5_SENDAUTH_V1.0\0" 16994 accessd 1231948663.592850 CALL read(6,0xbfbff914,4) 16994 accessd 1231948663.592854 GIO fd 6 read 4 bytes "\0\0\0\b" 16994 accessd 1231948663.592860 CALL read(6,0xa1e2530,8) 16994 accessd 1231948663.592863 GIO fd 6 read 8 bytes "PV 1.00\0" 16994 accessd 1231948663.592868 CALL write(6,0xbfbff99b,1) 16994 accessd 1231948663.592874 GIO fd 6 wrote 1 bytes "\0" 16994 accessd 1231948663.592879 CALL read(6,0xbfbff914,4) 16994 accessd 1231948663.593675 GIO fd 6 read 4 bytes "\0\0\^A\M^U" 16994 accessd 1231948663.593681 CALL read(6,0xa165800,0x195) 16994 accessd 1231948663.792905 GIO fd 6 read 405 bytes "...a bunch of binary goop..." This was pretty annoying when that 4/10s of a second was pretty much all of the connection lifetime. My guess is that this occurs anywhere that the kerberos libs use krb5_write_message(). My solution was just to do: int on = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)); before calling krb5_sendauth() but a "better" approach might be for krb5_write_message to end up calling writev so it does one write instead of two, I think. John From raeburn at MIT.EDU Wed Jan 14 16:52:34 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 14 Jan 2009 16:52:34 -0500 Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: <31033.1231964554@malison.ait.iastate.edu> References: <31033.1231964554@malison.ait.iastate.edu> Message-ID: <5A74721A-E127-45FE-BE81-100F1127250C@mit.edu> On Jan 14, 2009, at 15:22, John Hascall wrote: > I don't recall having seen this discussed on this > list and google doesn't seem to either, so... > > I just discovered that hard way that the way that > krb5_sendauth/krb5_recvauth work tickles the nasty > interaction between the TCP NAGLE and DelayedAck > features which inserts two ~200ms delays into the > process: Ouch. I ran into the same problem years ago with Emacs movemail's POP support. Send "DELE 123", pause, send "\r\n", wait for response... a delay per message to be deleted off the server, and if you're fetching 100 or so messages at a time, it adds up... > My guess is that this occurs anywhere that the kerberos > libs use krb5_write_message(). ...which is fortunately not too many places, but that doesn't help you today. > My solution was just to do: > int on = 1; > setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)); > before calling krb5_sendauth() but a "better" approach might > be for krb5_write_message to end up calling writev so it > does one write instead of two, I think. Yes, I think that's probably best -- maybe via a helper function to run a loop and manage the bookkeeping in case of short writes. Ken From Nicolas.Williams at sun.com Wed Jan 14 17:07:34 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 14 Jan 2009 16:07:34 -0600 Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: <5A74721A-E127-45FE-BE81-100F1127250C@mit.edu> References: <31033.1231964554@malison.ait.iastate.edu> <5A74721A-E127-45FE-BE81-100F1127250C@mit.edu> Message-ID: <20090114220734.GT884@Sun.COM> On Wed, Jan 14, 2009 at 04:52:34PM -0500, Ken Raeburn wrote: > On Jan 14, 2009, at 15:22, John Hascall wrote: > > My solution was just to do: > > int on = 1; > > setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)); > > before calling krb5_sendauth() but a "better" approach might > > be for krb5_write_message to end up calling writev so it > > does one write instead of two, I think. > > Yes, I think that's probably best -- maybe via a helper function to > run a loop and manage the bookkeeping in case of short writes. Or setsockopt() TCP_CORK around krb5_sendauth(). From john at iastate.edu Wed Jan 14 17:38:09 2009 From: john at iastate.edu (John Hascall) Date: Wed, 14 Jan 2009 16:38:09 CST Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: Your message of Wed, 14 Jan 2009 16:07:34 -0600. <20090114220734.GT884@Sun.COM> Message-ID: <31453.1231972689@malison.ait.iastate.edu> > On Wed, Jan 14, 2009 at 04:52:34PM -0500, Ken Raeburn wrote: > > On Jan 14, 2009, at 15:22, John Hascall wrote: > > > My solution was just to do: > > > int on = 1; > > > setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on)); > > > before calling krb5_sendauth() but a "better" approach might > > > be for krb5_write_message to end up calling writev so it > > > does one write instead of two, I think. > > > > Yes, I think that's probably best -- maybe via a helper function to > > run a loop and manage the bookkeeping in case of short writes. > Or setsockopt() TCP_CORK around krb5_sendauth(). I'm not sure this is portable enough yet. John From raeburn at MIT.EDU Wed Jan 14 20:06:58 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 14 Jan 2009 20:06:58 -0500 Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: <31033.1231964554@malison.ait.iastate.edu> References: <31033.1231964554@malison.ait.iastate.edu> Message-ID: I think this is fixed in the sources now, with revision 21749. If you want to try out my change, you can get the changes from http://src.mit.edu/fisheye/changelog/krb5/?cs=21749 ... um, when the fisheye server starts updating again. Or off the anonsvn server. Ken From rturner at amalfisystems.com Thu Jan 15 00:40:54 2009 From: rturner at amalfisystems.com (Randy Turner) Date: Wed, 14 Jan 2009 21:40:54 -0800 Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: References: <31033.1231964554@malison.ait.iastate.edu> Message-ID: <9A325B10-96DB-472B-B5A3-B8E6392E2581@amalfisystems.com> Hi Ken, Is this problem in the current release? I assume from so since John's original email didn't specify a release (like 1.6.1). We may be experiencing something like this occasionally... Thanks, Randy On Jan 14, 2009, at 5:06 PM, Ken Raeburn wrote: > I think this is fixed in the sources now, with revision 21749. If you > want to try out my change, you can get the changes from http://src.mit.edu/fisheye/changelog/krb5/?cs=21749 > ... um, when the fisheye server starts updating again. Or off the > anonsvn server. > > Ken > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > From aleem.akhtar at st.com Thu Jan 15 03:08:32 2009 From: aleem.akhtar at st.com (Aleem AKHTAR) Date: Thu, 15 Jan 2009 13:38:32 +0530 Subject: Suitable Kerberos Server for Packet cable ?? Message-ID: <001901c976e8$752837b0$ee1ec70a@dlh.st.com> Hi, Could I get information which kerberos server is best suited for Packet cable project specification. Is there any limitation if we use open source krb5 server published by MIT ?? Thanks, Aleem From ronniesahlberg at gmail.com Thu Jan 15 03:32:53 2009 From: ronniesahlberg at gmail.com (ronnie sahlberg) Date: Thu, 15 Jan 2009 19:32:53 +1100 Subject: Suitable Kerberos Server for Packet cable ?? In-Reply-To: <001901c976e8$752837b0$ee1ec70a@dlh.st.com> References: <001901c976e8$752837b0$ee1ec70a@dlh.st.com> Message-ID: I think there is a company called Blue-Cable or something that does these things. I doubt that either a MIT or Heimdal (or any rfc1510) server will work since packet-cable uses a non-1510 implementation of kerberos 5. Its very similar but there are subtle differences. They use either a pre-1510 draft or a forked different standard, dont know which, suspect the first. >From experience implementing both packetcable and also 1510 in wireshark we got around this by changing the ASN to make some structure fields OPTIONAL which were OPTIONAL in packet-cable but were mandatory in the official 1510. The changes I had to make was rather smallish and I did put a comment in packet-kerberos.c in wireshark to indicate these non-1510 changes. This was possible since we only unmarshall packets and never marshall them and thus sprinkling the ASN with extra OPTIONAL is harmless. There might be additional changes required if you also need to marshall data. Dont know. You take lots of shortcuts when you only unmarshall data. I think I recall also other differences (not ASN changes) that related to things like preauthentication types/blobs, enctypes, salt blobs etc etc. (Some which actually surprised me when they were resurrected in microsoft ad krb5 with the same numbers and the same meaning sometime around when w2k3 was released). Was a long time ago I did packetcable for wireshark so my memory is hazy... There was at some point a post on the wireshark mailinglist (long after i implemented the packetcable changes in ws) that linked to a full set of official specification for packetcable and in particular their krb5 implementation. This was in the days when wireshark was called ethereal. regards ronnie sahlberg On Thu, Jan 15, 2009 at 7:08 PM, Aleem AKHTAR wrote: > > Hi, > > Could I get information which kerberos server is best suited for Packet cable project specification. Is there any limitation if we use open source krb5 server published by MIT ?? >In wireshark the incompatibility issue between 1510 and packetcable is minor since we only ever unmarshall packets and never mashall them. > > Thanks, > Aleem > > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > From john at iastate.edu Thu Jan 15 09:41:09 2009 From: john at iastate.edu (John Hascall) Date: Thu, 15 Jan 2009 08:41:09 CST Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: Your message of Wed, 14 Jan 2009 20:06:58 -0500. Message-ID: <894.1232030469@malison.ait.iastate.edu> > I think this is fixed in the sources now, with revision 21749. If you > want to try out my change, you can get the changes from > http://src.mit.edu/fisheye/changelog/krb5/?cs=21749 > ... um, when the fisheye server starts updating again. Or off the > anonsvn server. > Ken Ken, I think you might want to also change krb5_sendauth() to call krb5int_net_writev() directly (or yet another helper function!) since krb5_sendauth() will still be doing two consecutive writes where it does the two version strings: outbuf.length = strlen(sendauth_version) + 1; outbuf.data = (char *) sendauth_version; if ((retval = krb5_write_message(context, fd, &outbuf))) return(retval); outbuf.length = strlen(appl_version) + 1; outbuf.data = appl_version; if ((retval = krb5_write_message(context, fd, &outbuf))) return(retval); John From lha at kth.se Thu Jan 15 13:15:30 2009 From: lha at kth.se (=?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Thu, 15 Jan 2009 10:15:30 -0800 Subject: Suitable Kerberos Server for Packet cable ?? In-Reply-To: References: <001901c976e8$752837b0$ee1ec70a@dlh.st.com> Message-ID: Older versions of heimdal did work with packet cable but since I didn't have anything to test with I broke it on purpose when code changed. Love 15 jan 2009 kl. 00.32 skrev ronnie sahlberg: > I think there is a company called Blue-Cable or something that does > these things. > > > I doubt that either a MIT or Heimdal (or any rfc1510) server will > work since packet-cable uses a non-1510 implementation of kerberos 5. > Its very similar but there are subtle differences. > They use either a pre-1510 draft or a forked different standard, dont > know which, suspect the first. > >> From experience implementing both packetcable and also 1510 in > wireshark we got around this by changing the ASN to make some > structure fields OPTIONAL which were OPTIONAL in packet-cable but were > mandatory in the official 1510. > > The changes I had to make was rather smallish and I did put a comment > in packet-kerberos.c in wireshark to indicate these non-1510 changes. > This was possible since we only unmarshall packets and never marshall > them and thus sprinkling the ASN with extra OPTIONAL is harmless. > > There might be additional changes required if you also need to > marshall data. Dont know. You take lots of shortcuts when you only > unmarshall data. > > > I think I recall also other differences (not ASN changes) that related > to things like preauthentication types/blobs, enctypes, salt blobs > etc etc. > (Some which actually surprised me when they were resurrected in > microsoft ad krb5 with the same numbers and the same meaning > sometime around when w2k3 was released). > > > Was a long time ago I did packetcable for wireshark so my memory is > hazy... > There was at some point a post on the wireshark mailinglist (long > after i implemented the packetcable changes in ws) that linked to a > full set of official specification for packetcable and in particular > their krb5 implementation. > This was in the days when wireshark was called ethereal. > > > regards > ronnie sahlberg > > > On Thu, Jan 15, 2009 at 7:08 PM, Aleem AKHTAR > wrote: >> >> Hi, >> >> Could I get information which kerberos server is best suited for >> Packet cable project specification. Is there any limitation if we >> use open source krb5 server published by MIT ?? >> In wireshark the incompatibility issue between 1510 and packetcable >> is minor since we only ever unmarshall packets and never mashall >> them. >> >> Thanks, >> Aleem >> >> >> ________________________________________________ >> Kerberos mailing list Kerberos at mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos >> > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos From raeburn at MIT.EDU Thu Jan 15 14:20:02 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 15 Jan 2009 14:20:02 -0500 Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: <894.1232030469@malison.ait.iastate.edu> References: <894.1232030469@malison.ait.iastate.edu> Message-ID: <6A7C6331-CEBB-4EE5-9A83-7DC18C92093A@MIT.EDU> On Jan 15, 2009, at 09:41, John Hascall wrote: > I think you might want to also change krb5_sendauth() to > call krb5int_net_writev() directly (or yet another helper > function!) since krb5_sendauth() will still be doing two > consecutive writes where it does the two version strings: Yeah, I missed that, thanks. I've just checked in another fix. There are also multiple calls possible in recvauth but it's not unconditionally doing two successive writes, so some rearranging of code would be needed there; the hardest bit would probably be making sure multiple paths through the code get tested. If you feel like tackling it, that'd be great, but I'm going to get back to my current project for a bit. Ken From raeburn at MIT.EDU Thu Jan 15 15:08:13 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 15 Jan 2009 15:08:13 -0500 Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: <9A325B10-96DB-472B-B5A3-B8E6392E2581@amalfisystems.com> References: <31033.1231964554@malison.ait.iastate.edu> <9A325B10-96DB-472B-B5A3-B8E6392E2581@amalfisystems.com> Message-ID: <18CE936E-5225-4BF5-AB28-CFC2F705F4FA@MIT.EDU> On Jan 15, 2009, at 00:40, Randy Turner wrote: > Hi Ken, > > Is this problem in the current release? I assume from so since > John's original email didn't specify a release (like 1.6.1). > > We may be experiencing something like this occasionally... Yes, I think it would've been in most of our releases. Ken From john at iastate.edu Thu Jan 15 15:49:31 2009 From: john at iastate.edu (John Hascall) Date: Thu, 15 Jan 2009 14:49:31 CST Subject: krb5_sendauth vs NAGLE vs DelayedAck In-Reply-To: Your message of Thu, 15 Jan 2009 14:20:02 -0500. <6A7C6331-CEBB-4EE5-9A83-7DC18C92093A@MIT.EDU> Message-ID: <1798.1232052571@malison.ait.iastate.edu> > On Jan 15, 2009, at 09:41, John Hascall wrote: > > I think you might want to also change krb5_sendauth() to > > call krb5int_net_writev() directly (or yet another helper > > function!) since krb5_sendauth() will still be doing two > > consecutive writes where it does the two version strings: > Yeah, I missed that, thanks. I've just checked in another fix. Great. > There are also multiple calls possible in recvauth but it's not > unconditionally doing two successive writes, so some rearranging of > code would be needed there; the hardest bit would probably be making > sure multiple paths through the code get tested. If you feel like > tackling it, that'd be great, but I'm going to get back to my current > project for a bit. The only place I could see where a double-write could happen was a successful mutual auth. So, here's my attempt at a minimal rewrite to handle that: http://john.public.iastate.edu/recvauth.c (basically I just made outbuf into a array[2] and some logic around calling krb5int_write_messages() with 1 or 2 entries from it). John From thomas at chaschperli.ch Fri Jan 16 04:15:33 2009 From: thomas at chaschperli.ch (Thomas Mueller) Date: Fri, 16 Jan 2009 09:15:33 +0000 (UTC) Subject: ldap backend issues Message-ID: hi i'm playing with debian lenny* and the new kerberos ldap backend. i've stumbled upon a few issues. first, the online documentation**, says to create new ACL's ending with "by * none". this disabled the access for all except the two kerberos users. after reading man slapd.access it may be better read "by * break" to let slapd evaluate the next access statements? second, i've configured the openldap like the sample krb5.conf file in chapter 3.3.11. altough i've written the kdc and adm dn the kdc-server and admin-server don't start without supplying "-x host=ldapi:// -x binddn=cn=kdc-service,dc=test". is /etc/krb5.conf the right place? don't i have to write some ldap config to /etc/krb5kdc/kdc.conf? "man kdc.conf" doesn't reveal anything about "ldap". third, is there some way to export the encrypted passwords from a non- ldap-backend and import them into the ldap-backend? Thanks for any hints. - Thomas *slapd 2.4.11, mit krb5 1.6.dfsg.4~beta1 (think this is 1.6.4 beta1) ** http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5- admin.html#Configuring-Kerberos-with-OpenLDAP-back_002dend From michael at stroeder.com Fri Jan 16 08:33:21 2009 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Fri, 16 Jan 2009 14:33:21 +0100 Subject: ldap backend issues In-Reply-To: References: Message-ID: <2ue646-ff2.ln1@nb2.stroeder.com> Thomas Mueller wrote: > first, the online documentation**, says to create new ACL's ending with > "by * none". this disabled the access for all except the two kerberos > users. after reading man slapd.access it may be better read "by * break" > to let slapd evaluate the next access statements? I'd suggest to examine ACL issues by setting an appropriate log level and clarify what you find in the logs on the openldap-software mailing list. > second, i've configured the openldap like the sample krb5.conf file in > chapter 3.3.11. altough i've written the kdc and adm dn the kdc-server > and admin-server don't start without supplying "-x host=ldapi:// -x > binddn=cn=kdc-service,dc=test". is /etc/krb5.conf the right place? don't > i have to write some ldap config to /etc/krb5kdc/kdc.conf? "man kdc.conf" > doesn't reveal anything about "ldap". I also had some problems. But you should really try to collect some Kerberos error messages and post them here. Also posting you krb5.conf and kdc.conf would help. > *slapd 2.4.11, You should use 2.4.13. Many issues have been fixed. I can't tell whether the fixes are relevant to your setup though. Ciao, Michael. From michael at stroeder.com Fri Jan 16 14:58:25 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 16 Jan 2009 20:58:25 +0100 Subject: mod_auth_kerb: gss_accept_sec_context() failed Message-ID: <2g5746-jue.ln1@nb2.stroeder.com> HI! I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly initialized. The web browser is Seamonkey and it already sends the Authorization: Negotiate YIIE0AYGKwYBBQ[..] in the HTTP request. But it does not work. I don't get authorized HTTP access. In Apache's error_log I find: gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, Decrypt integrity check failed) Any clue here? Many thanks in advance. Ciao, Michael. From phalenor at gmail.com Fri Jan 16 15:49:12 2009 From: phalenor at gmail.com (Andrew Cobaugh) Date: Fri, 16 Jan 2009 15:49:12 -0500 Subject: mod_auth_kerb: gss_accept_sec_context() failed In-Reply-To: <2g5746-jue.ln1@nb2.stroeder.com> References: <2g5746-jue.ln1@nb2.stroeder.com> Message-ID: <1b8d56200901161249q19a90e9ne7dd28c1552a8984@mail.gmail.com> On Fri, Jan 16, 2009 at 2:58 PM, Michael Str?der wrote: > HI! > > I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for > SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to > receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP > SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly > initialized. > > The web browser is Seamonkey and it already sends the > Authorization: Negotiate YIIE0AYGKwYBBQ[..] > in the HTTP request. > > But it does not work. I don't get authorized HTTP access. > In Apache's error_log I find: > gss_accept_sec_context() failed: Unspecified GSS failure. Minor > code may provide more information (, Decrypt integrity check failed) Are you sure that the keytab specified by Krb5Keytab is consistent with the HTTP service principal that is in AD? That message is the same as saying "your password is wrong." Also, if you're going to use mod_auth_kerb to do GSS, you'll need a patch so that mod_auth_kerb sets up the GSS environment correclty, so that your application will use the correct KRB5CCNAME: http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch --andy From pgp at psu.edu Mon Jan 19 14:48:13 2009 From: pgp at psu.edu (Phil Pishioneri) Date: Mon, 19 Jan 2009 14:48:13 -0500 Subject: MIT preference of returning KEY_EXP vs. NAME_EXP Message-ID: <4974D8FD.5080803@psu.edu> If both a client principal and its password have expired, is the fact that the MIT KDC prefers to return a status of KDC_ERR_KEY_EXP over KDC_ERR_NAME_EXP a deliberate choice, or just how it is? And if "how it is", would a bug (to switch the two checks around) be likely to be accepted? The code in question is in kdc/kdc_util.c, validate_as_request(), approx. line 907 on the trunk: /* The client's password must not be expired, unless the server is a KRB5_KDC_PWCHANGE_SERVICE. */ if (client.pw_expiration&& client.pw_expiration< kdc_time&& !isflagset(server.attributes, KRB5_KDB_PWCHANGE_SERVICE)) { *status = "CLIENT KEY EXPIRED"; #ifdef KRBCONF_VAGUE_ERRORS return(KRB_ERR_GENERIC); #else return(KDC_ERR_KEY_EXP); #endif } /* The client must not be expired */ if (client.expiration&& client.expiration< kdc_time) { *status = "CLIENT EXPIRED"; #ifdef KRBCONF_VAGUE_ERRORS return(KRB_ERR_GENERIC); #else return(KDC_ERR_NAME_EXP); #endif } Heimdal appears to prefer NAME_EXP; don't know how other KDCs act. -Phil (Asked on kerberos instead of krbdev since it could be a policy question.) From thomas at chaschperli.ch Mon Jan 19 14:52:33 2009 From: thomas at chaschperli.ch (Thomas Mueller) Date: Mon, 19 Jan 2009 19:52:33 +0000 (UTC) Subject: ldap backend issues References: <2ue646-ff2.ln1@nb2.stroeder.com> Message-ID: > Thomas Mueller wrote: >> first, the online documentation**, says to create new ACL's ending with >> "by * none". this disabled the access for all except the two kerberos >> users. after reading man slapd.access it may be better read "by * >> break" to let slapd evaluate the next access statements? > > I'd suggest to examine ACL issues by setting an appropriate log level > and clarify what you find in the logs on the openldap-software mailing > list. this isn't acually a problem. just wanted to say tha if somebody like me copies the sample configuration in the krb5 documentation from web.mit.edu/kerberos and if the cn=Kerberos is below the "root" of the ldap directory one will disable all read access. Maybe the documentation should state, that one should read "man slapd.access" for the "by * none" meaning or change documentation to "by * break" to let slapd evaluate the further access rules. > >> second, i've configured the openldap like the sample krb5.conf file in >> chapter 3.3.11. altough i've written the kdc and adm dn the kdc-server >> and admin-server don't start without supplying "-x host=ldapi:// >> -x binddn=cn=kdc-service,dc=test". is /etc/krb5.conf the right place? >> don't i have to write some ldap config to /etc/krb5kdc/kdc.conf? "man >> kdc.conf" doesn't reveal anything about "ldap". > > I also had some problems. But you should really try to collect some > Kerberos error messages and post them here. Also posting you krb5.conf > and kdc.conf would help. ok, i decided to set up a blank debian lenny virtual machine.. and it works now, i don't have to add "-x" flags to the init scripts. Think I had a typo somewhre. sorry for the noise. LDAP backend is working like I expected. So that leaves the last point: how to migrate the passwords from file based kerberos db to the ldap backend. Searching the net and newsgroups/ mailinglists didn't reaveal anything. Do i have missed something? - Thomas From rahulkohli2001 at yahoo.com Tue Jan 20 08:15:10 2009 From: rahulkohli2001 at yahoo.com (Rahul Kohli) Date: Tue, 20 Jan 2009 05:15:10 -0800 (PST) Subject: Kerberos Tickets flushed on unlocking Windows Xp? Message-ID: <251616.53693.qm@web34504.mail.mud.yahoo.com> Hi, ? I am facing a strange issue with Kerberos authentication on my Windows XP system. I noticed that on lock and unlock Windows XP system all the kerberos TGT and service tickets get deleted and recreated. ? Is this a Known feature or defect ? Please let me know when does these kerberos tickets get flushed on the lock, or the unlock? ? Is there a patch/fix available for this behavior? Can the default locl/unlock behavior be changed for kerberos. ? Thanks, Rahul From jaltman at secure-endpoints.com Tue Jan 20 08:36:40 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Tue, 20 Jan 2009 08:36:40 -0500 Subject: Kerberos Tickets flushed on unlocking Windows Xp? In-Reply-To: <251616.53693.qm@web34504.mail.mud.yahoo.com> References: <251616.53693.qm@web34504.mail.mud.yahoo.com> Message-ID: <4975D368.1010303@secure-endpoints.com> Rahul Kohli wrote: > Hi, > > I am facing a strange issue with Kerberos authentication on my Windows XP system. I noticed that on lock and unlock Windows XP system all the kerberos TGT and service tickets get deleted and recreated. > > Is this a Known feature or defect ? Please let me know when does these kerberos tickets get flushed on the lock, or the unlock? > > Is there a patch/fix available for this behavior? Can the default locl/unlock behavior be changed for kerberos. > > Thanks, > Rahul > During the unlock XP is re-authenticating the user against the KDC. This results in a new TGT being obtained which replaces any previously cached tickets. This is a fairly standard behavior across Kerberos implementations. What is the problem that you are experiencing from this behavior? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3355 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20090120/f26b7fdb/smime.bin From keithsjohnston at gmail.com Mon Jan 19 23:23:44 2009 From: keithsjohnston at gmail.com (keithsjohnston@gmail.com) Date: Mon, 19 Jan 2009 20:23:44 -0800 (PST) Subject: Problem with kerberos telnet option Message-ID: <16bcbbbc-2c32-4048-a2ff-0b0136d5a8fd@l38g2000vba.googlegroups.com> I am trying to setup a test kdc server and workstation. After I did the setup I can login as user5 using the kerberos password. But there still seems to be a problem. When I telnet from station5 (kerberos server) to station6 (workstation) I get the following error [krb5-telnet is on] ------------------------------- Waiting for encryption to be negotiated... Negotiation of authentication, which is required for encryption, has failed. Good-bye. --------------------------------------- When I login to either station5 or station6 using the user5 kerberos password (login or ssh), everything seems to be working. But when I go from ssh from station6 to station5 it request another login. I thought kerberos would only require me to login to station6 and then I could ssh directly to station5 without re-entering the password. Following are my krb5kdc.log messages as mapped by step. Following this are my /etc/krb5.conf, /var/kerberos/krb5kdc/kdc.conf files and my results from getprincs. What I am trying to determine is what are these log messages telling me and do they give an indication of what maybe or is my problem. ####### telnet from station5 to station6 ####### telnet -Fxl user5 station6.example.com Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, user5 at STATION5.EXAMPLE.COM for host/ station6.example.com at STATION5.EXAMPLE.COM Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, user5 at STATION5.EXAMPLE.COM for host/ station6.example.com at STATION5.EXAMPLE.COM Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, user5 at STATION5.EXAMPLE.COM for krbtgt/ STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, user5 at STATION5.EXAMPLE.COM for krbtgt/ STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM ###### Following is the messages in krb5kdc.log after ssh login ###### from a computer outside realm to ###### user5 at station6.example.com Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- authentication required Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- authentication required Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM Jan 19 21:56:22 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ station6.example.com at STATION5.EXAMPLE.COM Jan 19 21:56:22 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ station6.example.com at STATION5.EXAMPLE.COM ##### this is after starting the ssh login from station6 to station5 ##### ssh station5.example.com -l user5 ##### password has not been entered Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, Server not found in Kerberos database Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, Server not found in Kerberos database Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, Server not found in Kerberos database Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, Server not found in Kerberos database Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, Server not found in Kerberos database Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, Server not found in Kerberos database #####after password entry when ssh from station6 to station5 Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.5: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- authentication required Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.5: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- authentication required Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM Jan 19 21:59:37 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ station5.example.com at STATION5.EXAMPLE.COM Jan 19 21:59:37 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ station5.example.com at STATION5.EXAMPLE.COM ##### results of getprincs K/M at STATION5.EXAMPLE.COM host/station5.example.com at STATION5.EXAMPLE.COM host/station6.example.com at STATION5.EXAMPLE.COM kadmin/admin at STATION5.EXAMPLE.COM kadmin/changepw at STATION5.EXAMPLE.COM kadmin/history at STATION5.EXAMPLE.COM kadmin/station5 at STATION5.EXAMPLE.COM krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM root/admin at STATION5.EXAMPLE.COM user5 at STATION5.EXAMPLE.COM #####following is my /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = STATION5.EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes [realms] STATION5.EXAMPLE.COM = { kdc = 192.168.1.5:88 admin_server = 192.168.1.5:749 } [domain_realm] station5.example.com = STATION5.EXAMPLE.COM station6.example.com = STATION5.EXAMPLE.COM [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [appdefaults] pam = { validate = true debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } ##### Following are the results of getprincs Authenticating as principal root/admin at STATION5.EXAMPLE.COM with password. kadmin.local: getprincs K/M at STATION5.EXAMPLE.COM host/station5.example.com at STATION5.EXAMPLE.COM host/station6.example.com at STATION5.EXAMPLE.COM kadmin/admin at STATION5.EXAMPLE.COM kadmin/changepw at STATION5.EXAMPLE.COM kadmin/history at STATION5.EXAMPLE.COM kadmin/station5 at STATION5.EXAMPLE.COM krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM root/admin at STATION5.EXAMPLE.COM user5 at STATION5.EXAMPLE.COM ############Following is my /var/kerberos/krb5kdc/kdc.conf [kdcdefaults] acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab v4_mode = nopreauth [realms] STATION5.EXAMPLE.COM = { master_key_type = des3-hmac-sha1 default_principal_flags = +preauth # supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal des- hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3 } From michael at stroeder.com Mon Jan 19 11:32:28 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 19 Jan 2009 17:32:28 +0100 Subject: mod_auth_kerb: gss_accept_sec_context() failed In-Reply-To: References: <2g5746-jue.ln1@nb2.stroeder.com> Message-ID: Andrew Cobaugh wrote: > On Fri, Jan 16, 2009 at 2:58 PM, Michael Str?der wrote: >> HI! >> >> I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for >> SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to >> receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP >> SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly >> initialized. >> >> The web browser is Seamonkey and it already sends the >> Authorization: Negotiate YIIE0AYGKwYBBQ[..] >> in the HTTP request. >> >> But it does not work. I don't get authorized HTTP access. >> In Apache's error_log I find: >> gss_accept_sec_context() failed: Unspecified GSS failure. Minor >> code may provide more information (, Decrypt integrity check failed) > > Are you sure that the keytab specified by Krb5Keytab is consistent > with the HTTP service principal that is in AD? That message is the > same as saying "your password is wrong." Yes, I'm pretty sure. Krb5Keytab points to the file I've extracted with ktpass.exe and the command-line tool 'strings' extracts the right Kerberos realm, "HTTP" and fully-qualified domain name of the server. How can I gather more debug log messages? > Also, if you're going to use mod_auth_kerb to do GSS, you'll need a > patch so that mod_auth_kerb sets up the GSS environment correclty, so > that your application will use the correct KRB5CCNAME: > > http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch Many thanks for this information! Ciao, Michael. From phalenor at gmail.com Tue Jan 20 09:47:16 2009 From: phalenor at gmail.com (Andrew Cobaugh) Date: Tue, 20 Jan 2009 09:47:16 -0500 Subject: mod_auth_kerb: gss_accept_sec_context() failed In-Reply-To: References: <2g5746-jue.ln1@nb2.stroeder.com> Message-ID: <1b8d56200901200647n41d0281bu79eb97485fc902ac@mail.gmail.com> On Mon, Jan 19, 2009 at 11:32 AM, Michael Str?der wrote: > Andrew Cobaugh wrote: >> On Fri, Jan 16, 2009 at 2:58 PM, Michael Str?der wrote: >>> HI! >>> >>> I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for >>> SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to >>> receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP >>> SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly >>> initialized. >>> >>> The web browser is Seamonkey and it already sends the >>> Authorization: Negotiate YIIE0AYGKwYBBQ[..] >>> in the HTTP request. >>> >>> But it does not work. I don't get authorized HTTP access. >>> In Apache's error_log I find: >>> gss_accept_sec_context() failed: Unspecified GSS failure. Minor >>> code may provide more information (, Decrypt integrity check failed) >> >> Are you sure that the keytab specified by Krb5Keytab is consistent >> with the HTTP service principal that is in AD? That message is the >> same as saying "your password is wrong." > > Yes, I'm pretty sure. Krb5Keytab points to the file I've extracted with > ktpass.exe and the command-line tool 'strings' extracts the right > Kerberos realm, "HTTP" and fully-qualified domain name of the server. Look at the ktutil command. That's the proper way to inspect a keytab. You'll want to make sure the key version number (kvno) is the same as what's in AD. Actually, one simple way to test that the keytab is valid is to do something like: kinit -k -t /path/to/keytab HTTP/ It might also help to know what types of keys are associated with that principal. You can do that by looking at the output of "klist -e" after performing the kinit command above (assuming it succeeds). > How can I gather more debug log messages? Set "LogLevel debug" in httpd.conf It also might be helpful to look at your Active Directory server logs to see what principal apache is trying to use. It might be that it's requesting something other than HTTP/. >> Also, if you're going to use mod_auth_kerb to do GSS, you'll need a >> patch so that mod_auth_kerb sets up the GSS environment correclty, so >> that your application will use the correct KRB5CCNAME: >> >> http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch > > Many thanks for this information! Also, just to clarify, that's only if you're doing SPNEGO. I had the same problem trying to do SPNEGO to allow IMP to connect to an IMAP server using GSSAPI (through php's imap_open() function). Perhaps I should prod the developers to actually add in the call to gss_krb5_ccache_name().... --andy From michael at stroeder.com Tue Jan 20 15:20:49 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Jan 2009 21:20:49 +0100 Subject: mod_auth_kerb: gss_accept_sec_context() failed In-Reply-To: References: <2g5746-jue.ln1@nb2.stroeder.com> Message-ID: <2aoh46-bq5.ln1@nb2.stroeder.com> Michael Str?der wrote: > Andrew Cobaugh wrote: >> On Fri, Jan 16, 2009 at 2:58 PM, Michael Str?der wrote: >>> HI! >>> >>> I'm trying to test mod_auth_kerb-5.4 built with MIT libs 1.6.3 for >>> SPNEGO/Kerberos working with MS AD W2K3SP1. My ultimate goal is to >>> receive a forwardable ticket (env var KRB5CCNAME) and use that for LDAP >>> SASL/GSSAPI bind to AD. The service account in AD is AFAICS properly >>> initialized. >>> >>> The web browser is Seamonkey and it already sends the >>> Authorization: Negotiate YIIE0AYGKwYBBQ[..] >>> in the HTTP request. >>> >>> But it does not work. I don't get authorized HTTP access. >>> In Apache's error_log I find: >>> gss_accept_sec_context() failed: Unspecified GSS failure. Minor >>> code may provide more information (, Decrypt integrity check failed) >> Are you sure that the keytab specified by Krb5Keytab is consistent >> with the HTTP service principal that is in AD? That message is the >> same as saying "your password is wrong." > > Yes, I'm pretty sure. Krb5Keytab points to the file I've extracted with > ktpass.exe and the command-line tool 'strings' extracts the right > Kerberos realm, "HTTP" and fully-qualified domain name of the server. > > How can I gather more debug log messages? Well, I set LogLevel debug in httpd.conf now and got the following messages in Apache's error_log: ------------------------------ snip ------------------------------ [debug] src/mod_auth_kerb.c(1635): [client 10.1.1.5] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [debug] src/mod_auth_kerb.c(1635): [client 10.1.1.5] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [debug] src/mod_auth_kerb.c(1247): [client 10.1.1.5] Acquiring creds for HTTP/nb2.stroeder.local at DOM2.ADTEST.LOCAL [debug] src/mod_auth_kerb.c(1392): [client 10.1.1.5] Verifying client data using KRB5 GSS-API [debug] src/mod_auth_kerb.c(1408): [client 10.1.1.5] Client didn't delegate us their credential [debug] src/mod_auth_kerb.c(1108): [client 10.1.1.5] GSS-API major_status:000d0000, minor_status:96c73a1f [error] [client 10.1.1.5] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, Decrypt integrity check failed) ------------------------------ snip ------------------------------ Hmm... >> Also, if you're going to use mod_auth_kerb to do GSS, you'll need a >> patch so that mod_auth_kerb sets up the GSS environment correclty, so >> that your application will use the correct KRB5CCNAME: >> >> http://users.bx.psu.edu/~phalenor/code/mod_auth_kerb-5.4-set_gss_ccache_name.patch > > Many thanks for this information! I've applied this patch. Ciao, Michael. From ioplex at gmail.com Wed Jan 21 02:16:04 2009 From: ioplex at gmail.com (Michael B Allen) Date: Wed, 21 Jan 2009 02:16:04 -0500 Subject: mod_auth_kerb: gss_accept_sec_context() failed In-Reply-To: <2aoh46-bq5.ln1@nb2.stroeder.com> References: <2g5746-jue.ln1@nb2.stroeder.com> <2aoh46-bq5.ln1@nb2.stroeder.com> Message-ID: <78c6bd860901202316o19e8c8bdg3744c0a9b51188d@mail.gmail.com> On Tue, Jan 20, 2009 at 3:20 PM, Michael Str?der wrote: > [debug] src/mod_auth_kerb.c(1247): [client 10.1.1.5] Acquiring creds for > HTTP/nb2.stroeder.local at DOM2.ADTEST.LOCAL > [debug] src/mod_auth_kerb.c(1392): [client 10.1.1.5] Verifying client > data using KRB5 GSS-API > [debug] src/mod_auth_kerb.c(1408): [client 10.1.1.5] Client didn't > delegate us their credential > [debug] src/mod_auth_kerb.c(1108): [client 10.1.1.5] GSS-API > major_status:000d0000, minor_status:96c73a1f > [error] [client 10.1.1.5] gss_accept_sec_context() failed: Unspecified > GSS failure. Minor code may provide more information (, Decrypt > integrity check failed) The "Decrypt integrity check failed" error means that the GSS service located an entry in the keytab file with the target SPN but the encryption key, key version number or encryption type was not exactly the same as that used to encrypt the service ticket. If this error occurs while you're trying to install or update the HTTP service account, it's a good bet that the cause is an old cached HTTP service ticket on the client. Meaning the cached ticket was encrypted with an old encryption key, key version number, encryption type combination. To fix this problem, you simply need to purge your client credential cache (such as by logging off and back on) or wait long enough for the ticket to expire. That will force the client to reacquire a new ticket generated with the most current encryption key, key version number and encryption type. One tool that is helpful with examining your client credential cache and with purging tickets is the kerbtray.exe utility from the Resource Kit Tools package available through MS' website. Run kerbtray.exe and then right click on it's bright green systray icon and select "purge tickets". Whenever you run ktpass it's usually a good idea to purge your client's tickets. If this does not solve your problem then you should run ktpass again and note the encryption key and key version number (the encryption type should be the default which is RC4). Then recopy the keytab and verify with ktutil that the encryption key and key version number are in fact correct. To get delegation to work with Firefox, you must go into about:config and add the servername or domain name to network.negotiate-auth.delegation-uris property. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From engemam at uni-muenster.de Wed Jan 21 02:41:54 2009 From: engemam at uni-muenster.de (Michael Engemann) Date: Wed, 21 Jan 2009 08:41:54 +0100 Subject: AW: computer account change password with Windows 2008 domain In-Reply-To: References: <87wsd73qgm.fsf@windlord.stanford.edu> Message-ID: Hi Ross, I just wanted to mention that by my own tests I can confirm that, although the hotfix is not listed in the SP2 patch list, the hotfix or the equivalent functionality is included in SP2. This is also true for the recently released public beta1 of Windows Server 2008 R2. Michael > -----Urspr?ngliche Nachricht----- > Von: Wilper, Ross A [mailto:rwilper at stanford.edu] > Gesendet: Dienstag, 13. Januar 2009 18:03 > An: Michael Engemann; Russ Allbery > Cc: kerberos at mit.edu > Betreff: RE: computer account change password with Windows 2008 domain > > This hotfix is installed on 4 of our 5 forests and have not seen any > issues with it. I will note that our production authentication forest > is the one that it is not on since we have been delayed deploying > Windows 2008 there. On the other hand, we put infrastructure and client > development servers into our UAT forest which does have this patch - so > we do have Exchange, Outlook, and many 3rd-party + home grown apps on > both Windows and Unix hitting a patched environment. > > From the chatter I heard during the case, they had to make some deep > changes in LDAP to fix the behavior, but I am also surprised that the > patch has still not gone public. I have been poking a bit. I just > checked the patch list for Service Pack 2 and I do not see it listed > there either. > > -Ross > > -----Original Message----- > From: Michael Engemann [mailto:engemam at uni-muenster.de] > Sent: Tuesday, January 13, 2009 8:46 AM > To: Wilper, Ross A; Russ Allbery; Michael Engemann > Cc: kerberos at mit.edu > Subject: AW: computer account change password with Windows 2008 domain > > Hi Ross, > > thank you very much for the information about the hotfix. > May I ask if you have experienced any issues since applying the hotfix > on your production servers? I ask because I wonder why this hotfix > hasn't been released publicly yet. > > Thanks, > > Michael > > > > -----Urspr?ngliche Nachricht----- > > Von: Wilper, Ross A [mailto:rwilper at stanford.edu] > > Gesendet: Mittwoch, 7. Januar 2009 20:29 > > An: Russ Allbery; Michael Engemann > > Cc: kerberos at mit.edu > > Betreff: RE: computer account change password with Windows 2008 > domain > > > > The QoP negotiation issue is fixed by the hotfix with KB article > > 957072. > > This has been applied to our systems, but as of yet, I have not seen > > that this hotfix has been released publicly. So you would need to > > contact MS support for the hotfix > > > > -Ross > > > > > > -----Original Message----- > > From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On > > Behalf Of Russ Allbery > > Sent: Wednesday, January 07, 2009 10:45 AM > > To: Michael Engemann > > Cc: kerberos at mit.edu > > Subject: Re: computer account change password with Windows 2008 > domain > > > > Michael Engemann writes: > > > > > we are also experiencing the bug in Windows Server 2008 that was > > > mentionend on this list in April 2008 by Russ Allberry: > > > > > > * Microsoft broke password changes via the LDAP protocol with SASL > > GSSAPI > > > binds in Windows 2008. In Windows 2003, provided that you didn't > > try to > > > negotiate an SASL privacy layer, you could connect via TLS and > > > authenticate with GSSAPI and query or set the password attribute > > > directly. In Windows 2008, this no longer works; you always get > > the > > > error from the server that you are not permitted to negotiate a > > privacy > > > layer when using TLS, even though you're not trying to. We've > > already > > > filed this as a bug. > > > > > > Are there probably any news about a fix or a known workaround? > > > > The workaround is to use the password change protocol instead of > using > > LDAP. That's what we modified our code to do, since so far as I know > > Microsoft still hasn't fixed this bug. (Their negotiation of GSSAPI > > privacy layers in their LDAP implementation is oddly broken in ways > > that > > are apparently difficult to fix, leading the server to think that > > you've > > always negotiated a privacy layer even if you haven't. At least > that's > > my understanding of the problem.) > > > > -- > > Russ Allbery (rra at stanford.edu) > > > > ________________________________________________ > > Kerberos mailing list Kerberos at mit.edu > > https://mailman.mit.edu/mailman/listinfo/kerberos From peter.djalaliev at gmail.com Thu Jan 22 16:51:46 2009 From: peter.djalaliev at gmail.com (Peter Djalaliev) Date: Thu, 22 Jan 2009 13:51:46 -0800 (PST) Subject: question about obtaining a proxy ticket from another realm Message-ID: Hello, We are trying to make a client in realm R1 get a proxy ticket for a server in realm R2. We are using the MIT Kerberos distribution. Here is how we are trying to do this: - obtain a proxiable initial TGT using kinit - a client in R1 calls krb5_get_credentials() to follow the realm chain and get a service ticket for the server in R2. The function stores the service ticket, as well as all intermediate credentials in the credential cache (ccache). - the client retrieves from the ccache the TGT for R2's KDC, e.g for krbtgt/R2 at R1. This TGT is proxiable. - the client uses that TGT to call krb5_get_cred_via_tkt() with KDC_OPT_PROXY in the KDC request options to request from R2's KDC a proxy ticket for the server in R2. Does this sound like a correct way to do it? I couldn't really find any documentation about how to do get proxy tickets from another realm. The last step listed above fails. The error message that I get on R2's KDC is: TGS_REQ (7 etypes {18 17 16 23 3 2}) 192.168.100.3: CAN'T PROXY TGT: authtime 1232658130, peterdj at R1 for http/webserver at R2, KDC can't fulfill requested option The code that generates the error condition is in validate_tgs_request () in src/kdc/kdc_util.c: /* can not proxy ticket granting tickets */ if (isflagset(request->kdc_options, KDC_OPT_PROXY) && (!request->server->data || request->server->data[0].length != KRB5_TGS_NAME_SIZE || memcmp(request->server->data[0].data, KRB5_TGS_NAME, KRB5_TGS_NAME_SIZE))) { *status = "CAN'T PROXY TGT"; return KDC_ERR_BADOPTION; } KRB5_TGS_NAME is #define-d as "krbtgt" and KRB5_TGS_NAME_SIZE is #define-d as 6. I'm afraid I don't understand these error checks. This piece of code seems to check if KDC_OPT_PROXY is set in the KDC request and if the first portion of the server principal name is "krbtgt". If it is not "krbtgt", the KDC assumes that the client is requesting a proxy TGT and returns an error. The server principal for this KDC request is http/webserver at R2. Shouldn't this be the request for a service ticket for http/ webserver? Why is the KDC treating this request as a request for a TGT? Any help would be appreciated. Best Regards, Peter Djalaliev From sbuckley at MIT.EDU Fri Jan 23 09:35:24 2009 From: sbuckley at MIT.EDU (Stephen C. Buckley) Date: Fri, 23 Jan 2009 09:35:24 -0500 Subject: REMINDER -- Interop Testing Proposals Due Jan 30 Message-ID: <45774E80-EB81-419C-ADE8-FF17E8DF6945@mit.edu> The MIT Kerberos Consortium will hold its first Interoperability Testing event March 30th - April 3rd, 2009. This event will be hosted by Microsoft Corporation on their Campus in Redmond, Washington. MIT is organizing this interoperability event to provide a neutral environment for software companies and other organizations to test their Kerberos implementations and Kerberized applications. We expect a lively and productive week where engineers from participating organizations can succeed in testing and debugging their code together. This event is open to all. Sponsors of the MIT Kerberos Consortium may attend this event at no cost. Other organizations who wish to participate will pay a fee to support this work. The amount of this fee will be determined individually, based on the complexity of the testing required, the size of the organization, and the number of attendees representing them. The design of this event will be largely determined by who plans to attend, and what their testing needs will be. Therefore, we ask that you send us an indication of interest in participation as soon as possible, and a detailed testing proposal no later than January 30th, 2009. This testing proposal should ideally include: - software you would like to test, - any issues you have encountered with interoperability, - platforms against which you would like test, - specific Kerberos features you would like to test, - any unique configuration(s) that you require for testing, - Access to external Internet and network/firewall requirements, - Possible number of attendees from your organization, To indicate your interest in attending or to submit your proposal, please contact Thomas Hardjono, Strategic Advisor to the MIT Kerberos Consortium, at hardjono at MIT.EDU. Thanks and hope to see you in Redmond this Spring. s _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Stephen C. Buckley Executive Director MIT Kerberos Consortium Massachusetts Institute of Technology http://www.kerberos.org From Nika at teletrain.nl Fri Jan 23 15:55:32 2009 From: Nika at teletrain.nl (Nika Gerson Lohman) Date: Fri, 23 Jan 2009 21:55:32 +0100 Subject: Problems unwrapping SPNEGO token for Single Signon (SSO) in WebLogic Server 8.1. Message-ID: It turned out to be solved by removing the SSOAccount in AD and recreating it (including re-setting the password, which had already been done several times). Regards, Nika. ________________________________________ From: Nika Gerson Lohman Sent: Friday, January 02, 2009 8:58 AM To: 'kerberos at mit.edu' Subject: Problems unwrapping SPNEGO token for Single Signon (SSO) in WebLogic Server 8.1. First of all, a quick description of our issue. We've tried many different things, but cannot get WebLogic to unwrap the SPNEGO token so it authenticates using Kerberos. We received several errors while trying to debug, here's the one we see most: KDC has no support for encryption type (14) But we doubt it has anything to do with the encryption type, as these are set correctly everywhere. We've tried following some of the instructions on the BEA website (which contain several errors). One of them was also adding a host/ SPN (in krb5login.conf) but then, when using HTTP/ SPN we get the following error (it seems with multiple SPN's it only takes the first or last SPN that was set): Client not found in Kerberos database (6) Next try was using the host/ SPN but that results in the following error: Integrity check on decrypted field failed (31) We've tried changing the default_*_enctypes in KRB5.INI (We've removed the entries, and also tried only DES_CBC_MD5 and DES_CBC_CRC) but that did not change the behaviour. We've tried adding the AllowTGTSessionKey registry key on client and server, but that didn't change it either. We are not sure what details you need for this to debug, so here's what we've done to install the environment (please note that ip-addresses, domain, client and server names are made up and are different in real-life), We have two domains: Domain1 (DOMAIN1.COM) contains: Domain Controller ???????? "AD1" ?????????????? with IP 192.168.0.1 Domain Controller ???????? "AD2" ?????????????? with IP 192.168.1.1 Client ?????????????????????????? "Client1" ?????????? with IP 192.168.2.1 Domain2 (DOMAIN2.COM) contains: Domain Controller ???????? "AD3" ?????????????? with IP 10.0.0.1 Server?? (WebLogic)??????? "Server1" ????????? with IP 10.0.1.2 Between Domain1 and Domain2 a firewall exists in which we've opened the relevant ports like LDAP (TCP 389), Kerberos (UDP 88), WebLogic (7001/7002).We do not see any firewall blocks on other ports. We've configured AD1 (Microsoft AD with KDC) as follows: 1. Account "SSOAccountAD" created 2. Password never expires 3. DES encryption on 4. Do not require Kerberos preauthentication off 5. Password "Password" was reset several times 6. ServicePrincipalName was set using this setspn -A HTTP/Server1.DOMAIN1.COM SSOAccountAD 7. ServicePrincipalName on AD1 was checked (and found to be ok) using this command: setspn -L SSOAccountAD 8. KTPass was executed: ktpass -princ HTTP/Server1 at DOMAIN1.COM -mapuser SSOAccountAD -pass Password 9. User Logon name was checked: HTTP/Server1 10. ServicePrincipalName on AD2 was checked (and found to be ok) using this command: setspn -L SSOAccountAD We've configured the WebLogic Server (Server1) as follows: 1. LDAP authentication was activated and test ok 2. Single Pass Negotiate Identity Asserter was created with Chosen Type "Authorization" 3. KRB5.INI file was created and added to %windir% (and C:\WINNT folder to be able to test with Java ktab and kinit which do not look in the %windir% folder): [libdefaults] default_realm = DOMAIN1.COM dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes=DES-CBC-CRC default_tgs_enctypes=DES-CBC-CRC [realms] DOMAIN1.COM = { kdc = 192.168.0.1 admin_server = 192.168.0.1 default_domain = DOMAIN1.COM } [domain_realm] .domain1.com = DOMAIN1.COM domain1.com = DOMAIN1.COM [appdefaults] autologin = true forward = true forwardable = true encrypt = true 4. We've installed JDK 1.5.0.12: jdk-1_5_0_12-windows-i586-p.exe 5. Keytab File was created (with password "Password"): ktab -k SSOKeyTabFile -a HTTP/Server1 at DOMAIN1.COM 6. Keytab File and Kerberos communication was tested using: kinit -k -t SSOKeyTabFile HTTP/Server1 at DOMAIN1.COM 7. Keytab File and Kerberos communication was tested using Java (incl. Debugging): java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Kinit -k -t SSOKeyTabFile HTTP/Server1 at DOMAIN1.COM 8. Keytab was listed: java -Dsun.security.krb5.debug=true sun.security.krb5.internal.tools.Klist 9. SSOKeyTabFile was copied to the WebLogic ProductionDomain folder 10. The krb5login.conf file was created and copied to the WebLogic ProductionDomain folder: com.sun.security.jgss.initiate { ???? com.sun.security.auth.module.Krb5LoginModule required ???? principal="HTTP/Server1 at DOMAIN1.COM" useKeyTab=true ???? keyTab=SSOKeyTabFile storeKey=true debug=true; }; com.sun.security.jgss.accept { ???? com.sun.security.auth.module.Krb5LoginModule required ???? principal=" HTTP/Server1 at DOMAIN1.COM " useKeyTab=true ???? keyTab=SSOKeyTabFile storeKey=true debug=true; }; 11. WebLogic service and startWeblogic.cmd were modified with the following parameters: -Djava.security.krb5.realm=DOMAIN1.COM -Djava.security.krb5.kdc=192.168.0.1 -Djava.security.auth.login.config=\krb5login.conf -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true -DDebugSecurityAdjudicator=true -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugSecurityAtz=true -Dweblogic.Debug.DebugSecurityATN=true -Dweblogic.StdoutSeverityLevel=64 -Dweblogic.StdoutDebugEnabled=true For the client pc (Client1) we've checked the browser settings: Automatic Logon only in Intranet Zone ??????????? Enable Integrated Windows Authentication On the client we've used "kerbtray.exe" to see whether a kerberos token is created, and it is (although with the full domain name, HTTP/Server1.domain1.com). We've checked for Kerberos communication with Wireshark and see that the client does communicate, and passes the SPNEGO token to the WebLogic server, but we do not see any Kerberos communication on the WebLogic server. The server simply requests Authorisation again. If required we have the full wireshark traces of the WebLogic Server and the Client. We also have very detailed WebLogic tracing which I can provide. Kind Regards, Nika. Nika Gerson Lohman Senior Software Engineer ? Tele'Train Software BV, http://www.teletrain.nl Paasheuvelweg 1 1105 BE Amsterdam Telefoon: +31 (0)20 379 03 52 Fax: +31 (0)20 379 03 53 Private Fax: +31 (0)84 222 49 06 Mobiel: +31 (0)62 040 13 50 E-Mail: nika at teletrain.nl MSN: nika at teletrain.nl From mike503 at gmail.com Sat Jan 24 02:43:40 2009 From: mike503 at gmail.com (mike) Date: Fri, 23 Jan 2009 23:43:40 -0800 Subject: I'm trying to hire a developer to port mod_auth_gss to nginx... Message-ID: What would be the minimum environment required to get this done? I assume some sort of Windows server that does Kerberos key stuff Webserver would be on Ubuntu, and I see the docs on how to get mod_auth_gss working. It's the server piece I am not sure about. I doubt WinXP or Vista can do this. What's the lowest Windows version that will distribute Kerberos keys for SPNEGO/single sign on? 2000? 2003? Side note: anyone interested in this? Willing to pay. Will help advance nginx and SPNEGO... Sam did a quick evaluation and it sounded like he didn't think it would be too difficult. From res at qoxp.net Mon Jan 26 19:45:44 2009 From: res at qoxp.net (Richard E. Silverman) Date: Mon, 26 Jan 2009 19:45:44 -0500 Subject: MIT kadmin not using DNS Message-ID: A (I hope) quick question: I see claims in various places (including the O'Reilly Kerberos book), that kadmin will use DNS SRV records to locate the admin server -- but it doesn't seem to. The Solaris derivative *does* do this, and works for us, but running MIT kadmin in the same environment requires the admin_server parameter in krb5.conf. Any ideas? -- Richard Silverman res at qoxp.net From commercials at gmx.net Mon Jan 26 22:51:30 2009 From: commercials at gmx.net (Julius) Date: Tue, 27 Jan 2009 04:51:30 +0100 Subject: MIT kadmin not using DNS Message-ID: <1233028290.6414.6.camel@wf> On Mon, 2009-01-26 at 19:45 -0500, Richard E. Silverman wrote: > A (I hope) quick question: I see claims in various places (including the > O'Reilly Kerberos book), that kadmin will use DNS SRV records to locate the > admin server -- but it doesn't seem to. The Solaris derivative *does* do > this, and works for us, but running MIT kadmin in the same environment > requires the admin_server parameter in krb5.conf. > > Any ideas? > This works for heimdal /etc/dnsmasq.conf: domain=localdomain.de srv-host=_kerberos-adm._udp,night_crawler.localdomain.de,88 srv-host=_kerberos-adm._tcp,night_crawler.localdomain.de,88 srv-host=_kerberos-adm._tls._tcp,night_crawler.localdomain.de,88 srv-host=_kerberos._udp.LOCALDOMAIN.DE,night_crawler.localdomain.de,88 srv-host=_kerberos._tcp.LOCALDOMAIN.DE,night_crawler.localdomain.de,88 From mikef at berkeley.edu Tue Jan 27 18:53:33 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Tue, 27 Jan 2009 15:53:33 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a 'sequel' to my earlier postings about getting bad return codes from the KDC. However, I've moved from a binary Linux distribution to a FreeBSD port of MIT Kerberos and my symptoms are a bit different, so I'm starting a new thread. My problem is this: I'm using programs based on the MIT API to do authentication, via get_in_tkt_with_password (or get_in_tkt_with_keytab), krb5_mk_req, krb5_rd_req. (This is perl code using the Authen::Krb5 module, which I've been running for a couple of years on my production 1.4.2 system). If I have a principal that has any of the following set, then, even if I supply the correct password, I get back a return code of 31 (decrypt integrity check), instead of the more specific return code that would correspond to the specific situation: CLIENT_NOT_FOUND CLIENT EXPIRED REQUIRED PWCHANGE CLIENT KEY EXPIRED But if none of the above is true, then my authentication succeeds (RC=0) if I supply the correct password, and fails with the expected RC=31 if I enter an invalid password. This is krb5-1.6.3 on FreeBSD. In reply to one of my earlier postings, Tom Yu said the following: > I am unable to reproduce this condition. Is the krb5-1.6.1 KDC possibly > built using the --with-vague-errors option? Looking through the (now 1.6.3) build tree, I see no indication that '--with-vague-errors' is being specified as an override. In src/configure, it appears to be specified by default, but I think that is my own misunderstanding of the configure file, because my production KDC (1.4.2) src/configure looks exactly the same in this regard and I don't get this behavior there. My symptoms seem very much consistent with the presumed meaning of '--with-vague-errors', but I have the problem only on 1.6.3, yet it appears that neither system is compiled with that option. Is it possible that 1.6.3 defaults to '--with-vague-errors', unlike 1.4.2? More specifically, how can I be sure whether that option was specified at compile time? Thanks for any suggestions. Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl/nn0ACgkQFgKSfLOvZ1R+MACePCkn5lhhT+ksuV4KQ4NLbqa2 BY4AnAliAZLXvkAEEu+TI0LwgXQD0Vs4 =OPL9 -----END PGP SIGNATURE----- From mortenolsen at gmail.com Wed Jan 28 05:38:30 2009 From: mortenolsen at gmail.com (Morten Sylvest Olsen) Date: Wed, 28 Jan 2009 02:38:30 -0800 (PST) Subject: Kerberos <-> Microsoft Active Directory & DNS Message-ID: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> Hi, I have an issue integrating Kerberos to AD. I believe they have an error in their DNS setup (based on the amount of trouble I've had through the years with Active Directory and DNS, yuck), but I'd like a second opinion, before I yell at the AD admins. The problem is that a number of AD servers in a sub-domain/sub-realm resolves to a name in a higher-level domain when doing a reverse lookup. Ie. ad1.ext.domain.org -> 1.2.3.4 When doing a reverse lookup on 1.2.3.4 I'd get ad1.domain.org This fools Kerberos and it tries to get a key for ldap/ad1.domain.org instead of ldap/ad1.ext.domain.org (MIT Kerberos 1.6.1 on redhat linux 5) I can workaround by messing with /etc/hosts, of course. Does anyone know whether this is a "supported" configuration for Kerberos? /Morten From res at qoxp.net Wed Jan 28 13:53:06 2009 From: res at qoxp.net (Richard E. Silverman) Date: Wed, 28 Jan 2009 13:53:06 -0500 Subject: Problem with kerberos telnet option References: <16bcbbbc-2c32-4048-a2ff-0b0136d5a8fd@l38g2000vba.googlegroups.com> Message-ID: > > I am trying to setup a test kdc server and workstation. > After I did the setup I can login as user5 using the kerberos > password. But there still seems to be a problem. > > When I telnet from station5 (kerberos server) to station6 > (workstation) I get the following error [krb5-telnet is on] > ------------------------------- > Waiting for encryption to be negotiated... > > Negotiation of authentication, which is required for encryption, > has failed. Good-bye. > --------------------------------------- Try setting client-side debug authentication debugging to see what's going on: sys1:~% telnet telnet> set authd auth debugging enabled telnet> open -a seraph.lionaka.net Trying ... Connected to seraph.lionaka.net Escape character is '^]'. >>>TELNET: I support auth type 2 6 >>>TELNET: I support auth type 2 2 >>>TELNET: I support auth type 2 0 >>>TELNET: auth_send got: 02 06 02 02 02 00 >>>TELNET: He supports 2 >>>TELNET: He supports 2 >>>TELNET: Trying 2 2 >>>IS:0: [0] (485) 6e 82 01 e1 30 82 01 dd a0 03 02 01 05 a1 03 02 telnet: Sent Kerberos V5 credentials to server >>>TELNET: Using type 2 [ Kerberos V5 accepts you as ``res at LIONAKA.NET'' ] Last login: Tue Jan 27 21:57:55 seraph:~% > When I login to either station5 or station6 using the user5 kerberos > password (login or ssh), everything seems to be working. But when I go > from ssh from station6 to station5 it request another login. I > thought kerberos would only require me to login to station6 and then I > could ssh directly to station5 without re-entering the password. > > Following are my krb5kdc.log messages as mapped by step. > Following this are my /etc/krb5.conf, /var/kerberos/krb5kdc/kdc.conf > files and my results from getprincs. > > What I am trying to determine is what are these log messages telling > me and do they give an indication of what maybe or is my problem. > > ####### telnet from station5 to station6 > ####### telnet -Fxl user5 station6.example.com > > Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) > 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, > user5 at STATION5.EXAMPLE.COM for host/ > station6.example.com at STATION5.EXAMPLE.COM > Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) > 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, > user5 at STATION5.EXAMPLE.COM for host/ > station6.example.com at STATION5.EXAMPLE.COM > Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) > 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, > user5 at STATION5.EXAMPLE.COM for krbtgt/ > STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > Jan 19 22:01:51 station5 krb5kdc[1876](info): TGS_REQ (1 etypes {1}) > 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 tkt=16 ses=1}, > user5 at STATION5.EXAMPLE.COM for krbtgt/ > STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > > > > > ###### Following is the messages in krb5kdc.log after ssh login > ###### from a computer outside realm to > ###### user5 at station6.example.com > > Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM > for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- > authentication required > Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM > for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- > authentication required > Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ > STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > Jan 19 21:56:22 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ > STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > Jan 19 21:56:22 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ > station6.example.com at STATION5.EXAMPLE.COM > Jan 19 21:56:22 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: ISSUE: authtime 1232423782, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ > station6.example.com at STATION5.EXAMPLE.COM > > > ##### this is after starting the ssh login from station6 to station5 > ##### ssh station5.example.com -l user5 > ##### password has not been entered > > Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, > user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, > Server not found in Kerberos database > Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, > user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, > Server not found in Kerberos database > Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, > user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, > Server not found in Kerberos database > Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, > user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, > Server not found in Kerberos database > Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, > user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, > Server not found in Kerberos database > Jan 19 21:59:05 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.6: UNKNOWN_SERVER: authtime 1232423782, > user5 at STATION5.EXAMPLE.COM for host/station5 at STATION5.EXAMPLE.COM, > Server not found in Kerberos database > > #####after password entry when ssh from station6 to station5 > > Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.5: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM > for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- > authentication required > Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.5: NEEDED_PREAUTH: user5 at STATION5.EXAMPLE.COM > for krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM, Additional pre- > authentication required > Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ > STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > Jan 19 21:59:37 station5 krb5kdc[1876](info): AS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for krbtgt/ > STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > Jan 19 21:59:37 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ > station5.example.com at STATION5.EXAMPLE.COM > Jan 19 21:59:37 station5 krb5kdc[1876](info): TGS_REQ (7 etypes {18 17 > 16 23 1 3 2}) 192.168.1.5: ISSUE: authtime 1232423977, etypes {rep=16 > tkt=16 ses=16}, user5 at STATION5.EXAMPLE.COM for host/ > station5.example.com at STATION5.EXAMPLE.COM > > > > ##### results of getprincs > > K/M at STATION5.EXAMPLE.COM > host/station5.example.com at STATION5.EXAMPLE.COM > host/station6.example.com at STATION5.EXAMPLE.COM > kadmin/admin at STATION5.EXAMPLE.COM > kadmin/changepw at STATION5.EXAMPLE.COM > kadmin/history at STATION5.EXAMPLE.COM > kadmin/station5 at STATION5.EXAMPLE.COM > krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > root/admin at STATION5.EXAMPLE.COM > user5 at STATION5.EXAMPLE.COM > > > #####following is my /etc/krb5.conf > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = STATION5.EXAMPLE.COM > dns_lookup_realm = false > dns_lookup_kdc = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > STATION5.EXAMPLE.COM = { > kdc = 192.168.1.5:88 > admin_server = 192.168.1.5:749 > } > > [domain_realm] > station5.example.com = STATION5.EXAMPLE.COM > station6.example.com = STATION5.EXAMPLE.COM > > [kdc] > profile = /var/kerberos/krb5kdc/kdc.conf > > [appdefaults] > pam = { > validate = true > debug = false > ticket_lifetime = 36000 > renew_lifetime = 36000 > forwardable = true > krb4_convert = false > } > > ##### Following are the results of getprincs > > Authenticating as principal root/admin at STATION5.EXAMPLE.COM with > password. > kadmin.local: getprincs > K/M at STATION5.EXAMPLE.COM > host/station5.example.com at STATION5.EXAMPLE.COM > host/station6.example.com at STATION5.EXAMPLE.COM > kadmin/admin at STATION5.EXAMPLE.COM > kadmin/changepw at STATION5.EXAMPLE.COM > kadmin/history at STATION5.EXAMPLE.COM > kadmin/station5 at STATION5.EXAMPLE.COM > krbtgt/STATION5.EXAMPLE.COM at STATION5.EXAMPLE.COM > root/admin at STATION5.EXAMPLE.COM > user5 at STATION5.EXAMPLE.COM > > > ############Following is my /var/kerberos/krb5kdc/kdc.conf > > [kdcdefaults] > acl_file = /var/kerberos/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab v4_mode = nopreauth [realms] STATION5.EXAMPLE.COM = { master_key_type = des3-hmac-sha1 default_principal_flags = +preauth # supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal des- hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3 } -- Richard Silverman res at qoxp.net From ioplex at gmail.com Wed Jan 28 15:27:51 2009 From: ioplex at gmail.com (Michael B Allen) Date: Wed, 28 Jan 2009 15:27:51 -0500 Subject: Kerberos <-> Microsoft Active Directory & DNS In-Reply-To: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> References: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> Message-ID: <78c6bd860901281227p22a7cb6cv44e50b7cfae18ced@mail.gmail.com> On Wed, Jan 28, 2009 at 5:38 AM, Morten Sylvest Olsen wrote: > Hi, > > I have an issue integrating Kerberos to AD. I believe they have an > error in their DNS setup (based on the amount of trouble I've had > through the years with Active Directory and DNS, yuck), but I'd like a > second opinion, before I yell at the AD admins. > > The problem is that a number of AD servers in a sub-domain/sub-realm > resolves to a name in a higher-level domain when doing a reverse > lookup. > > Ie. ad1.ext.domain.org -> 1.2.3.4 > When doing a reverse lookup on 1.2.3.4 I'd get ad1.domain.org > > This fools Kerberos and it tries to get a key for ldap/ad1.domain.org > instead of ldap/ad1.ext.domain.org (MIT Kerberos 1.6.1 on redhat linux > 5) > > I can workaround by messing with /etc/hosts, of course. > > Does anyone know whether this is a "supported" configuration for > Kerberos? Hi Morten, It's not clear to me what component is doing a reverse lookup. What software is actually getting the name mixed up? Is it an LDAP client? What LDAP client with what Kerberos implementation? What exactly is the hostname that you are using with said client? You're not using an IP address where an FQDN hostname should be right? I'm not aware of any software that uses a reverse lookup to change the hostname before composing the principal name used to request a ticket (I would not be surprised if such a thing existed but if it did I would consider it broken). Of course if you supplied an IP address instead, the client would have to do a reverse lookup and that would certainly explain the behavior you see (which I think I might still consider broken). Or perhaps the client cannot resolve the hostname that was supplied and there is some fallback code that is doing a reverse lookup (which again I think I might still consider broken)? Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From mortenolsen at gmail.com Wed Jan 28 16:57:53 2009 From: mortenolsen at gmail.com (Morten Sylvest Olsen) Date: Wed, 28 Jan 2009 13:57:53 -0800 (PST) Subject: Kerberos <-> Microsoft Active Directory & DNS References: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> Message-ID: On Jan 28, 9:27?pm, Michael B Allen wrote: > Hi Morten, > > It's not clear to me what component is doing a reverse lookup. What > software is actually getting the name mixed up? Is it an LDAP client? > What LDAP client with what Kerberos implementation? What exactly is > the hostname that you are using with said client? You're not using an > IP address where an FQDN hostname should be right? No, I am not using numeric addresses. I think it happens inside the Kerberos implementation, it correctly retrieves a tgt for the sub- domain using my TGT for the base domain, but fails when it tries to get the service ticket. I can see the wrong principal used in the _REQ packet (using wireshark). It could be the cyrus-sasl GSSAPI plugin as well. (The stack is openldap -> SASL -> GSSAPI -> Kerberos). > I'm not aware of any software that uses a reverse lookup to change the > hostname before composing the principal name used to request a ticket > (I would not be surprised if such a thing existed but if it did I > would consider it broken). Well, this is MIT Kerberos (on Linux). The MIT Kerberos libraries uses DNS reverse lookup for canonization in many places, afaik. Obviously, that is not the case for AD, I have no idea how Heimdal behaves. I guess your Java implementation doesnt either, judging from your statements :) /Morten From ioplex at gmail.com Wed Jan 28 20:25:51 2009 From: ioplex at gmail.com (Michael B Allen) Date: Wed, 28 Jan 2009 20:25:51 -0500 Subject: Kerberos <-> Microsoft Active Directory & DNS In-Reply-To: References: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> Message-ID: <78c6bd860901281725v58609057r27951ebf7ec9cfa3@mail.gmail.com> On Wed, Jan 28, 2009 at 4:57 PM, Morten Sylvest Olsen wrote: > On Jan 28, 9:27 pm, Michael B Allen wrote: >> Hi Morten, >> >> It's not clear to me what component is doing a reverse lookup. What >> software is actually getting the name mixed up? Is it an LDAP client? >> What LDAP client with what Kerberos implementation? What exactly is >> the hostname that you are using with said client? You're not using an >> IP address where an FQDN hostname should be right? > > No, I am not using numeric addresses. I think it happens inside the > Kerberos implementation, it correctly retrieves a tgt for the sub- > domain using my TGT for the base domain, but fails when it tries to > get the service ticket. I can see the wrong principal used in the _REQ > packet (using wireshark). > > It could be the cyrus-sasl GSSAPI plugin as well. (The stack is > openldap -> SASL -> GSSAPI -> Kerberos). > >> I'm not aware of any software that uses a reverse lookup to change the >> hostname before composing the principal name used to request a ticket >> (I would not be surprised if such a thing existed but if it did I >> would consider it broken). > > Well, this is MIT Kerberos (on Linux). The MIT Kerberos libraries uses > DNS reverse lookup for canonization in many places, afaik. I know more about Heimdal than I do MIT so I don't really know how MIT actually uses DNS reverse lookups to discover names. But if I had to guess I would be surprised if it didn't use reverse lookups only as a last resort in the absence of sufficient information in either the krb5.conf or derived from DNS (someone familiar w/ the MIT implementation please step in and correct me if necessary). You might want to make sure your client's krb5.conf has information about all of the domains involved. > Obviously, that is not the case for AD, I have no idea how Heimdal > behaves. I'm still not really sure what the codepath and point of failure is in your use-case so I still can't give you a definitive answer. But Windows clients do use DNS SRV queries A LOT to discover services. That could be related to your issue. In general, both the MIT and Heimdal clients are not optimized for a Windows environment. We have an AD integration product that uses Heimdal that we made a lot of changes to try to better emulate Windows behavior. > I guess your Java implementation doesnt either, judging from > your statements :) The Java solution referenced in my sig is actually NTLM (although that product will eventually also support Kerberos too). Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From cclausen at acm.org Thu Jan 29 10:00:07 2009 From: cclausen at acm.org (Christopher D. Clausen) Date: Thu, 29 Jan 2009 09:00:07 -0600 Subject: Kerberos <-> Microsoft Active Directory & DNS References: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> <78c6bd860901281725v58609057r27951ebf7ec9cfa3@mail.gmail.com> Message-ID: <376C117F4612491EBB644CACCCC5BF2B@CDCHOME> Michael B Allen wrote: > In general, both the MIT and Heimdal clients are not optimized for a > Windows environment. We have an AD integration product that uses > Heimdal that we made a lot of changes to try to better emulate Windows > behavior. Please just stop trying to sell folks your product using this list. ----- It sounds like all this guy needs is proper [domain_realm settings] in krb5.conf and possibly a proper [capaths] sections if a realm trust is involved. (Its not clear to me if there is just a single realm or not.) It sounds like AD is configured to do dynamic DNS for A record registration but is not authoritative for PTR registration and this is causing problems b/c AD thinks the name should be in one domain and in reality the PTR is in another. (We have the exact same problem where I work.) I think the solution is to ignore the AD name and use the fqdn that the reverse lookup returns. If you join #kerberos on the Freenode IRC network there are folks there who would be willing to try and help for free and NOT try and sell you some Active Directory integration product. < Microsoft Active Directory & DNS In-Reply-To: <376C117F4612491EBB644CACCCC5BF2B@CDCHOME> References: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> <78c6bd860901281725v58609057r27951ebf7ec9cfa3@mail.gmail.com> <376C117F4612491EBB644CACCCC5BF2B@CDCHOME> Message-ID: <78c6bd860901290849s71dc347dkc4a1fd027bc73298@mail.gmail.com> On Thu, Jan 29, 2009 at 10:00 AM, Christopher D. Clausen wrote: > Michael B Allen wrote: >> In general, both the MIT and Heimdal clients are not optimized for a >> Windows environment. We have an AD integration product that uses >> Heimdal that we made a lot of changes to try to better emulate Windows >> behavior. > > Please just stop trying to sell folks your product using this list. Christopher, No were did I link to or even name the product you speak of (nor do I think it would apply to him) and obviously the solution cited in my signature does not apply to him. I was simply informing him, as someone with real experience in these matters, that AD clients exhibit very different behavior from both MIT and Heimdal and thus he may have to take additional care to compensate. I have mentioned my Kerberos product on this list in the past but only when the list member specifically asked about the unique combination of things to which it applies. All of the changes made to Heimdal that I cited have been posted on the Heimdal mailing list. I have made contributions to the Kerberos community in the form of bug fixes, support and documentation. I do not think my behavior in this thread warranted a complaint. I absolutely did not intend to impress my products on Morten and I was only genuinely trying to help him. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From res at qoxp.net Thu Jan 29 01:16:48 2009 From: res at qoxp.net (Richard E. Silverman) Date: Thu, 29 Jan 2009 01:16:48 -0500 Subject: Windows client authentication problem References: Message-ID: >>>>> "VVN" == Viji V Nair writes: VVN> Hi, I am trying to authenticate windows xp clients to an MIT VVN> kerberos server. The Server is on a Linux machine and I have VVN> both windows and Linux clients on my network. I have followed the VVN> below steps, but no success. VVN> Configured the kerberos server and Linux clients are VVN> authenticating properly, but no success on windows clients. On VVN> the kerberos Server I have created a host principal using the VVN> following command. VVN> # kadmin -q "ank host/bmdata01.testing.com" (I tried kadmin -q VVN> "ank host/bmdata01" also) VVN> On the windows xp client(bmdata01), VVN> C:> ksetup /setrealm TESTING.COM C:> ksetup /addkdc TESTING.COM VVN> viji.bigmaps.com C:> ksetup /setmachpassword C:> VVN> ksetup /mapuser admin at TESTING.COM guest C:> ksetup /mapuser * * VVN> After the reboot windows is showing TESTING.COM as a Kerberos VVN> Realm on the login screen, but when I try to login using a VVN> kerberos user it is throwing the following error. VVN> *"The system could not log you on. Make sure your user name and VVN> domain are correct, and then type your password again. Letters in VVN> passwords must be typed using the correct case."* VVN> But the kerberos server is issuing the tickets, the log shows: VVN> Dec 30 22:36:03 viji.testing.com krb5kdc[5179](info): AS_REQ (7 VVN> etypes {23 -133 -128 3 1 24 -135}) 172.16.33.112: NEEDED_PREAUTH: VVN> admin at TESTING.COM for krbtgt/TESTING.COM at TESTING.COM, Additional VVN> pre-authentication required Dec 30 22:36:03 viji.testing.com VVN> krb5kdc[5179](info): AS_REQ (3 etypes {23 3 1}) 172.16.33.112: VVN> ISSUE: authtime 1230656763, etypes {rep=23 tkt=18 ses=23}, VVN> admin at TESTING.COM for krbtgt/TESTING.COM at TESTING.COM Dec 30 VVN> 22:36:03 viji.testing.com krb5kdc[5179](info): TGS_REQ (7 etypes VVN> {23 -133 -128 3 1 24 -135}) 172.16.33.112: ISSUE: authtime VVN> 1230656763, etypes {rep=23 tkt=18 ses=23}, admin at TESTING.COM for VVN> host/bmdata01.testing.com@ TESTING.COM Make sure both the machine and user principals on the KDC only have RC4 or DES keys. The session key here is RC4 (23), but the ticket is AES (18). VVN> I have found some article on Microsoft website, saying this is a VVN> bug and apply the latest service pack (SP3), I even tried that, VVN> but no success. VVN> http://support.microsoft.com/kb/825081 VVN> Similar Thread: VVN> http://mailman.mit.edu/pipermail/kerberos/2006-May/009890.html VVN> c:> ksetup.exe default realm = TESTING.COM (external) VVN> TESTING.COM: kdc = viji.testing.com Realm Flags = 0x0 none VVN> Mapping all users (*) to guest. Mapping admin to guest. VVN> # cat /etc/krb5.conf VVN> [logging] default = FILE:/var/log/krb5libs.log kdc = VVN> FILE:/var/log/krb5kdc.log admin_server = VVN> FILE:/var/log/kadmind.log VVN> [libdefaults] default_realm = TESTING.COM dns_lookup_realm = true VVN> dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes VVN> [realms] TESTING.COM = { kdc = viji.testing.com:88 admin_server = VVN> viji.testing.com:749 default_domain = testing.com VVN> } [domain_realm] VVN> .testing.com = TESTING.COM testing.com = TESTING.COM VVN> [appdefaults] pam = { debug = false ticket_lifetime = 36000 VVN> renew_lifetime = 36000 forwardable = true krb4_convert = false VVN> } [dbmodules] VVN> TESTING.COM = { db_library = kldap ldap_servers = VVN> ldap://127.0.0.1/ ldap_kerberos_container_dn = VVN> cn=kerberos,dc=testing,dc=com ldap_kdc_dn = VVN> uid=kdc,cn=sysaccounts,cn=etc,dc=testing,dc=com ldap_kadmind_dn = VVN> uid=kdc,cn=sysaccounts,cn=etc,dc=testing,dc=com VVN> ldap_service_password_file = /var/kerberos/krb5kdc/ldappwd VVN> } Any help on this will be greatly appreciated. VVN> Thanks & Regards Viji -- Richard Silverman res at qoxp.net From mortenolsen at gmail.com Thu Jan 29 04:58:38 2009 From: mortenolsen at gmail.com (Morten Sylvest Olsen) Date: Thu, 29 Jan 2009 01:58:38 -0800 (PST) Subject: Kerberos <-> Microsoft Active Directory & DNS References: <547ffb28-1d6a-4d93-b5e2-caee34820538@i20g2000prf.googlegroups.com> Message-ID: <3aee848d-29d4-4953-9e92-ea9326f4c6a8@v5g2000prm.googlegroups.com> On Jan 29, 2:25?am, Michael B Allen wrote: > >> I'm not aware of any software that uses a reverse lookup to change the > >> hostname before composing the principal name used to request a ticket > >> (I would not be surprised if such a thing existed but if it did I > >> would consider it broken). > > > Well, this is MIT Kerberos (on Linux). The MIT Kerberos libraries uses > > DNS reverse lookup for canonization in many places, afaik. > > I know more about Heimdal than I do MIT so I don't really know how MIT > actually uses DNS reverse lookups to discover names. But if I had to > guess I would be surprised if it didn't use reverse lookups only as a > last resort in the absence of sufficient information in either the > krb5.conf or derived from DNS (someone familiar w/ the MIT > implementation please step in and correct me if necessary). You might > want to make sure your client's krb5.conf has information about all of > the domains involved. Well, that would kind of defeat the entire purpose of not having to, because DNS SRV lookups are used for finding KDC's, and AD afaik *always* has a 1-1 mapping between domains and realms? Normally, it isn't necessary to configure anything except dns_lookup_realm and dns_lookup_kdc, when I've previously integrated to AD's. > In general, both the MIT and Heimdal clients are not optimized for a > Windows environment. We have an AD integration product that uses > Heimdal that we made a lot of changes to try to better emulate Windows > behavior. Yes, I can imagine that. I believe the samba people has had a lot of issues as well. I resorted to reading the code, I guess somebody at MIT agrees with you: if (maybe_use_reverse_dns(context, DEFAULT_RDNS_LOOKUP)) { /* * Do a reverse resolution to get the full name, just in * case there's some funny business going on. If there * isn't an in-addr record, give up. */ /* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */ For posterity, I did find a good thread on this exact problem on the MIT kerberos mailing list: http://mailman.mit.edu/pipermail/krbdev/2005-September/003724.html The AD administrators have actually conceded that the DNS may be wrong, I'm not sure whether they'll be able to change it. We'd have to use krb5.conf or hosts tricks otherwise. Thanks for your input, /Morten From mikef at berkeley.edu Thu Jan 29 14:55:35 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Thu, 29 Jan 2009 11:55:35 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Re: my getting RC=31 (decrypt integrity check) for various conditions, like expired principal or passphrase or non-existent principal. I've done some further testing and here's my situation: It appears that the '--with-vague-errors' configure option just affects the text of error messages, not the return codes. So, I've compiled without that option and even even kinit exhibits the same problem: it tells me I've entered an incorrect password, even though that's not true. In fact, if the principal is expired, or the passphrase is expired, etc., it appears that the KDC 'short circuits' the AS exchange, not issuing a 'PRE_AUTH_REQUIRED' message and just reporting a bad passphrase. My applications need to be able to distinguish between these various conditions, for which there are documented return codes. Why are they not being returned? Since '--with-vague-errors' is not the issue here, my question is, what else might have changed between 1.4.2 and 1.6.1 to cause this new behavior? Thanks. Mike ======================================================================== On Tue, 27 Jan 2009 at 15:53 (-0800), Mike Friedman wrote: > If I have a principal that has any of the following set, then, even if I > supply the correct password, I get back a return code of 31 (decrypt > integrity check), instead of the more specific return code that would > correspond to the specific situation: > > CLIENT_NOT_FOUND > CLIENT EXPIRED > REQUIRED PWCHANGE > CLIENT KEY EXPIRED > > But if none of the above is true, then my authentication succeeds (RC=0) > if I supply the correct password, and fails with the expected RC=31 if I > enter an invalid password. > > This is krb5-1.6.3 on FreeBSD. _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmCCbcACgkQFgKSfLOvZ1R8FQCeI1kE+PoKInp/P1+ExkaPLZ8C P/MAn3QIp99evRjn2/AYt0BxcE9PwYq3 =Ykhx -----END PGP SIGNATURE----- From tlyu at MIT.EDU Thu Jan 29 16:23:28 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Jan 2009 16:23:28 -0500 Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: (Mike Friedman's message of "Tue, 27 Jan 2009 15:53:33 -0800 (PST)") References: Message-ID: Mike Friedman writes: > This is a 'sequel' to my earlier postings about getting bad return codes > from the KDC. However, I've moved from a binary Linux distribution to a > FreeBSD port of MIT Kerberos and my symptoms are a bit different, so I'm > starting a new thread. > > My problem is this: > > I'm using programs based on the MIT API to do authentication, via > get_in_tkt_with_password (or get_in_tkt_with_keytab), krb5_mk_req, > krb5_rd_req. (This is perl code using the Authen::Krb5 module, which I've > been running for a couple of years on my production 1.4.2 system). The get_in_tkt APIs are deprecated in favor of the get_init_creds APIs. I know that this fact is probably not well-documented. > If I have a principal that has any of the following set, then, even if I > supply the correct password, I get back a return code of 31 (decrypt > integrity check), instead of the more specific return code that would > correspond to the specific situation: > > CLIENT_NOT_FOUND > CLIENT EXPIRED > REQUIRED PWCHANGE > CLIENT KEY EXPIRED > > But if none of the above is true, then my authentication succeeds (RC=0) > if I supply the correct password, and fails with the expected RC=31 if I > enter an invalid password. What error shows up in the KDC logs during those failure conditions? From mikef at berkeley.edu Thu Jan 29 16:43:06 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Thu, 29 Jan 2009 13:43:06 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 Jan 2009 at 16:23 (-0500), Tom Yu wrote: > The get_in_tkt APIs are deprecated in favor of the get_init_creds APIs. > I know that this fact is probably not well-documented. Tom, Yes, I've been aware of this for some time. Unfortunately, my code is several years old and I've not had a chance to upgrade it. Anyway, by now you've probably seen my subsequent note that, I hope, helps clarify the actual situation with return codes. >> If I have a principal that has any of the following set, then, even if >> I supply the correct password, I get back a return code of 31 (decrypt >> integrity check), instead of the more specific return code that would >> correspond to the specific situation: >> >> CLIENT_NOT_FOUND >> CLIENT EXPIRED >> REQUIRED PWCHANGE >> CLIENT KEY EXPIRED >> >> But if none of the above is true, then my authentication succeeds >> (RC=0) if I supply the correct password, and fails with the expected >> RC=31 if I enter an invalid password. > > What error shows up in the KDC logs during those failure conditions? One example is this: CLIENT KEY EXPIRED: mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU, Password has expired As I said in my later note, it's not just my API code that's reflecting the wrong return code. Even kinit tells me 'Password incorrect while getting initial credentials', though I did enter the correct password. And (as I also mentioned, for what it might be worth), the KDC is not even doing the REQUIRES_PREAUTH exchange in these cases. Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmCIuoACgkQFgKSfLOvZ1Rk+wCfRLoafDZwTlYOtEi4UKm45CZq FDwAn1azP4Faaf78r8zKOQM0PVlWdB6r =SWgA -----END PGP SIGNATURE----- From tlyu at MIT.EDU Thu Jan 29 17:09:34 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Jan 2009 17:09:34 -0500 Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: (Mike Friedman's message of "Thu, 29 Jan 2009 13:43:06 -0800 (PST)") References: Message-ID: Mike Friedman writes: >> What error shows up in the KDC logs during those failure conditions? > > One example is this: > > CLIENT KEY EXPIRED: mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU, Password has expired > > As I said in my later note, it's not just my API code that's reflecting > the wrong return code. Even kinit tells me 'Password incorrect while > getting initial credentials', though I did enter the correct password. > And (as I also mentioned, for what it might be worth), the KDC is not even > doing the REQUIRES_PREAUTH exchange in these cases. Are you getting a "password incorrect" error from kinit when the KDC logs the "CLIENT KEY EXPIRED" message above? If you are getting the incorrect error code out of kinit as well, I was unable to reproduce that. Which release are you getting the kinit program from? And which release are you using for the library for the program you wrote? What does "getprinc" show for the principal when you have set it up to produce this failure condition? From mikef at berkeley.edu Thu Jan 29 17:23:50 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Thu, 29 Jan 2009 14:23:50 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 Jan 2009 at 17:09 (-0500), Tom Yu wrote: > Mike Friedman writes: > >> CLIENT KEY EXPIRED: mikef at BERKELEY.EDU for krbtgt/BERKELEY.EDU at BERKELEY.EDU, Password has expired >> >> As I said in my later note, it's not just my API code that's reflecting >> the wrong return code. Even kinit tells me 'Password incorrect while >> getting initial credentials', though I did enter the correct password. >> And (as I also mentioned, for what it might be worth), the KDC is not >> even doing the REQUIRES_PREAUTH exchange in these cases. > > Are you getting a "password incorrect" error from kinit when the KDC > logs the "CLIENT KEY EXPIRED" message above? If you are getting the > incorrect error code out of kinit as well, I was unable to reproduce > that. Tom, Yes, when the KDC says 'CLIENT KEY EXPIRED', kinit says 'Password incorrect'. > Which release are you getting the kinit program from? And which release > are you using for the library for the program you wrote? What does > "getprinc" show for the principal when you have set it up to produce > this failure condition? Previously, I was using a 1.4.2 kinit remotely. But I just tried 1.6.3 kinit on the same 1.6.3 KDC itself and also got a 'Password incorrect' message. Also, as for my API program, I actually tried with a version that was built with 1.4.2 and one built with an older MIT version. But the fact that kinit seems to be acting the same way would appear to be the significant point. Here's what getprinc shows: kadmin.local: getprinc mikef Principal: mikef at BERKELEY.EDU Expiration date: [never] Last password change: Tue Jan 27 14:41:56 PST 2009 Password expiration date: Wed Jan 28 11:00:16 PST 2009 Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Thu Jan 29 11:00:16 PST 2009 (root/admin at BERKELEY.EDU) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 4 Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt Key: vno 1, ArcFour with HMAC/md5, no salt Key: vno 1, DES cbc mode with CRC-32, no salt Attributes: REQUIRES_PRE_AUTH Policy: [none] _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmCLHcACgkQFgKSfLOvZ1T+4wCfX4zvBA0GZVx23A4GqtU5vVRZ OFQAoIEEAoAHs/z32QH76PtkkdaGnUtq =n1uq -----END PGP SIGNATURE----- From tlyu at MIT.EDU Thu Jan 29 17:44:40 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Jan 2009 17:44:40 -0500 Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: (Mike Friedman's message of "Thu, 29 Jan 2009 14:23:50 -0800 (PST)") References: Message-ID: Mike Friedman writes: > But the fact that kinit seems to be acting the same way would appear to be > the significant point. Yes. > Here's what getprinc shows: > > kadmin.local: getprinc mikef > Principal: mikef at BERKELEY.EDU > Expiration date: [never] > Last password change: Tue Jan 27 14:41:56 PST 2009 > Password expiration date: Wed Jan 28 11:00:16 PST 2009 > Maximum ticket life: 0 days 10:00:00 > Maximum renewable life: 7 days 00:00:00 > Last modified: Thu Jan 29 11:00:16 PST 2009 (root/admin at BERKELEY.EDU) > Last successful authentication: [never] > Last failed authentication: [never] > Failed password attempts: 0 > Number of keys: 4 > Key: vno 1, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt > Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt > Key: vno 1, ArcFour with HMAC/md5, no salt > Key: vno 1, DES cbc mode with CRC-32, no salt > Attributes: REQUIRES_PRE_AUTH > Policy: [none] Do you get this sort of mismatched error code for a client principal that does not have REQUIRES_PRE_AUTH set? From mikef at berkeley.edu Thu Jan 29 17:50:53 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Thu, 29 Jan 2009 14:50:53 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 29 Jan 2009 at 17:44 (-0500), Tom Yu wrote: > Do you get this sort of mismatched error code for a client principal > that does not have REQUIRES_PRE_AUTH set? Tom, With 1.6.3 kinit, without REQUIRES_PREAUTH, I now get the expected message: Password expired. You must change it now. However, with 1.4.2 kinit and with my API program built with earlier MIT libraries, I still get 'Password incorrect while getting initial credentials' from kinit and RC=31, 'decrypt integrity check' from my program. So, what's going on here? Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmCMs0ACgkQFgKSfLOvZ1TGQwCeI8el2hrH6baUtgWw31XcPM05 e0sAn3927DaRB1uXv3PeI4KN9DYTPZyS =qXuF -----END PGP SIGNATURE----- From gwolosh at njit.edu Fri Jan 30 09:43:28 2009 From: gwolosh at njit.edu (Gedaliah Wolosh) Date: Fri, 30 Jan 2009 09:43:28 -0500 (EST) Subject: Error in logs during propogation Message-ID: Hi, I'm running 1.4.4 on RHEL 4. I propogate the database every 15 minutes. This realm was recently put into production and has about 20K principals. I seeing the following in the logs on the slaves - kpropd: Resource temporarily unavailable while trying to lock '/local/kerberos/var/krb5kdc/from_master.temp' This occurs on one slave far more frequently then the other. Based on the time stamps of the files in /local/kerberos/var/krb5kdc/ the propogation succeeds. I haven't been able to determine what is causing this error. Gedaliah Wolosh University Computing Systems - IST New Jersey Institute of Technology From mikef at berkeley.edu Fri Jan 30 11:46:51 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Fri, 30 Jan 2009 08:46:51 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom, I have a correction to my last note to you: On Thu, 29 Jan 2009 at 14:50 (-0800), Mike Friedman wrote: > With 1.6.3 kinit, without REQUIRES_PREAUTH, I now get the expected > message: > > Password expired. You must change it now. > > However, with 1.4.2 kinit and with my API program built with earlier MIT > libraries, I still get 'Password incorrect while getting initial > credentials' from kinit and RC=31, 'decrypt integrity check' from my > program. Actually, here's the situation: 1. Even *with* REQUIRES_PREAUTH, kinit on the KDC behaves correctly. 2. With or without REQUIRES_PREAUTH, kinit on my remote client still insists on returning 'Password incorrect', even when I enter the correct password. 3. My remote client kinit is *also* at the 1.6.3 level! So REQUIRES_PREAUTH doesn't appear to be the issue either. Number 3 above is what's really surprising. In fact, even the OS on the client is the same (though a different release) as that on the KDC: Client: FreeBSD 6.3-RELEASE KDC: FreeBSD 7.0-RELEASE-p5 Also, here's some additional information: on the KDC, MIT Kerberos was built (using the FreeBSD port) as follows: ./configure --enable-shared --without-krb4 CPPFLAGS=-I/usr/local/include -L/usr/local/lib --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ amd64-portbld-freebsd7.0 whereas on my FreeBSD client, I built from the MIT distribution, like this: ./configure CPPFLAGS=-DEAI_NODATA=EAI_NONAME --prefix=/usr/local/krb5-1.6.3 The latter was done quite a while ago and I believe I used the above CPPFLAGS on recommendation from someone on this list because of problems I was having otherwise (which I, unfortunately, can't recall). I don't know if any of this helps. But right now it appears that the problem occurs only when I try authentication from either of two remote clients, but not on the KDC itself. Thanks for any help you can provide on this. Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmDLvsACgkQFgKSfLOvZ1Sl8gCdHGGnUwh7KvhAeZvUVwqB5p9K Z+8AmQGR28r4ZwFXVZQh/5xVch7MtOpf =YNs8 -----END PGP SIGNATURE----- From mikef at berkeley.edu Sat Jan 31 02:25:36 2009 From: mikef at berkeley.edu (Mike Friedman) Date: Fri, 30 Jan 2009 23:25:36 -0800 (PST) Subject: Unexpected return codes from KDC -- krb5-1.6.3 -- SOLVED In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom, Well, I figured out the cause of my problem with misleading return codes. It turns out to have been caused by a simple misconfiguration, based on my own ignorance and an oversight. It seems that somewhere along the way, over the years, I overlooked the correspondence on this list concerning the 'master_kdc' parameter in krb5.config. So, all along, I've been assuming it's an optional parameter which is really useful only if you have more than one KDC and want clients to retry the master when certain authentication errors occur. The krb5.conf file I've been using to point to our test KDC was missing the 'master_kdc' parameter, even though my production krb5.conf has had it all along. This was the oversight on my part when I created the test krb5.conf. In our test (1.6.3) environment, we currently have only one KDC set up, so it never occurred to me that 'master_kdc' would make any difference. (Of course, we will be adding secondary KDCs later). However we also have a '_kerberos-master._udp...' SRV record defined in the DNS, pointing, of course, to our *production* KDC. My remote client uses the default of falling through to DNS, whereas the krb5.conf on the KDC itself turns that setting off. This, I guess, is why kinit has been working on the KDC, but not on my client. With no master_kdc in the config file or in DNS, and no secondary KDC anyway, it appears the correct errors were getting reflected back to the KDC's kinit. Whereas my remote client was falling through to the production KDC, where the passphrase I was entering for a principal in the test KDC would always be incorrect ('decrypt integrity check'). I verified the above by noticing that my production KDC logs show decrypt integrity failures every time I would enter the 'correct' password for the test KDC principal. The test KDC log would say 'CLIENT KEY EXPIRED', but then I'd fall through to the production KDC and get the invalid password error. So, having fixed my test krb5.conf file, kinit and my API program both work properly. Sorry for making this all seem more obscure than it turned out to be and thanks for your help in ruling out certain possibilities. Mike _________________________________________________________________________ Mike Friedman Information Services & Technology mikef at berkeley.edu 2484 Shattuck Avenue 1-510-642-1410 University of California at Berkeley http://mikef.berkeley.edu http://ist.berkeley.edu _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmD/PAACgkQFgKSfLOvZ1QmRACfcS6Egh+JiNxc4BMOqVEt+TcT 3q8An1ywXxlXfHchzVle4pbzy3D9tAYV =OQcM -----END PGP SIGNATURE-----