Re: Different Services, Different Realms, but One Host
Alright! Thank you sincerely for all the helpful and precise information! That's one problem with an answer ... PS. Are you aware of any products - ssh or otherwise - which use a directory service to resolve the realms of SPNs - based on both the service name and the FQDN? Jack On Mar 13, 2004, at 6:18 AM, Tim Alsop wrote: Ok, The service address lookup is dependant on the actual ssh product you are using. The product I am familiar with guesses the name of the service principal by prefixing it with "host/" and then adding the target hostname. The realm is based on the default realm of the local system. This is not a very flexible approach since it will not work in multi-realm architecture like yours. You therefore need to talk to the supplier of your ssh product and see if they have a way to configure the SPN (service principal name) for a target system so that you can tell the ssh client which realm to use in the request. Thanks, Tim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 13 March 2004 12:15 To: Tim Alsop Cc: [EMAIL PROTECTED] Subject: Re: Different Services, Different Realms, but One Host Ahh ... I'm getting the picture ... How about ssh, for starters? Most of host.blue's keys are in BLUE, though host/host.blue is in RED. So ssh need's to get host/[EMAIL PROTECTED] ... Thanks again for all the help! Jack On Mar 11, 2004, at 2:59 AM, Tim Alsop wrote: > Jack, > > The process works something like : > > 1. User enters logon details at workstation 2. Workstation kerberos > client requests initial tgt from REALM0 > (krbtgt/[EMAIL PROTECTED]) > 3. User has now authenticated against REALM0 4. You run a client > application which needs to send your principal name to service2 on > server1.domain.com. This service is using REALM2. > > 5. The client application needs to request a service ticket called > service1/[EMAIL PROTECTED] from the KDC it knows about (i.e. > REALM0). > > 6. The KDC for REALM0 recognises that the service ticket request is > for REALM2 so it uses its trust relationship to send back to > workstation a new cross realm tgt (krbtgt/[EMAIL PROTECTED]) > > 7. The workstation sends a fresh service ticket request to REALM2 > using the cross realm tgt issued by REALM0 KDC. > 8. The KDC for REALM2 responds with a service ticket 9. The service > ticket can be sent to the server by the client application. > 10. The service on the server decrypts the service ticket to determine > the principal name of the user who authenticated at the workstation. > > The bit that may be causing you an issue is step 5. It is necessary > for the client application to be aware of the full service principal > name of the service it is trying to communicate with. > > Perhaps, if you can advise what the application is I can let you know > how to make it request the correct service ticket ? > > Thanks, Tim. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 11 March 2004 10:48 > To: Tim Alsop > Subject: Re: Different Services, Different Realms, but One Host > > Thanks everyone! > > I agree, Tim: Being able to store one host's keys in different realms > would be nice - in my simple opinion. > > I think you understand my question exactly - your example is just what > I'm trying to do. Unfortunately, I still don't know how to do it. > > Truly, the confusing part is how the kerberos client obtains a cross > realm TGT for the correct realm. > > Since your example is precisely what I'm trying to do, suppose I'm > connecting to service2 on server1.domain.com - my principle resides in > REALM0, say. How does my kerberos client know whether to request a > cross realm TGT for REALM1, 2, or 3? It seems domain_realm will only > map server1.domain.com - and all of its instances - to one realm ... > > I'd be very happy to find a way around this! > > Jack > > On Mar 9, 2004, at 9:36 AM, Tim Alsop wrote: > > > Hi, > > > > Perhaps I missunderstand the question, but it is possible to use > > multiple realms on a specific host. The naming of the service > > principals (keys for which would be stored in a key table) would > > look something like : > > > > host/[EMAIL PROTECTED] > > service1/[EMAIL PROTECTED] > > service2/[EMAIL PROTECTED] > > service3/[EMAIL PROTECTED] > > > > Essentially, the key in the key table which would be acquired by a > > specific application (a Kerberos service) maintains the > > shared-secret between the service and the realm. > > > > A user can be in one realm with one password. The services can be in > > multiple realms. When an application is run by a user and requests a > > service ticket it will get the ticket from the appropriate KDC for > the > > realm. > > > > The part which is perhaps a little confusing is the approach used > >by a kerberos client to determine the KDC that issues the service > ticket. > > Normally, the service ticket request is sent to the realm where the > > initial user's ticke
Re: unable to authenticate using active directory/mit kfw 2.5 and
> Question3: For the scenario described above I have chosen SASL > implementation using netscape sdk. I have tried this in Solaris and > have succeeded. I tested with SEAM/Directory Server 5.2 and AD > implemented using Luke Padl samples implementations for > authentications and found that it was successful (attached > libgssldap.c). > > I then ported this to windows using kfw2.5 and failed to run the > samples > > May Be (MS uses SSPI to fetch Microsoft credentials from the LSA > (Windows version of credentials cache) while and then kfw 2.5 uses > GSSAPI and has its own credential caches) There are indeed different credentials caches. With KFW 2.5 you must copy the MS credentials from the LSA to CCAPI with the MS2MIT.EXE utility. In KFW 2.6 (currently in beta), you can simply set the environment variable KRB5CCNAME = MSLSA: before starting your application and the credentials from the MS LSA cache will automatically and transparently be used. Jeffrey Altman KFW Maintainer Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
RE: Different Services, Different Realms, but One Host
Ok, The service address lookup is dependant on the actual ssh product you are using. The product I am familiar with guesses the name of the service principal by prefixing it with "host/" and then adding the target hostname. The realm is based on the default realm of the local system. This is not a very flexible approach since it will not work in multi-realm architecture like yours. You therefore need to talk to the supplier of your ssh product and see if they have a way to configure the SPN (service principal name) for a target system so that you can tell the ssh client which realm to use in the request. Thanks, Tim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 13 March 2004 12:15 To: Tim Alsop Cc: [EMAIL PROTECTED] Subject: Re: Different Services, Different Realms, but One Host Ahh ... I'm getting the picture ... How about ssh, for starters? Most of host.blue's keys are in BLUE, though host/host.blue is in RED. So ssh need's to get host/[EMAIL PROTECTED] ... Thanks again for all the help! Jack On Mar 11, 2004, at 2:59 AM, Tim Alsop wrote: > Jack, > > The process works something like : > > 1. User enters logon details at workstation 2. Workstation kerberos > client requests initial tgt from REALM0 > (krbtgt/[EMAIL PROTECTED]) > 3. User has now authenticated against REALM0 4. You run a client > application which needs to send your principal name to service2 on > server1.domain.com. This service is using REALM2. > > 5. The client application needs to request a service ticket called > service1/[EMAIL PROTECTED] from the KDC it knows about (i.e. > REALM0). > > 6. The KDC for REALM0 recognises that the service ticket request is > for REALM2 so it uses its trust relationship to send back to > workstation a new cross realm tgt (krbtgt/[EMAIL PROTECTED]) > > 7. The workstation sends a fresh service ticket request to REALM2 > using the cross realm tgt issued by REALM0 KDC. > 8. The KDC for REALM2 responds with a service ticket 9. The service > ticket can be sent to the server by the client application. > 10. The service on the server decrypts the service ticket to determine > the principal name of the user who authenticated at the workstation. > > The bit that may be causing you an issue is step 5. It is necessary > for the client application to be aware of the full service principal > name of the service it is trying to communicate with. > > Perhaps, if you can advise what the application is I can let you know > how to make it request the correct service ticket ? > > Thanks, Tim. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 11 March 2004 10:48 > To: Tim Alsop > Subject: Re: Different Services, Different Realms, but One Host > > Thanks everyone! > > I agree, Tim: Being able to store one host's keys in different realms > would be nice - in my simple opinion. > > I think you understand my question exactly - your example is just what > I'm trying to do. Unfortunately, I still don't know how to do it. > > Truly, the confusing part is how the kerberos client obtains a cross > realm TGT for the correct realm. > > Since your example is precisely what I'm trying to do, suppose I'm > connecting to service2 on server1.domain.com - my principle resides in > REALM0, say. How does my kerberos client know whether to request a > cross realm TGT for REALM1, 2, or 3? It seems domain_realm will only > map server1.domain.com - and all of its instances - to one realm ... > > I'd be very happy to find a way around this! > > Jack > > On Mar 9, 2004, at 9:36 AM, Tim Alsop wrote: > > > Hi, > > > > Perhaps I missunderstand the question, but it is possible to use > > multiple realms on a specific host. The naming of the service > > principals (keys for which would be stored in a key table) would > > look something like : > > > > host/[EMAIL PROTECTED] > > service1/[EMAIL PROTECTED] > > service2/[EMAIL PROTECTED] > > service3/[EMAIL PROTECTED] > > > > Essentially, the key in the key table which would be acquired by a > > specific application (a Kerberos service) maintains the > > shared-secret between the service and the realm. > > > > A user can be in one realm with one password. The services can be in > > multiple realms. When an application is run by a user and requests a > > service ticket it will get the ticket from the appropriate KDC for > the > > realm. > > > > The part which is perhaps a little confusing is the approach used > >by a kerberos client to determine the KDC that issues the service > ticket. > > Normally, the service ticket request is sent to the realm where the > > initial user's ticket (tgt) was issued, and then a cross realm tgt > > is returned for the service realm so that a service ticket can then > > be requested from the correct realm. The service ticket is then sent > > to the service and decrypted with the key in the key table in order > > to determine the principal name of th
Re: Is Kerberos a good solution for web-single signon
Other WebISO systems that might be of interest: a-select: http://a-select.surfnet.nl/ cas: http://www.yale.edu/tp/auth/ cosign: http://weblogin.org/ You should probably also see the WebISO (web initial sign-on) group at Internet2: http://middleware.internet2.edu/webiso/ I should admit that, as a co-author of cosign, I'm rather biased, but you really should look at all of these systems closely before choosing one and particularly before choosing to write yet another one. Kevin On Mar 12, 2004, at 7:58 PM, Christopher Kranz wrote: I was wondering the same thing. In fact I started a simular thread a little while ago. The short answer is no, not really. And the reason is, HTTP is a stateless protocol. You would need to generate a new authenticator for each and every connection. Kerberos kind of assumes that once a session is started the connection is persistant. See UWash's pubcookie (http://www.pubcookie.org/) or Stanford's WebAuth (http://webauthv3.stanford.edu/) for examples of WebISO solutions. ... "In, as you say, the mud." ... Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
unable to authenticate using active directory/mit kfw 2.5 and netscape sdk
Hi All FYI: Current I am using netscape 3 c-sdk and have compiled them in windows/solaris. First I give some very basic understanding of what I am trying to achieve. Its a SSO (Single Sign on) project where our servers may be running on MAX OSX, SUN, Windows and the underlying db for users/acl(access control list) storage shall be LDAP. The directory server should be closable between DS/OpenLDAP/Ad/NDS. Question 1: The first question arises about is choosing way of authentication. Almost all the authentication mechanisms are independent of DS unless u decide to store passwords in the DS itself. The only exception is Microsoft's AD which has blended kdc with AD . Now the choice drills down to choosing mechnism. I have choosen GSSAPI/Kerberos 5. Now I have to support all of them. SEAM/MIT/HEMIDAL/AD kdc for all the respective platforms. After some study I found that SASL was the answer. As we have to choose a pluggable module for authentication so that even if we have to involve any third part auth-mechanism we should not face any problems. But the fundamental question arises. Approach : clientapp --> LDAP/SASL/GSSAPI --> KDC --> Tickets I think thru ldap_sasl_bind via SASL only. As I understand in this approach we shall be involving ldap_sasl_bind sort of thing thru SASL and shall pass the password along with user dn and other details. I think this should be same as ldapclient mechanism where I do kinit and then do all the search. i.e. the ticket is used to ldap operations. LDAP(DS) just becomes another service in the kerberos domain and once authenticated can do all the ldap operations. Now for my application when a person logs on to the windows/mac client, he gets his tgt and passes the same for authentication via sasl/ldap using netscape c-sdk library. Am I wrong in this thought or not Question2: Next part of the question is if I want to use SASL/LDAP with Directory Server Does it matter which SASL implementations are u using Question3: For the scenario described above I have chosen SASL implementation using netscape sdk. I have tried this in Solaris and have succeeded. I tested with SEAM/Directory Server 5.2 and AD implemented using Luke Padl samples implementations for authentications and found that it was successful (attached libgssldap.c). I then ported this to windows using kfw2.5 and failed to run the samples May Be (MS uses SSPI to fetch Microsoft credentials from the LSA (Windows version of credentials cache) while and then kfw 2.5 uses GSSAPI and has its own credential caches) Question4: I have attached both the files libgssldap.c and test.c which I tested in Solaris 9 and was successful. Is this the way to use GSSAPI/kerberos 5 via LDAP. I am confused ?? Question5: If feasible can u guide what can be done in the case of windows Is netscape c-sdk is the right choice. I feel yes. Question6: I have been unable to find any samples using gssapi/kerberos examples and using c-sdk except luke padl examples which runs only in UNIX based systems. Where can I find one simple sample using gssapi/kerberos/sasl in windows Regards Vikas Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Different Services, Different Realms, but One Host
Ahh ... I'm getting the picture ... How about ssh, for starters? Most of host.blue's keys are in BLUE, though host/host.blue is in RED. So ssh need's to get host/[EMAIL PROTECTED] ... Thanks again for all the help! Jack On Mar 11, 2004, at 2:59 AM, Tim Alsop wrote: Jack, The process works something like : 1. User enters logon details at workstation 2. Workstation kerberos client requests initial tgt from REALM0 (krbtgt/[EMAIL PROTECTED]) 3. User has now authenticated against REALM0 4. You run a client application which needs to send your principal name to service2 on server1.domain.com. This service is using REALM2. 5. The client application needs to request a service ticket called service1/[EMAIL PROTECTED] from the KDC it knows about (i.e. REALM0). 6. The KDC for REALM0 recognises that the service ticket request is for REALM2 so it uses its trust relationship to send back to workstation a new cross realm tgt (krbtgt/[EMAIL PROTECTED]) 7. The workstation sends a fresh service ticket request to REALM2 using the cross realm tgt issued by REALM0 KDC. 8. The KDC for REALM2 responds with a service ticket 9. The service ticket can be sent to the server by the client application. 10. The service on the server decrypts the service ticket to determine the principal name of the user who authenticated at the workstation. The bit that may be causing you an issue is step 5. It is necessary for the client application to be aware of the full service principal name of the service it is trying to communicate with. Perhaps, if you can advise what the application is I can let you know how to make it request the correct service ticket ? Thanks, Tim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 11 March 2004 10:48 To: Tim Alsop Subject: Re: Different Services, Different Realms, but One Host Thanks everyone! I agree, Tim: Being able to store one host's keys in different realms would be nice - in my simple opinion. I think you understand my question exactly - your example is just what I'm trying to do. Unfortunately, I still don't know how to do it. Truly, the confusing part is how the kerberos client obtains a cross realm TGT for the correct realm. Since your example is precisely what I'm trying to do, suppose I'm connecting to service2 on server1.domain.com - my principle resides in REALM0, say. How does my kerberos client know whether to request a cross realm TGT for REALM1, 2, or 3? It seems domain_realm will only map server1.domain.com - and all of its instances - to one realm ... I'd be very happy to find a way around this! Jack On Mar 9, 2004, at 9:36 AM, Tim Alsop wrote: > Hi, > > Perhaps I missunderstand the question, but it is possible to use > multiple realms on a specific host. The naming of the service > principals (keys for which would be stored in a key table) would look > something like : > > host/[EMAIL PROTECTED] > service1/[EMAIL PROTECTED] > service2/[EMAIL PROTECTED] > service3/[EMAIL PROTECTED] > > Essentially, the key in the key table which would be acquired by a > specific application (a Kerberos service) maintains the shared-secret > between the service and the realm. > > A user can be in one realm with one password. The services can be in > multiple realms. When an application is run by a user and requests a > service ticket it will get the ticket from the appropriate KDC for the > realm. > > The part which is perhaps a little confusing is the approach used by > a kerberos client to determine the KDC that issues the service ticket. > Normally, the service ticket request is sent to the realm where the > initial user's ticket (tgt) was issued, and then a cross realm tgt is > returned for the service realm so that a service ticket can then be > requested from the correct realm. The service ticket is then sent to > the service and decrypted with the key in the key table in order to > determine the principal name of the user. > > So, in summary - having multiple realms works well, but is more > complex. The simplest approach is to use one realm for everthing, but > this does not have the granularity that some implementations require. > It is nice to have the option to use either approach to protect > multiple applications on a specific host !! > > Regards, Tim. > > -Original Message- > From: Sam Hartman [mailto:[EMAIL PROTECTED] > Sent: 09 March 2004 17:09 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Different Services, Different Realms, but One Host > > > "ms419" == ms419 <[EMAIL PROTECTED]> writes: > > ms419> Pardon this newbish question, but here's the setup: I want > ms419> to distribute the keys for one host among two > ms419> realms. Basically, I've got a sensitive service running on > ms419> a couple of hosts, and a less secure service running on the > ms419> same hosts. I want to store the keys for the sensitive > ms419> service in one realm, and the keys for
Re: Is Kerberos a good solution for web-single signon
Christopher Kranz wrote: [EMAIL PROTECTED] (paul b) wrote in message news:<[EMAIL PROTECTED]>... Hello, I am currently developping a "web single signon"-system and I am thinking about using Kerberos for this propose [snip] Perhaps someone can tell me if Kerberos is really a good solution for web-single signon(and fully transparent to end-users) or if there are more simple possiblities like for example installing a "reverse proxy"? I was wondering the same thing. In fact I started a simular thread a little while ago. The short answer is no, not really. And the reason is, HTTP is a stateless protocol. You would need to generate a new authenticator for each and every connection. Kerberos kind of assumes that once a session is started the connection is persistant. There are two ways to go about this. The simplest is to let Apache act as a Kerberos client, accepting USER/PASS via HTTP/Basic authentication method. This is actually very bad for two reasons. Firstly, it uses HTTP/Basic authentication method between browser and web server. This method is unencrypted and without SSL (HTTPS), it will defeat one of the basic intentions of Kerberos - encrypted authentication. A much better way is to implement HTTP/SPNego authentication method. In that model, browser is a Kerberos client (with user's principal) and Apache or IIS is a Kerberos server (with server's principal), both authenticating against some Kerberos KDC (MIT KDC, MS ADS, Heimdal,...). For this you need both server and browser to be "Kerberos aware". Apache has "mod_negotiate", IIS on Win2k/2k3 should be ready, since it is on MS ADS. Of the browsers, IE 6 should be OK, also Mozilla 1.5/1.6 Nix. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
