Accepting secure context on Server without KDC-Login - Kerberos

This is a discussion on Accepting secure context on Server without KDC-Login - Kerberos ; Hello, Please help me, I still don't get it: I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Accepting secure context on Server without KDC-Login

  1. Accepting secure context on Server without KDC-Login

    Hello,

    Please help me, I still don't get it:
    I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.

    This is my code:

    Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    GSSManager tGSSManager = GSSManager.getInstance();
    String tPrincName = "servicename/hostname@REALM";
    GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    GSSCredential.ACCEPT_ONLY);
    GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    byte [] tInToken = aToken;
    byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);

    If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:

    JaasLogin {
    //Kerberos single-sign-on login module
    com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    };


    But if i never call

    LoginContext tLoginContext = new LoginContext("JaasLogin");
    tLoginContext.login();
    final Subject tSubject = tLoginContext.getSubject();

    then how can the application know that it shall use a keytab and where to find it?

    IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    What do I have to do? Login or no Login?

    Thanks for any help.

    Florian

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. AW: Accepting secure context on Server without KDC-Login

    The problem is, my server application cannot reach the KDC. The KDC's host isn't resolved for the server. So if I call

    lc.login()

    I get an UnknownHostException because the KDC's hostname is unknown.

    Thanks you for your help.

    -----Ursprüngliche Nachricht-----
    Von: Olfmatic [mailtolfmatic@web.de]
    Gesendet: Donnerstag, 7. September 2006 14:42
    An: kerberos@mit.edu
    Betreff: Accepting secure context on Server without KDC-Login


    Hello,

    Please help me, I still don't get it:
    I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.

    This is my code:

    Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    GSSManager tGSSManager = GSSManager.getInstance();
    String tPrincName = "servicename/hostname@REALM";
    GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    GSSCredential.ACCEPT_ONLY);
    GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    byte [] tInToken = aToken;
    byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);

    If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:

    JaasLogin {
    //Kerberos single-sign-on login module
    com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    };


    But if i never call

    LoginContext tLoginContext = new LoginContext("JaasLogin");
    tLoginContext.login();
    final Subject tSubject = tLoginContext.getSubject();

    then how can the application know that it shall use a keytab and where to find it?

    IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    What do I have to do? Login or no Login?

    Thanks for any help.

    Florian

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Accepting secure context on Server without KDC-Login

    The default credential acquisition model for Java GSS-API requires
    credentials to be present in the current Subject. Typically, the
    credentials are placed there after a JAAS login by the application.

    Client and server applications typically perform JAAS authentication
    using the Kerberos login module. Upon successful authentication the TGT
    is stored in the Subject's private credentials set and the Kerberos
    principal is stored in the Subject's principal set. At the server-end
    the secret key is stored in the Subject's private credentials set.

    If there are no valid credentials in the current Subject, Java GSS
    provider attempts to obtain new credentials by invoking a JAAS login
    itself. This is when the default JAAS entries
    "com.sun.security.jgss.initiate" and "com.sun.security.jgss.accept" are
    read from the JAAS configuration file, using the desired configurations
    that you provide, such as the keytab at the server-end.

    You can configure JAAS Krb5LoginModule to be an "acceptor" only at the
    server-end. This option is available starting from Java SE 6, and will
    be backported to earlier releases.

    For details on this option, check the javadoc on Krb5LoginModule:
    http://download.java.net/jdk6/docs/j...ginModule.html

    Seema

    Olfmatic wrote On 09/07/06 05:41,:

    >Hello,
    >
    >Please help me, I still don't get it:
    >I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.
    >
    >This is my code:
    >
    > Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    > GSSManager tGSSManager = GSSManager.getInstance();
    > String tPrincName = "servicename/hostname@REALM";
    > GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    > GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    > GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    > GSSCredential.ACCEPT_ONLY);
    > GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    > byte [] tInToken = aToken;
    > byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);
    >
    >If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    >But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:
    >
    >JaasLogin {
    > //Kerberos single-sign-on login module
    > com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    >};
    >
    >
    >But if i never call
    >
    > LoginContext tLoginContext = new LoginContext("JaasLogin");
    > tLoginContext.login();
    > final Subject tSubject = tLoginContext.getSubject();
    >
    >then how can the application know that it shall use a keytab and where to find it?
    >
    >IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    >IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    >What do I have to do? Login or no Login?
    >
    >Thanks for any help.
    >
    >Florian
    >
    >________________________________________________
    >Kerberos mailing list Kerberos@mit.edu
    >https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. AW: Accepting secure context on Server without KDC-Login

    Is it possible for me to use this attribute " isInitiator with a JDK 1.4? Currently I am using 1.4.2_07. Will this function be backported to a 1.4 release? Which one, if so?

    So if I understand you right, there is no possibility to tell the Krb5LoginModule NOT to try to login to the KDC, but to fetch the credentials from the keytab-File, if you are using JDK1.4?

    Thank you for your help.


    -----Ursprüngliche Nachricht-----
    Von: Seema.Malkani@Sun.COM [mailto:Seema.Malkani@Sun.COM]
    Gesendet: Donnerstag, 7. September 2006 20:20
    An: Olfmatic
    Cc: kerberos@mit.edu
    Betreff: Re: Accepting secure context on Server without KDC-Login


    The default credential acquisition model for Java GSS-API requires
    credentials to be present in the current Subject. Typically, the
    credentials are placed there after a JAAS login by the application.

    Client and server applications typically perform JAAS authentication
    using the Kerberos login module. Upon successful authentication the TGT
    is stored in the Subject's private credentials set and the Kerberos
    principal is stored in the Subject's principal set. At the server-end
    the secret key is stored in the Subject's private credentials set.

    If there are no valid credentials in the current Subject, Java GSS
    provider attempts to obtain new credentials by invoking a JAAS login
    itself. This is when the default JAAS entries
    "com.sun.security.jgss.initiate" and "com.sun.security.jgss.accept" are
    read from the JAAS configuration file, using the desired configurations
    that you provide, such as the keytab at the server-end.

    You can configure JAAS Krb5LoginModule to be an "acceptor" only at the
    server-end. This option is available starting from Java SE 6, and will
    be backported to earlier releases.

    For details on this option, check the javadoc on Krb5LoginModule:
    http://download.java.net/jdk6/docs/j...ginModule.html

    Seema

    Olfmatic wrote On 09/07/06 05:41,:

    >Hello,
    >
    >Please help me, I still don't get it:
    >I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.
    >
    >This is my code:
    >
    > Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    > GSSManager tGSSManager = GSSManager.getInstance();
    > String tPrincName = "servicename/hostname@REALM";
    > GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    > GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    > GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    > GSSCredential.ACCEPT_ONLY);
    > GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    > byte [] tInToken = aToken;
    > byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);
    >
    >If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    >But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:
    >
    >JaasLogin {
    > //Kerberos single-sign-on login module
    > com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    >};
    >
    >
    >But if i never call
    >
    > LoginContext tLoginContext = new LoginContext("JaasLogin");
    > tLoginContext.login();
    > final Subject tSubject = tLoginContext.getSubject();
    >
    >then how can the application know that it shall use a keytab and where to find it?
    >
    >IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    >IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    >What do I have to do? Login or no Login?
    >
    >Thanks for any help.
    >
    >Florian
    >
    >________________________________________________
    >Kerberos mailing list Kerberos@mit.edu
    >https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: AW: Accepting secure context on Server without KDC-Login

    This configuration option in JAAS Krb5LoginModule will be backported to
    JDK 5.0 Update release, and JDK 1.4.2, don't have the exact release
    details available as yet.

    No, server will acquire credentials from the keytab, if you provide the
    configuration option to specify the keytab file. However, the JAAS
    Krb5LoginModule will in addition acquire the TGT.

    Seema

    Olfmatic wrote:

    >Is it possible for me to use this attribute " isInitiator with a JDK 1.4? Currently I am using 1.4.2_07. Will this function be backported to a 1.4 release? Which one, if so?
    >
    >So if I understand you right, there is no possibility to tell the Krb5LoginModule NOT to try to login to the KDC, but to fetch the credentials from the keytab-File, if you are using JDK1.4?
    >
    >Thank you for your help.
    >
    >
    >-----Ursprüngliche Nachricht-----
    >Von: Seema.Malkani@Sun.COM [mailto:Seema.Malkani@Sun.COM]
    >Gesendet: Donnerstag, 7. September 2006 20:20
    >An: Olfmatic
    >Cc: kerberos@mit.edu
    >Betreff: Re: Accepting secure context on Server without KDC-Login
    >
    >
    >The default credential acquisition model for Java GSS-API requires
    >credentials to be present in the current Subject. Typically, the
    >credentials are placed there after a JAAS login by the application.
    >
    >Client and server applications typically perform JAAS authentication
    >using the Kerberos login module. Upon successful authentication the TGT
    >is stored in the Subject's private credentials set and the Kerberos
    >principal is stored in the Subject's principal set. At the server-end
    >the secret key is stored in the Subject's private credentials set.
    >
    >If there are no valid credentials in the current Subject, Java GSS
    >provider attempts to obtain new credentials by invoking a JAAS login
    >itself. This is when the default JAAS entries
    >"com.sun.security.jgss.initiate" and "com.sun.security.jgss.accept" are
    >read from the JAAS configuration file, using the desired configurations
    >that you provide, such as the keytab at the server-end.
    >
    >You can configure JAAS Krb5LoginModule to be an "acceptor" only at the
    >server-end. This option is available starting from Java SE 6, and will
    >be backported to earlier releases.
    >
    >For details on this option, check the javadoc on Krb5LoginModule:
    >http://download.java.net/jdk6/docs/j...ginModule.html
    >
    >Seema
    >
    >Olfmatic wrote On 09/07/06 05:41,:
    >
    >
    >
    >>Hello,
    >>
    >>Please help me, I still don't get it:
    >>I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.
    >>
    >>This is my code:
    >>
    >> Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    >> GSSManager tGSSManager = GSSManager.getInstance();
    >> String tPrincName = "servicename/hostname@REALM";
    >> GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    >> GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    >> GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    >> GSSCredential.ACCEPT_ONLY);
    >> GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    >> byte [] tInToken = aToken;
    >> byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);
    >>
    >>If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    >>But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:
    >>
    >>JaasLogin {
    >> //Kerberos single-sign-on login module
    >> com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    >>};
    >>
    >>
    >>But if i never call
    >>
    >> LoginContext tLoginContext = new LoginContext("JaasLogin");
    >> tLoginContext.login();
    >> final Subject tSubject = tLoginContext.getSubject();
    >>
    >>then how can the application know that it shall use a keytab and where to find it?
    >>
    >>IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    >>IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    >>What do I have to do? Login or no Login?
    >>
    >>Thanks for any help.
    >>
    >>Florian
    >>
    >>________________________________________________
    >>Kerberos mailing list Kerberos@mit.edu
    >>https://mailman.mit.edu/mailman/listinfo/kerberos
    >>
    >>
    >>
    >>



    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. AW: Accepting secure context on Server without KDC-Login

    Hello Seema,

    Sorry, but this is important to me. Let us make this clear:

    JDK 1.4.2:
    Specifying the keytab-file in the LoginModule will make it look there for credentials. But the TGT is obtained from the KDC when login() is called.

    JAVA5:
    Specifying the keytab-file in the LoginModule will make it look there for credentials. If the option isInitiator is set true, it will NOT try to get the TGT from the KDC. No connection to the KDC will be established.
    Is that right?


    The point is, as far as I understand Kerberos, there should be no reason for the server application to call the KDC. So why does it do this? They shared a secret and that's enough to proove authenticity of service tickets. The server application should not need to have the TGT. At least that's what I thought.

    Thanks for your help.
    Florian


    <<<<<<<<<<<<<<<<<<<

    This configuration option in JAAS Krb5LoginModule will be backported to
    JDK 5.0 Update release, and JDK 1.4.2, don't have the exact release
    details available as yet.

    No, server will acquire credentials from the keytab, if you provide the
    configuration option to specify the keytab file. However, the JAAS
    Krb5LoginModule will in addition acquire the TGT.

    Seema


    The default credential acquisition model for Java GSS-API requires
    credentials to be present in the current Subject. Typically, the
    credentials are placed there after a JAAS login by the application.

    Client and server applications typically perform JAAS authentication
    using the Kerberos login module. Upon successful authentication the TGT
    is stored in the Subject's private credentials set and the Kerberos
    principal is stored in the Subject's principal set. At the server-end
    the secret key is stored in the Subject's private credentials set.

    If there are no valid credentials in the current Subject, Java GSS
    provider attempts to obtain new credentials by invoking a JAAS login
    itself. This is when the default JAAS entries
    "com.sun.security.jgss.initiate" and "com.sun.security.jgss.accept" are
    read from the JAAS configuration file, using the desired configurations
    that you provide, such as the keytab at the server-end.

    You can configure JAAS Krb5LoginModule to be an "acceptor" only at the
    server-end. This option is available starting from Java SE 6, and will
    be backported to earlier releases.

    For details on this option, check the javadoc on Krb5LoginModule:
    http://download.java.net/jdk6/docs/j...ginModule.html

    Seema

    Olfmatic wrote On 09/07/06 05:41,:

    >Hello,
    >
    >Please help me, I still don't get it:
    >I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.
    >
    >This is my code:
    >
    > Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    > GSSManager tGSSManager = GSSManager.getInstance();
    > String tPrincName = "servicename/hostname@REALM";
    > GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    > GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    > GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    > GSSCredential.ACCEPT_ONLY);
    > GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    > byte [] tInToken = aToken;
    > byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);
    >
    >If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    >But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:
    >
    >JaasLogin {
    > //Kerberos single-sign-on login module
    > com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    >};
    >
    >
    >But if i never call
    >
    > LoginContext tLoginContext = new LoginContext("JaasLogin");
    > tLoginContext.login();
    > final Subject tSubject = tLoginContext.getSubject();
    >
    >then how can the application know that it shall use a keytab and where to find it?
    >
    >IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    >IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    >What do I have to do? Login or no Login?
    >
    >Thanks for any help.
    >
    >Florian
    >
    >________________________________________________
    >Kerberos mailing list Kerberos@mit.edu
    >https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: AW: Accepting secure context on Server without KDC-Login

    The JAAS Krb5LoginModule allows to generate keys using passwords, which
    is when the server would need to contact the KDC. Currently, the JAAS
    Krb5LoginModule does not make the distinction of client/server, server
    can be an acceptor and initiator i.e. both, hence a TGT is acquired.

    The usage option "isInitiator" allows to distinguish if are want the
    JAAS Krb5LoginModule to be an acceptor only or an initiator/acceptor
    i.e. both.

    Seema

    Olfmatic wrote:

    >Hello Seema,
    >
    >Sorry, but this is important to me. Let us make this clear:
    >
    >JDK 1.4.2:
    >Specifying the keytab-file in the LoginModule will make it look there for credentials. But the TGT is obtained from the KDC when login() is called.
    >
    >JAVA5:
    >Specifying the keytab-file in the LoginModule will make it look there for credentials. If the option isInitiator is set true, it will NOT try to get the TGT from the KDC. No connection to the KDC will be established.
    >Is that right?
    >
    >
    >The point is, as far as I understand Kerberos, there should be no reason for the server application to call the KDC. So why does it do this? They shared a secret and that's enough to proove authenticity of service tickets. The server application should not need to have the TGT. At least that's what I thought.
    >
    >Thanks for your help.
    >Florian
    >
    >
    ><<<<<<<<<<<<<<<<<<<
    >
    >This configuration option in JAAS Krb5LoginModule will be backported to
    >JDK 5.0 Update release, and JDK 1.4.2, don't have the exact release
    >details available as yet.
    >
    >No, server will acquire credentials from the keytab, if you provide the
    >configuration option to specify the keytab file. However, the JAAS
    >Krb5LoginModule will in addition acquire the TGT.
    >
    >Seema
    >
    >
    >The default credential acquisition model for Java GSS-API requires
    >credentials to be present in the current Subject. Typically, the
    >credentials are placed there after a JAAS login by the application.
    >
    >Client and server applications typically perform JAAS authentication
    >using the Kerberos login module. Upon successful authentication the TGT
    >is stored in the Subject's private credentials set and the Kerberos
    >principal is stored in the Subject's principal set. At the server-end
    >the secret key is stored in the Subject's private credentials set.
    >
    >If there are no valid credentials in the current Subject, Java GSS
    >provider attempts to obtain new credentials by invoking a JAAS login
    >itself. This is when the default JAAS entries
    >"com.sun.security.jgss.initiate" and "com.sun.security.jgss.accept" are
    >read from the JAAS configuration file, using the desired configurations
    >that you provide, such as the keytab at the server-end.
    >
    >You can configure JAAS Krb5LoginModule to be an "acceptor" only at the
    >server-end. This option is available starting from Java SE 6, and will
    >be backported to earlier releases.
    >
    >For details on this option, check the javadoc on Krb5LoginModule:
    >http://download.java.net/jdk6/docs/j...ginModule.html
    >
    >Seema
    >
    >Olfmatic wrote On 09/07/06 05:41,:
    >
    >
    >
    >>Hello,
    >>
    >>Please help me, I still don't get it:
    >>I want to accept a secure context on my server. As far as I learned, the server does not have to contact the KDC to do so, because the shared secret is stored in a keytab file created on the KDC and then stored at the server. But I made a different experience.
    >>
    >>This is my code:
    >>
    >> Oid tKrb5Oid = new Oid("1.2.840.113554.1.2.2");
    >> GSSManager tGSSManager = GSSManager.getInstance();
    >> String tPrincName = "servicename/hostname@REALM";
    >> GSSName tServerName = tGSSManager.createName(tPrincName, GSSName.NT_USER_NAME);
    >> GSSCredential tServerCredential = tGSSManager.createCredential(tServerName,
    >> GSSCredential.INDEFINITE_LIFETIME, new Krb5MechFactory().getMechanismOid(),
    >> GSSCredential.ACCEPT_ONLY);
    >> GSSContext tSecureContext = tGSSManager.createContext(tServerName, tKrb5Oid, tServerCredential, GSSContext.DEFAULT_LIFETIME);
    >> byte [] tInToken = aToken;
    >> byte [] tOutToken = tSecureContext.acceptSecContext(tInToken, 0, tInToken.length);
    >>
    >>If I execute this code in a PrivilegedAction after loggin in to the KDC with the Krb5LoginModule, everything is fine. Now what I want is the server to accept the secure context WITHOUT trying to contact the KDC. Do I have to login with the Krb5LoginModule even though? Or can the above code also be executed without prior KDC-Login?
    >>But then how do I tell the server application where to find the keytab file? As far as I know, the keytab file is configured in the configuration of LoginModules:
    >>
    >>JaasLogin {
    >> //Kerberos single-sign-on login module
    >> com.sun.security.auth.module.Krb5LoginModule required debug=true useKeyTab=true keyTab=C:/krb5.keytab ;
    >>};
    >>
    >>
    >>But if i never call
    >>
    >> LoginContext tLoginContext = new LoginContext("JaasLogin");
    >> tLoginContext.login();
    >> final Subject tSubject = tLoginContext.getSubject();
    >>
    >>then how can the application know that it shall use a keytab and where to find it?
    >>
    >>IF I login with the Krb5LoginModule, the server looks for the KDC which is not what I want.
    >>IF I do not login with the Krb5LoginModule, I get the error message "Attempt to obtain new ACCEPT credentials failed", which seems clear to me because the server application doesn't know anything about the keytab file.
    >>What do I have to do? Login or no Login?
    >>
    >>Thanks for any help.
    >>
    >>Florian
    >>
    >>________________________________________________
    >>Kerberos mailing list Kerberos@mit.edu
    >>https://mailman.mit.edu/mailman/listinfo/kerberos
    >>
    >>
    >>
    >>



    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread