Java GSS/Kerberos issue - Autheticating server - Kerberos

This is a discussion on Java GSS/Kerberos issue - Autheticating server - Kerberos ; Hey guys, hopefully someone can help me out here. I am having a problem with authenticating a user to a KDC (I believe the MIT reference implementation) using Java (JDK1.5 and JDK1.4) through GSS. Here is the background: I have ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Java GSS/Kerberos issue - Autheticating server

  1. Java GSS/Kerberos issue - Autheticating server

    Hey guys, hopefully someone can help me out here.

    I am having a problem with authenticating a user to a KDC (I believe
    the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    through GSS.

    Here is the background:

    I have two processes running on one machine (Client and Server).

    1. Client authenticates to kerberos server and logs in, uses the GSS
    libraries to create a service ticket for destination server
    (Authenticates with principal test/admin@realm.com).
    2. Server receives request from client (Through soap transcation).
    Generates a login context and tries to authenticate against the
    kerberos server using test2/admin@realm.com. Server is returned an
    error from the kerberos server (Integrity check on decrypted field
    failed (31) - PREAUTH_FAILED).

    If I configured the client to use the same username/password I can
    authenticate on the client, but no matter what I put in the server it
    fails.

    I don't know the kerberos protocol well enough to know if I can even do
    this (Having the server contact the KDC after a service ticket has been
    issued to the client to authenticate). Is that why I'm getting what
    I've read indicates a password error?


  2. Re: Java GSS/Kerberos issue - Autheticating server

    Such an error "Integrity check on decrypted field failed" is typically
    returned when the password or key used is incorrect.

    Are you using passwords or keytab at the server-side ? Have you setup
    the server to use keytab ? In order to evaluate further, you'll need to
    send me the details.

    Seema

    Laurence wrote On 11/29/05 11:31,:
    > Hey guys, hopefully someone can help me out here.
    >
    > I am having a problem with authenticating a user to a KDC (I believe
    > the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > through GSS.
    >
    > Here is the background:
    >
    > I have two processes running on one machine (Client and Server).
    >
    > 1. Client authenticates to kerberos server and logs in, uses the GSS
    > libraries to create a service ticket for destination server
    > (Authenticates with principal test/admin@realm.com).
    > 2. Server receives request from client (Through soap transcation).
    > Generates a login context and tries to authenticate against the
    > kerberos server using test2/admin@realm.com. Server is returned an
    > error from the kerberos server (Integrity check on decrypted field
    > failed (31) - PREAUTH_FAILED).
    >
    > If I configured the client to use the same username/password I can
    > authenticate on the client, but no matter what I put in the server it
    > fails.
    >
    > I don't know the kerberos protocol well enough to know if I can even do
    > this (Having the server contact the KDC after a service ticket has been
    > issued to the client to authenticate). Is that why I'm getting what
    > I've read indicates a password error?
    >


  3. Re: Java GSS/Kerberos issue - Autheticating server

    Debug is true storeKey false useTicketCache false useKeyTab false
    doNotPrompt false ticketCache is null KeyTab is null refreshKrb5Config
    is false principal is another/admin tryFirstPass is false useFirstPass
    is false storePass is false clearPass is false
    [Krb5LoginModule] user entered username:
    another/admin

    principal is another/admin@REALM.COM
    Acquire TGT using AS Exchange
    EncryptionKey: keyType=3 keyBytes (hex dump)=0000: 6E 98 91 1C 01 C7 1C
    89
    EncryptionKey: keyType=1 keyBytes (hex dump)=0000: 6E 98 91 1C 01 C7 1C
    89
    EncryptionKey: keyType=16 keyBytes (hex dump)=0000: EF 4A 7F DC C2 5B
    45 02 B9 86 9E 37 26 9E C2 92 .J...[E....7&...
    0010: B3 5E 98 37 8C 20 AE 7C
    [Krb5LoginModule] authentication failed
    Integrity check on decrypted field failed (31) - PREAUTH_FAILED
    - Failed to get login context:
    javax.security.auth.login.LoginException: Integrity check on decrypted
    field failed (31) - PREAUTH_FAILED
    org.apache.ws.security.WSSecurityException: The security token could
    not be authenticated or authorized (Failed authentication to Kerberos
    Server)
    at
    org.apache.ws.security.kerberos.GSSAuthorizor.auth orize(GSSAuthorizor.java:112)
    at
    org.apache.ws.security.kerberos.KerberosAuthorizor .authorize(KerberosAuthorizor.java:65)
    at
    org.apache.ws.security.processor.KerberosProcessor .handleToken(KerberosProcessor.java:75)
    at
    org.apache.ws.security.WSSecurityEngine.processSec urityHeader(WSSecurityEngine.java:287)
    at
    org.apache.ws.security.WSSecurityEngine.processSec urityHeader(WSSecurityEngine.java:190)
    at
    org.apache.ws.axis.security.WSDoAllReceiver.invoke (WSDoAllReceiver.java:166)
    at
    org.apache.axis.strategies.InvocationStrategy.visi t(InvocationStrategy.java:32)
    at
    org.apache.axis.SimpleChain.doVisiting(SimpleChain .java:118)
    at org.apache.axis.SimpleChain.invoke(SimpleChain.jav a:83)
    at
    org.apache.axis.strategies.InvocationStrategy.visi t(InvocationStrategy.java:32)
    at
    org.apache.axis.SimpleChain.doVisiting(SimpleChain .java:118)
    at org.apache.axis.SimpleChain.invoke(SimpleChain.jav a:83)
    at
    org.apache.axis.handlers.soap.SOAPService.invoke(S OAPService.java:453)
    at
    org.apache.axis.server.AxisServer.invoke(AxisServe r.java:281)
    at
    org.apache.axis.transport.http.AxisServlet.doPost( AxisServlet.java:699)
    at
    javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
    at
    org.apache.axis.transport.http.AxisServletBase.ser vice(AxisServletBase.java:327)
    at
    javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
    at
    org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
    at
    org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
    at
    org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
    at
    org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
    at
    org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
    at
    org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
    at
    org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
    at
    org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
    at
    org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:868)
    at
    org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.processConnection(Http11BaseProt ocol.java:663)
    at
    org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
    at
    org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
    at
    org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
    at java.lang.Thread.run(Thread.java:595)

    On the same box I run the client side, which looks like:

    Debug is true storeKey false useTicketCache false useKeyTab false
    doNotPrompt false ticketCache is null KeyTab is null refreshKrb5Config
    is false principal is null tryFirstPass is false useFirstPass is false
    storePass is false clearPass is true
    [Krb5LoginModule] user entered username: laurence/admin

    principal is laurence/admin@REALM.COM
    Acquire TGT using AS Exchange
    EncryptionKey: keyType=3 keyBytes (hex dump)=0000: 25 0D A7 B9 89 D5 A2
    CE
    EncryptionKey: keyType=1 keyBytes (hex dump)=0000: 25 0D A7 B9 89 D5 A2
    CE
    EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 3E A1 75 68 C2 CB
    D5 94 0D 32 3B 1C 6D F8 A1 07 >.uh.....2;.m...
    0010: 49 51 16 2A 1A 4A E9 1C
    Commit Succeeded

    Passwords are being used in both cases and if I configure the client to
    authenticate with the servers principal it works fine (From the client
    side). So I know the username/password is correct (At least when I'm
    going to exceute the code).


  4. Re: Java GSS/Kerberos issue - Autheticating server

    It should be noted that I am running JDK1.5 with tomcat 5.5 and the
    tomcat servlet (Through the AXIS SOAP engine) is trying to authenticate
    against the KDC (Using the another/admin@REALM.COM principal).


  5. Re: Java GSS/Kerberos issue - Autheticating server



    Laurence wrote:

    > Hey guys, hopefully someone can help me out here.
    >
    > I am having a problem with authenticating a user to a KDC (I believe
    > the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > through GSS.
    >
    > Here is the background:
    >
    > I have two processes running on one machine (Client and Server).
    >
    > 1. Client authenticates to kerberos server and logs in, uses the GSS
    > libraries to create a service ticket for destination server
    > (Authenticates with principal test/admin@realm.com).
    > 2. Server receives request from client (Through soap transcation).
    > Generates a login context and tries to authenticate against the
    > kerberos server using test2/admin@realm.com. Server is returned an
    > error from the kerberos server (Integrity check on decrypted field
    > failed (31) - PREAUTH_FAILED).


    There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    It has to do with Jave assuming it knows the "salt" to use when generating
    the key from the password. key = fun(passwrod,salt); The salt is based on
    user and realm. Jave assumes that the these have not changed since the
    password was last changed. Windows is also case insensitive but does
    preserve the case of the salt when changing the password.

    So if you have moved an AD account from one domain to another or changed
    the acount name (even the case) and not changed the password you could
    have problems.

    So make sure the case of the principal and the principal is the same
    as when the password for the acount was last changed.


    >
    > If I configured the client to use the same username/password I can
    > authenticate on the client, but no matter what I put in the server it
    > fails.
    >
    > I don't know the kerberos protocol well enough to know if I can even do
    > this (Having the server contact the KDC after a service ticket has been
    > issued to the client to authenticate). Is that why I'm getting what
    > I've read indicates a password error?
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: Java GSS/Kerberos issue - Autheticating server



    Laurence Brockman wrote:

    > I can authenticate as that particular principal in the client portion of the
    > code that I have written using exactly the same case, etc.
    >
    > I have a server and a client portion of code that pass GSS-wrapped kerberos
    > tokens through a SOAP connection


    So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen the
    clint and server. And the server accepts the authentication.


    > and the server is unable to authenticate to
    > the KDC using any credentials (Same error) and the client can authenticate


    Normally the server does not talk to the KDC at all. SO what is it really
    trying to do?

    But the GSSAPI Delegation feature can be used be the client to delegate
    a credential to the server so the server can act as the client. (The client
    gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    for example where the user is logging in as the user.

    > using any credentials.
    >
    > Both use the same code:
    >
    > LoginContext("confName", new PasswordCallbackClass(....,....));


    So where is geting the password? Does the server think the principal
    is that of the user, as the gssapi delegated a TGT to the server?

    > lc.login();
    >
    > Thc lc.login() on the server portion is failing. The server is runnning on
    > my Windows XP devel box and is running as a Tomcat servlet. Any known issues
    > with this type of setup?
    >


    You can run Ethereal on the box, and watch the network traffic. Ethereal
    can format krb5 packets. Very helpfull is cases like this.


    Don't know.

    > Thanks all the help!
    >
    > Laurence
    >
    >
    > On 11/30/05, Douglas E. Engert wrote:
    >
    >>
    >>
    >>Laurence wrote:
    >>
    >>
    >>>Hey guys, hopefully someone can help me out here.
    >>>
    >>>I am having a problem with authenticating a user to a KDC (I believe
    >>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    >>>through GSS.
    >>>
    >>>Here is the background:
    >>>
    >>>I have two processes running on one machine (Client and Server).
    >>>
    >>>1. Client authenticates to kerberos server and logs in, uses the GSS
    >>>libraries to create a service ticket for destination server
    >>>(Authenticates with principal test/admin@realm.com).
    >>>2. Server receives request from client (Through soap transcation).
    >>>Generates a login context and tries to authenticate against the
    >>>kerberos server using test2/admin@realm.com. Server is returned an
    >>>error from the kerberos server (Integrity check on decrypted field
    >>>failed (31) - PREAUTH_FAILED).

    >>
    >>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    >>It has to do with Jave assuming it knows the "salt" to use when generating
    >>the key from the password. key = fun(passwrod,salt); The salt is based on
    >>user and realm. Jave assumes that the these have not changed since the
    >>password was last changed. Windows is also case insensitive but does
    >>preserve the case of the salt when changing the password.
    >>
    >>So if you have moved an AD account from one domain to another or changed
    >>the acount name (even the case) and not changed the password you could
    >>have problems.
    >>
    >>So make sure the case of the principal and the principal is the same
    >>as when the password for the acount was last changed.
    >>
    >>
    >>
    >>>If I configured the client to use the same username/password I can
    >>>authenticate on the client, but no matter what I put in the server it
    >>>fails.
    >>>
    >>>I don't know the kerberos protocol well enough to know if I can even do
    >>>this (Having the server contact the KDC after a service ticket has been
    >>>issued to the client to authenticate). Is that why I'm getting what
    >>>I've read indicates a password error?
    >>>
    >>>________________________________________________
    >>>Kerberos mailing list Kerberos@mit.edu
    >>>https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>
    >>>

    >>
    >>--
    >>
    >>Douglas E. Engert
    >>Argonne National Laboratory
    >>9700 South Cass Avenue
    >>Argonne, Illinois 60439
    >>(630) 252-5444
    >>

    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: Java GSS/Kerberos issue - Autheticating server

    Douglas E. Engert wrote On 11/30/05 08:27,:

    >
    >
    > Laurence wrote:
    >
    >> Hey guys, hopefully someone can help me out here.
    >>
    >> I am having a problem with authenticating a user to a KDC (I believe
    >> the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    >> through GSS.
    >>
    >> Here is the background:
    >>
    >> I have two processes running on one machine (Client and Server).
    >>
    >> 1. Client authenticates to kerberos server and logs in, uses the GSS
    >> libraries to create a service ticket for destination server
    >> (Authenticates with principal test/admin@realm.com).
    >> 2. Server receives request from client (Through soap transcation).
    >> Generates a login context and tries to authenticate against the
    >> kerberos server using test2/admin@realm.com. Server is returned an
    >> error from the kerberos server (Integrity check on decrypted field
    >> failed (31) - PREAUTH_FAILED).

    >
    >
    > There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    > It has to do with Jave assuming it knows the "salt" to use when
    > generating
    > the key from the password. key = fun(passwrod,salt); The salt is based on
    > user and realm. Jave assumes that the these have not changed since the
    > password was last changed. Windows is also case insensitive but does
    > preserve the case of the salt when changing the password.
    >
    > So if you have moved an AD account from one domain to another or changed
    > the acount name (even the case) and not changed the password you could
    > have problems.
    >
    > So make sure the case of the principal and the principal is the same
    > as when the password for the acount was last changed.


    I think we have a different scenario here. If I understand correctly,
    submitter says he can authenticate using same principal/password
    "test2/admin" from the client-side, but cannot use the same
    principal/password from the server-side.

    Laurence, can you try to simple JAAS Kerberos login, and check if you
    can authenticate from the server-side.

    Seema

    >
    >
    >>
    >> If I configured the client to use the same username/password I can
    >> authenticate on the client, but no matter what I put in the server it
    >> fails.
    >>
    >> I don't know the kerberos protocol well enough to know if I can even do
    >> this (Having the server contact the KDC after a service ticket has been
    >> issued to the client to authenticate). Is that why I'm getting what
    >> I've read indicates a password error?
    >>
    >> ________________________________________________
    >> 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


  8. Re: Java GSS/Kerberos issue - Autheticating server

    I can authenticate as that particular principal in the client portion of the
    code that I have written using exactly the same case, etc.

    I have a server and a client portion of code that pass GSS-wrapped kerberos
    tokens through a SOAP connection and the server is unable to authenticate to
    the KDC using any credentials (Same error) and the client can authenticate
    using any credentials.

    Both use the same code:

    LoginContext("confName", new PasswordCallbackClass(....,....));
    lc.login();

    Thc lc.login() on the server portion is failing. The server is runnning on
    my Windows XP devel box and is running as a Tomcat servlet. Any known issues
    with this type of setup?

    Thanks all the help!

    Laurence


    On 11/30/05, Douglas E. Engert wrote:
    >
    >
    >
    > Laurence wrote:
    >
    > > Hey guys, hopefully someone can help me out here.
    > >
    > > I am having a problem with authenticating a user to a KDC (I believe
    > > the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > > through GSS.
    > >
    > > Here is the background:
    > >
    > > I have two processes running on one machine (Client and Server).
    > >
    > > 1. Client authenticates to kerberos server and logs in, uses the GSS
    > > libraries to create a service ticket for destination server
    > > (Authenticates with principal test/admin@realm.com).
    > > 2. Server receives request from client (Through soap transcation).
    > > Generates a login context and tries to authenticate against the
    > > kerberos server using test2/admin@realm.com. Server is returned an
    > > error from the kerberos server (Integrity check on decrypted field
    > > failed (31) - PREAUTH_FAILED).

    >
    > There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    > It has to do with Jave assuming it knows the "salt" to use when generating
    > the key from the password. key = fun(passwrod,salt); The salt is based on
    > user and realm. Jave assumes that the these have not changed since the
    > password was last changed. Windows is also case insensitive but does
    > preserve the case of the salt when changing the password.
    >
    > So if you have moved an AD account from one domain to another or changed
    > the acount name (even the case) and not changed the password you could
    > have problems.
    >
    > So make sure the case of the principal and the principal is the same
    > as when the password for the acount was last changed.
    >
    >
    > >
    > > If I configured the client to use the same username/password I can
    > > authenticate on the client, but no matter what I put in the server it
    > > fails.
    > >
    > > I don't know the kerberos protocol well enough to know if I can even do
    > > this (Having the server contact the KDC after a service ticket has been
    > > issued to the client to authenticate). Is that why I'm getting what
    > > I've read indicates a password error?
    > >
    > > ________________________________________________
    > > Kerberos mailing list Kerberos@mit.edu
    > > https://mailman.mit.edu/mailman/listinfo/kerberos
    > >
    > >

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444
    >

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


  9. Re: Java GSS/Kerberos issue - Autheticating server



    Laurence Brockman wrote:

    > On 11/30/05, Douglas E. Engert wrote:
    >
    >>
    >>
    >>So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen the
    >>clint and server. And the server accepts the authentication.

    >
    >
    >
    > Prior to the server even looking at the packet from the client, it needs to
    > contact the kerberos server to get it's own credentials (GSS Uses these
    > underlying credentials when communicating with the client).


    No.

    See:
    http://java.sun.com/j2se/1.4.2/docs/...le-signon.html


    Credential acquisition on the server side occurs as follows:

    GSSCredential serverCreds =
    manager.createCredential(serverName,
    GSSCredential.INDEFINITE_LIFETIME,
    desiredMechs,
    GSSCredential.ACCEPT_ONLY);

    The behavior is similar to the client case, except that the kind of credential
    requested is one that can accept incoming requests (i.e., a server credential).
    Moreover, servers are typically long lived and like to request a longer lifetime
    for the credentials such as the INDEFINITE_LIFETIME shown here. The Kerberos V5
    mechanism element stored is an instance of a subclass of
    javax.security.auth.kerberos.KerberosKey containing the secret key of the server.

    This step can be an expensive one, and applications generally acquire a reference
    at initialization time to all the credentials they expect to use during their
    lifetime.


    There is an example of the server side later on, with gs name of "nfs@bar.foo.com"
    which when handled by the Kerberos would turn in into principal
    "nfs/bar.foo.com@DEFAULT.REALM"

    >
    >
    >>and the server is unable to authenticate to
    >>
    >>>the KDC using any credentials (Same error) and the client can

    >>
    >>authenticate
    >>
    >>Normally the server does not talk to the KDC at all. SO what is it really
    >>trying to do?

    >
    >
    >
    > I'm refering to the kerberos server that granted the service ticket to the
    > client. My server will need to talk to that server to get it's shared key at
    > some point otherwise it will not be able to verify the ticket the client is
    > sending.
    >
    > But the GSSAPI Delegation feature can be used be the client to delegate
    >
    >>a credential to the server so the server can act as the client. (The
    >>client
    >>gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    >>for example where the user is logging in as the user.
    >>
    >>
    >>>using any credentials.
    >>>
    >>>Both use the same code:
    >>>
    >>>LoginContext("confName", new PasswordCallbackClass(....,....));

    >>
    >>So where is geting the password? Does the server think the principal
    >>is that of the user, as the gssapi delegated a TGT to the server?

    >
    >
    >
    > The principal is manually submitted and the password is returned from the
    > callback class (The call back class is instiated in such a way that it has
    > the password stored on the object and when the method responsible for
    > returning the password is called on the callback class it returns that
    > password (1234567890 in our case). This is the same process that is used on
    > my client and it works no problem (Using the same commands, same principals
    > and same variables).
    >
    >
    >>lc.login();
    >>
    >>>Thc lc.login() on the server portion is failing. The server is runnning

    >>
    >>on
    >>
    >>>my Windows XP devel box and is running as a Tomcat servlet. Any known

    >>
    >>issues
    >>
    >>>with this type of setup?
    >>>

    >>
    >>You can run Ethereal on the box, and watch the network traffic. Ethereal
    >>can format krb5 packets. Very helpfull is cases like this.

    >
    >
    >
    > Yup, this will be the next step.
    >
    > Don't know.
    >
    >>>Thanks all the help!
    >>>
    >>>Laurence
    >>>
    >>>
    >>>On 11/30/05, Douglas E. Engert wrote:
    >>>
    >>>
    >>>>
    >>>>Laurence wrote:
    >>>>
    >>>>
    >>>>
    >>>>>Hey guys, hopefully someone can help me out here.
    >>>>>
    >>>>>I am having a problem with authenticating a user to a KDC (I believe
    >>>>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    >>>>>through GSS.
    >>>>>
    >>>>>Here is the background:
    >>>>>
    >>>>>I have two processes running on one machine (Client and Server).
    >>>>>
    >>>>>1. Client authenticates to kerberos server and logs in, uses the GSS
    >>>>>libraries to create a service ticket for destination server
    >>>>>(Authenticates with principal test/admin@realm.com).
    >>>>>2. Server receives request from client (Through soap transcation).
    >>>>>Generates a login context and tries to authenticate against the
    >>>>>kerberos server using test2/admin@realm.com. Server is returned an
    >>>>>error from the kerberos server (Integrity check on decrypted field
    >>>>>failed (31) - PREAUTH_FAILED).
    >>>>
    >>>>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    >>>>It has to do with Jave assuming it knows the "salt" to use when

    >>
    >>generating
    >>
    >>>>the key from the password. key = fun(passwrod,salt); The salt is based

    >>
    >>on
    >>
    >>>>user and realm. Jave assumes that the these have not changed since the
    >>>>password was last changed. Windows is also case insensitive but does
    >>>>preserve the case of the salt when changing the password.
    >>>>
    >>>>So if you have moved an AD account from one domain to another or changed
    >>>>the acount name (even the case) and not changed the password you could
    >>>>have problems.
    >>>>
    >>>>So make sure the case of the principal and the principal is the same
    >>>>as when the password for the acount was last changed.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>If I configured the client to use the same username/password I can
    >>>>>authenticate on the client, but no matter what I put in the server it
    >>>>>fails.
    >>>>>
    >>>>>I don't know the kerberos protocol well enough to know if I can even do
    >>>>>this (Having the server contact the KDC after a service ticket has been

    >>
    >>>>>issued to the client to authenticate). Is that why I'm getting what
    >>>>>I've read indicates a password error?
    >>>>>
    >>>>>________________________________________________
    >>>>>Kerberos mailing list Kerberos@mit.edu
    >>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>>
    >>>>>
    >>>>
    >>>>--
    >>>>
    >>>>Douglas E. Engert
    >>>>Argonne National Laboratory
    >>>>9700 South Cass Avenue
    >>>>Argonne, Illinois 60439
    >>>>(630) 252-5444
    >>>>
    >>>
    >>>

    >>--
    >>
    >>Douglas E. Engert
    >>Argonne National Laboratory
    >>9700 South Cass Avenue
    >>Argonne, Illinois 60439
    >>(630) 252-5444
    >>

    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  10. Re: Java GSS/Kerberos issue - Autheticating server



    Laurence Brockman wrote:

    > Tried that already too and received:
    >
    > GSSException: GSSException: No valid credentials provided (Mechanism level:
    > Failed to find any Kerberos Key)


    Then you have to get the key into the keytab. This is the way a server works,
    It does not try and get a ticket.

    Figure 2 provides a sample login configuration entry for a server
    application. With this configuration, the secret key from the keytab
    is used to authenticate the principal "nfs/bar.foo.com" and both the TGT
    obtained from the Kerberos KDC and the secret key are stored in the Subject's
    private credentials set. The stored key may be used later to validate a service
    ticket sent by a client (See the section on Java GSS-API.)

    SampleServer {
    com.sun.security.auth.module.Krb5LoginModule
    required useKeyTab=true storeKey=true principal="nfs/bar.foo.com"
    };

    There should be an option above to set the file name. If not, it will use the
    default which is owned by root, and something like /etc/krb5.keytab or
    /etc/krb5/krb5.keytab. (If you server is not run as root, then it should have its
    own keytab.) (If the KDC is a windows AD, then the Microsoft ktpass can be used
    to create the key, and a keytab, that can be copied to your server.)


    Also note well that the @ is used GSS, and is changed
    to a principal /@

    GSSName serverName = manager.createName("nfs@bar.foo.com",
    GSSName.NT_HOSTBASED_SERVICE);

    The Kerberos V5 mechanism would map this name to the Kerberos specific
    form nfs/bar.foo.com@FOO.COM where FOO.COM is the realm of the principal.
    This principal represents the service nfs running on the host machine bar.foo.com.



    >
    > If I don't setup the Kerberos stuff before calling that GSSCredentials I get
    > that error (See code below).
    >
    > GSSManager manager = GSSManager.getInstance();
    > Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    > GSSName serverGSSName = manager.createName(this.serverName, null);
    > GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
    > GSSCredential.INDEFINITE_LIFETIME,
    > kerberos, GSSCredential.ACCEPT_ONLY);
    > this.serverGSSContext = manager.createContext(serverGSSCreds);
    >
    > this.serverName = "another/admin" (The principal that I want to authenticate
    > as).


    No. See the above about the gss name to principal mapping. Its not the admin.
    You need to ge the keytab.

    >
    > Thanks for all the help!
    >
    > Laurence
    >
    > On 11/30/05, Douglas E. Engert wrote:
    >
    >>
    >>
    >>Laurence Brockman wrote:
    >>
    >>
    >>>On 11/30/05, Douglas E. Engert wrote:
    >>>
    >>>
    >>>>
    >>>>So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen

    >>
    >>the
    >>
    >>>>clint and server. And the server accepts the authentication.
    >>>
    >>>
    >>>
    >>>Prior to the server even looking at the packet from the client, it needs

    >>
    >>to
    >>
    >>>contact the kerberos server to get it's own credentials (GSS Uses these
    >>>underlying credentials when communicating with the client).

    >>
    >>No.
    >>
    >>See:
    >>http://java.sun.com/j2se/1.4.2/docs/...le-signon.html
    >>
    >>
    >> Credential acquisition on the server side occurs as follows:
    >>
    >> GSSCredential serverCreds =
    >> manager.createCredential(serverName,
    >> GSSCredential.INDEFINITE_LIFETIME,
    >> desiredMechs,
    >> GSSCredential.ACCEPT_ONLY);
    >>
    >> The behavior is similar to the client case, except that the kind of
    >>credential
    >> requested is one that can accept incoming requests (i.e., a server
    >>credential).
    >> Moreover, servers are typically long lived and like to request a longer
    >>lifetime
    >> for the credentials such as the INDEFINITE_LIFETIME shown here. The
    >>Kerberos V5
    >> mechanism element stored is an instance of a subclass of
    >> javax.security.auth.kerberos.KerberosKey containing the secret key of
    >>the server.
    >>
    >> This step can be an expensive one, and applications generally acquire a
    >>reference
    >> at initialization time to all the credentials they expect to use during
    >>their
    >> lifetime.
    >>
    >>
    >>There is an example of the server side later on, with gs name of "
    >>nfs@bar.foo.com"
    >>which when handled by the Kerberos would turn in into principal
    >>"nfs/bar.foo.com@DEFAULT.REALM"
    >>
    >>
    >>>
    >>>>and the server is unable to authenticate to
    >>>>
    >>>>
    >>>>>the KDC using any credentials (Same error) and the client can
    >>>>
    >>>>authenticate
    >>>>
    >>>>Normally the server does not talk to the KDC at all. SO what is it

    >>
    >>really
    >>
    >>>>trying to do?
    >>>
    >>>
    >>>
    >>>I'm refering to the kerberos server that granted the service ticket to

    >>
    >>the
    >>
    >>>client. My server will need to talk to that server to get it's shared

    >>
    >>key at
    >>
    >>>some point otherwise it will not be able to verify the ticket the client

    >>
    >>is
    >>
    >>>sending.
    >>>
    >>>But the GSSAPI Delegation feature can be used be the client to delegate
    >>>
    >>>
    >>>>a credential to the server so the server can act as the client. (The
    >>>>client
    >>>>gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    >>>>for example where the user is logging in as the user.
    >>>>
    >>>>
    >>>>
    >>>>>using any credentials.
    >>>>>
    >>>>>Both use the same code:
    >>>>>
    >>>>>LoginContext("confName", new PasswordCallbackClass(....,....));
    >>>>
    >>>>So where is geting the password? Does the server think the principal
    >>>>is that of the user, as the gssapi delegated a TGT to the server?
    >>>
    >>>
    >>>
    >>>The principal is manually submitted and the password is returned from

    >>
    >>the
    >>
    >>>callback class (The call back class is instiated in such a way that it

    >>
    >>has
    >>
    >>>the password stored on the object and when the method responsible for
    >>>returning the password is called on the callback class it returns that
    >>>password (1234567890 in our case). This is the same process that is used

    >>
    >>on
    >>
    >>>my client and it works no problem (Using the same commands, same

    >>
    >>principals
    >>
    >>>and same variables).
    >>>
    >>>
    >>>
    >>>>lc.login();
    >>>>
    >>>>
    >>>>>Thc lc.login() on the server portion is failing. The server is runnning
    >>>>
    >>>>on
    >>>>
    >>>>
    >>>>>my Windows XP devel box and is running as a Tomcat servlet. Any known
    >>>>
    >>>>issues
    >>>>
    >>>>
    >>>>>with this type of setup?
    >>>>>
    >>>>
    >>>>You can run Ethereal on the box, and watch the network traffic. Ethereal
    >>>>can format krb5 packets. Very helpfull is cases like this.
    >>>
    >>>
    >>>
    >>>Yup, this will be the next step.
    >>>
    >>>Don't know.
    >>>
    >>>
    >>>>>Thanks all the help!
    >>>>>
    >>>>>Laurence
    >>>>>
    >>>>>
    >>>>>On 11/30/05, Douglas E. Engert wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Laurence wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>Hey guys, hopefully someone can help me out here.
    >>>>>>>
    >>>>>>>I am having a problem with authenticating a user to a KDC (I believe
    >>>>>>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    >>>>>>>through GSS.
    >>>>>>>
    >>>>>>>Here is the background:
    >>>>>>>
    >>>>>>>I have two processes running on one machine (Client and Server).
    >>>>>>>
    >>>>>>>1. Client authenticates to kerberos server and logs in, uses the GSS
    >>>>>>>libraries to create a service ticket for destination server
    >>>>>>>(Authenticates with principal test/admin@realm.com).
    >>>>>>>2. Server receives request from client (Through soap transcation).
    >>>>>>>Generates a login context and tries to authenticate against the
    >>>>>>>kerberos server using test2/admin@realm.com. Server is returned an
    >>>>>>>error from the kerberos server (Integrity check on decrypted field
    >>>>>>>failed (31) - PREAUTH_FAILED).
    >>>>>>
    >>>>>>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I

    >>
    >>believe.)
    >>
    >>>>>>It has to do with Jave assuming it knows the "salt" to use when
    >>>>
    >>>>generating
    >>>>
    >>>>
    >>>>>>the key from the password. key = fun(passwrod,salt); The salt is based
    >>>>
    >>>>on
    >>>>
    >>>>
    >>>>>>user and realm. Jave assumes that the these have not changed since the
    >>>>>>password was last changed. Windows is also case insensitive but does
    >>>>>>preserve the case of the salt when changing the password.
    >>>>>>
    >>>>>>So if you have moved an AD account from one domain to another or

    >>
    >>changed
    >>
    >>>>>>the acount name (even the case) and not changed the password you

    >>
    >>could
    >>
    >>>>>>have problems.
    >>>>>>
    >>>>>>So make sure the case of the principal and the principal is the same
    >>>>>>as when the password for the acount was last changed.
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>If I configured the client to use the same username/password I can
    >>>>>>>authenticate on the client, but no matter what I put in the server it
    >>>>>>>fails.
    >>>>>>>
    >>>>>>>I don't know the kerberos protocol well enough to know if I can even

    >>
    >>do
    >>
    >>>>>>>this (Having the server contact the KDC after a service ticket has

    >>
    >>been
    >>
    >>>>>>>issued to the client to authenticate). Is that why I'm getting what
    >>>>>>>I've read indicates a password error?
    >>>>>>>
    >>>>>>>________________________________________________
    >>>>>>>Kerberos mailing list Kerberos@mit.edu
    >>>>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>>>>
    >>>>>>>
    >>>>>>
    >>>>>>--
    >>>>>>
    >>>>>>Douglas E. Engert
    >>>>>>Argonne National Laboratory
    >>>>>>9700 South Cass Avenue
    >>>>>>Argonne, Illinois 60439
    >>>>>>(630) 252-5444
    >>>>>>
    >>>>>
    >>>>>
    >>>>--
    >>>>
    >>>>Douglas E. Engert
    >>>>Argonne National Laboratory
    >>>>9700 South Cass Avenue
    >>>>Argonne, Illinois 60439
    >>>>(630) 252-5444
    >>>>
    >>>
    >>>

    >>--
    >>
    >>Douglas E. Engert
    >>Argonne National Laboratory
    >>9700 South Cass Avenue
    >>Argonne, Illinois 60439
    >>(630) 252-5444
    >>

    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  11. Re: Java GSS/Kerberos issue - Autheticating server

    Tried that already too and received:

    GSSException: GSSException: No valid credentials provided (Mechanism level:
    Failed to find any Kerberos Key)

    If I don't setup the Kerberos stuff before calling that GSSCredentials I get
    that error (See code below).

    GSSManager manager = GSSManager.getInstance();
    Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    GSSName serverGSSName = manager.createName(this.serverName, null);
    GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
    GSSCredential.INDEFINITE_LIFETIME,
    kerberos, GSSCredential.ACCEPT_ONLY);
    this.serverGSSContext = manager.createContext(serverGSSCreds);

    this.serverName = "another/admin" (The principal that I want to authenticate
    as).

    Thanks for all the help!

    Laurence

    On 11/30/05, Douglas E. Engert wrote:
    >
    >
    >
    > Laurence Brockman wrote:
    >
    > > On 11/30/05, Douglas E. Engert wrote:
    > >
    > >>
    > >>
    > >>So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen

    > the
    > >>clint and server. And the server accepts the authentication.

    > >
    > >
    > >
    > > Prior to the server even looking at the packet from the client, it needs

    > to
    > > contact the kerberos server to get it's own credentials (GSS Uses these
    > > underlying credentials when communicating with the client).

    >
    > No.
    >
    > See:
    > http://java.sun.com/j2se/1.4.2/docs/...le-signon.html
    >
    >
    > Credential acquisition on the server side occurs as follows:
    >
    > GSSCredential serverCreds =
    > manager.createCredential(serverName,
    > GSSCredential.INDEFINITE_LIFETIME,
    > desiredMechs,
    > GSSCredential.ACCEPT_ONLY);
    >
    > The behavior is similar to the client case, except that the kind of
    > credential
    > requested is one that can accept incoming requests (i.e., a server
    > credential).
    > Moreover, servers are typically long lived and like to request a longer
    > lifetime
    > for the credentials such as the INDEFINITE_LIFETIME shown here. The
    > Kerberos V5
    > mechanism element stored is an instance of a subclass of
    > javax.security.auth.kerberos.KerberosKey containing the secret key of
    > the server.
    >
    > This step can be an expensive one, and applications generally acquire a
    > reference
    > at initialization time to all the credentials they expect to use during
    > their
    > lifetime.
    >
    >
    > There is an example of the server side later on, with gs name of "
    > nfs@bar.foo.com"
    > which when handled by the Kerberos would turn in into principal
    > "nfs/bar.foo.com@DEFAULT.REALM"
    >
    > >
    > >
    > >>and the server is unable to authenticate to
    > >>
    > >>>the KDC using any credentials (Same error) and the client can
    > >>
    > >>authenticate
    > >>
    > >>Normally the server does not talk to the KDC at all. SO what is it

    > really
    > >>trying to do?

    > >
    > >
    > >
    > > I'm refering to the kerberos server that granted the service ticket to

    > the
    > > client. My server will need to talk to that server to get it's shared

    > key at
    > > some point otherwise it will not be able to verify the ticket the client

    > is
    > > sending.
    > >
    > > But the GSSAPI Delegation feature can be used be the client to delegate
    > >
    > >>a credential to the server so the server can act as the client. (The
    > >>client
    > >>gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    > >>for example where the user is logging in as the user.
    > >>
    > >>
    > >>>using any credentials.
    > >>>
    > >>>Both use the same code:
    > >>>
    > >>>LoginContext("confName", new PasswordCallbackClass(....,....));
    > >>
    > >>So where is geting the password? Does the server think the principal
    > >>is that of the user, as the gssapi delegated a TGT to the server?

    > >
    > >
    > >
    > > The principal is manually submitted and the password is returned from

    > the
    > > callback class (The call back class is instiated in such a way that it

    > has
    > > the password stored on the object and when the method responsible for
    > > returning the password is called on the callback class it returns that
    > > password (1234567890 in our case). This is the same process that is used

    > on
    > > my client and it works no problem (Using the same commands, same

    > principals
    > > and same variables).
    > >
    > >
    > >>lc.login();
    > >>
    > >>>Thc lc.login() on the server portion is failing. The server is runnning
    > >>
    > >>on
    > >>
    > >>>my Windows XP devel box and is running as a Tomcat servlet. Any known
    > >>
    > >>issues
    > >>
    > >>>with this type of setup?
    > >>>
    > >>
    > >>You can run Ethereal on the box, and watch the network traffic. Ethereal
    > >>can format krb5 packets. Very helpfull is cases like this.

    > >
    > >
    > >
    > > Yup, this will be the next step.
    > >
    > > Don't know.
    > >
    > >>>Thanks all the help!
    > >>>
    > >>>Laurence
    > >>>
    > >>>
    > >>>On 11/30/05, Douglas E. Engert wrote:
    > >>>
    > >>>
    > >>>>
    > >>>>Laurence wrote:
    > >>>>
    > >>>>
    > >>>>
    > >>>>>Hey guys, hopefully someone can help me out here.
    > >>>>>
    > >>>>>I am having a problem with authenticating a user to a KDC (I believe
    > >>>>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > >>>>>through GSS.
    > >>>>>
    > >>>>>Here is the background:
    > >>>>>
    > >>>>>I have two processes running on one machine (Client and Server).
    > >>>>>
    > >>>>>1. Client authenticates to kerberos server and logs in, uses the GSS
    > >>>>>libraries to create a service ticket for destination server
    > >>>>>(Authenticates with principal test/admin@realm.com).
    > >>>>>2. Server receives request from client (Through soap transcation).
    > >>>>>Generates a login context and tries to authenticate against the
    > >>>>>kerberos server using test2/admin@realm.com. Server is returned an
    > >>>>>error from the kerberos server (Integrity check on decrypted field
    > >>>>>failed (31) - PREAUTH_FAILED).
    > >>>>
    > >>>>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I

    > believe.)
    > >>>>It has to do with Jave assuming it knows the "salt" to use when
    > >>
    > >>generating
    > >>
    > >>>>the key from the password. key = fun(passwrod,salt); The salt is based
    > >>
    > >>on
    > >>
    > >>>>user and realm. Jave assumes that the these have not changed since the
    > >>>>password was last changed. Windows is also case insensitive but does
    > >>>>preserve the case of the salt when changing the password.
    > >>>>
    > >>>>So if you have moved an AD account from one domain to another or

    > changed
    > >>>>the acount name (even the case) and not changed the password you

    > could
    > >>>>have problems.
    > >>>>
    > >>>>So make sure the case of the principal and the principal is the same
    > >>>>as when the password for the acount was last changed.
    > >>>>
    > >>>>
    > >>>>
    > >>>>
    > >>>>>If I configured the client to use the same username/password I can
    > >>>>>authenticate on the client, but no matter what I put in the server it
    > >>>>>fails.
    > >>>>>
    > >>>>>I don't know the kerberos protocol well enough to know if I can even

    > do
    > >>>>>this (Having the server contact the KDC after a service ticket has

    > been
    > >>
    > >>>>>issued to the client to authenticate). Is that why I'm getting what
    > >>>>>I've read indicates a password error?
    > >>>>>
    > >>>>>________________________________________________
    > >>>>>Kerberos mailing list Kerberos@mit.edu
    > >>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
    > >>>>>
    > >>>>>
    > >>>>
    > >>>>--
    > >>>>
    > >>>>Douglas E. Engert
    > >>>>Argonne National Laboratory
    > >>>>9700 South Cass Avenue
    > >>>>Argonne, Illinois 60439
    > >>>>(630) 252-5444
    > >>>>
    > >>>
    > >>>
    > >>--
    > >>
    > >>Douglas E. Engert
    > >>Argonne National Laboratory
    > >>9700 South Cass Avenue
    > >>Argonne, Illinois 60439
    > >>(630) 252-5444
    > >>

    > >
    > >

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444
    >

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


  12. Re: Java GSS/Kerberos issue - Autheticating server

    On 11/30/05, Douglas E. Engert wrote:
    >
    >
    >
    > So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen the
    > clint and server. And the server accepts the authentication.



    Prior to the server even looking at the packet from the client, it needs to
    contact the kerberos server to get it's own credentials (GSS Uses these
    underlying credentials when communicating with the client).

    > and the server is unable to authenticate to
    > > the KDC using any credentials (Same error) and the client can

    > authenticate
    >
    > Normally the server does not talk to the KDC at all. SO what is it really
    > trying to do?



    I'm refering to the kerberos server that granted the service ticket to the
    client. My server will need to talk to that server to get it's shared key at
    some point otherwise it will not be able to verify the ticket the client is
    sending.

    But the GSSAPI Delegation feature can be used be the client to delegate
    > a credential to the server so the server can act as the client. (The
    > client
    > gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    > for example where the user is logging in as the user.
    >
    > > using any credentials.
    > >
    > > Both use the same code:
    > >
    > > LoginContext("confName", new PasswordCallbackClass(....,....));

    >
    > So where is geting the password? Does the server think the principal
    > is that of the user, as the gssapi delegated a TGT to the server?



    The principal is manually submitted and the password is returned from the
    callback class (The call back class is instiated in such a way that it has
    the password stored on the object and when the method responsible for
    returning the password is called on the callback class it returns that
    password (1234567890 in our case). This is the same process that is used on
    my client and it works no problem (Using the same commands, same principals
    and same variables).

    > lc.login();
    > >
    > > Thc lc.login() on the server portion is failing. The server is runnning

    > on
    > > my Windows XP devel box and is running as a Tomcat servlet. Any known

    > issues
    > > with this type of setup?
    > >

    >
    > You can run Ethereal on the box, and watch the network traffic. Ethereal
    > can format krb5 packets. Very helpfull is cases like this.



    Yup, this will be the next step.

    Don't know.
    >
    > > Thanks all the help!
    > >
    > > Laurence
    > >
    > >
    > > On 11/30/05, Douglas E. Engert wrote:
    > >
    > >>
    > >>
    > >>Laurence wrote:
    > >>
    > >>
    > >>>Hey guys, hopefully someone can help me out here.
    > >>>
    > >>>I am having a problem with authenticating a user to a KDC (I believe
    > >>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > >>>through GSS.
    > >>>
    > >>>Here is the background:
    > >>>
    > >>>I have two processes running on one machine (Client and Server).
    > >>>
    > >>>1. Client authenticates to kerberos server and logs in, uses the GSS
    > >>>libraries to create a service ticket for destination server
    > >>>(Authenticates with principal test/admin@realm.com).
    > >>>2. Server receives request from client (Through soap transcation).
    > >>>Generates a login context and tries to authenticate against the
    > >>>kerberos server using test2/admin@realm.com. Server is returned an
    > >>>error from the kerberos server (Integrity check on decrypted field
    > >>>failed (31) - PREAUTH_FAILED).
    > >>
    > >>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    > >>It has to do with Jave assuming it knows the "salt" to use when

    > generating
    > >>the key from the password. key = fun(passwrod,salt); The salt is based

    > on
    > >>user and realm. Jave assumes that the these have not changed since the
    > >>password was last changed. Windows is also case insensitive but does
    > >>preserve the case of the salt when changing the password.
    > >>
    > >>So if you have moved an AD account from one domain to another or changed
    > >>the acount name (even the case) and not changed the password you could
    > >>have problems.
    > >>
    > >>So make sure the case of the principal and the principal is the same
    > >>as when the password for the acount was last changed.
    > >>
    > >>
    > >>
    > >>>If I configured the client to use the same username/password I can
    > >>>authenticate on the client, but no matter what I put in the server it
    > >>>fails.
    > >>>
    > >>>I don't know the kerberos protocol well enough to know if I can even do
    > >>>this (Having the server contact the KDC after a service ticket has been

    >
    > >>>issued to the client to authenticate). Is that why I'm getting what
    > >>>I've read indicates a password error?
    > >>>
    > >>>________________________________________________
    > >>>Kerberos mailing list Kerberos@mit.edu
    > >>>https://mailman.mit.edu/mailman/listinfo/kerberos
    > >>>
    > >>>
    > >>
    > >>--
    > >>
    > >>Douglas E. Engert
    > >>Argonne National Laboratory
    > >>9700 South Cass Avenue
    > >>Argonne, Illinois 60439
    > >>(630) 252-5444
    > >>

    > >
    > >

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444
    >

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


  13. Re: Java GSS/Kerberos issue - Autheticating server

    The server is running on the same machine as the client.

    I have one development box running.

    Server is running as a tomcat servlet (Utilizing Apache's Axis SOAP
    interface). The client contacts the kerberos server, grabs the appropriate
    ticket and uses the GSS API to generate a ticket. The client then MD5's the
    service ticket and inserts that into the SOAP header (Using the OASIS spec
    released on Nov 7) in the form of a BinarySecurityToken element. The server
    receives the request, contacts the kerberos server to authenticate itself.
    The server portion creates a login context (The Password callback is just a
    simple class that has two local variables, username and password, and when
    the appropriate method is returned, the username is returned and the
    password is returned for the appropriate method -- The same callback class
    as the client).

    After the login context has been created the lc.login() method is called.
    This method throws an exception and the server process returns an exception
    to the calling SOAP request because the authentication has failed.

    I have been basing my code on IBM's paper entilied "Simplify enterprise
    Java authentication with single sign-on" published on Sep 9, 2003 (For the
    kerberos/GSS specific stuff).

    Is this even the appropriate process to be going through on the server side?
    Looking at the SampleServer.java code from Sun it doesn't even look like the
    LoginContext/LoginContext.login() method's get called (Maybe replaced with
    GSSManager.createContext()?).

    I'm open to the idea that I'm doing this completely wrong on the server
    side... I'm brand new to kerberos and basically what we need to have happen
    is the SOAP Server verify that the user has appropriate access to the SOAP
    service method (As defined in the kerberos server). EG.
    webservermethod/soapservice.company.com@company.com. Am I going about this
    the wrong way?

    On 11/30/05, Seema Malkani wrote:
    >
    > Douglas E. Engert wrote On 11/30/05 08:27,:
    >
    > >
    > >
    > > Laurence wrote:
    > >
    > >> Hey guys, hopefully someone can help me out here.
    > >>
    > >> I am having a problem with authenticating a user to a KDC (I believe
    > >> the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > >> through GSS.
    > >>
    > >> Here is the background:
    > >>
    > >> I have two processes running on one machine (Client and Server).
    > >>
    > >> 1. Client authenticates to kerberos server and logs in, uses the GSS
    > >> libraries to create a service ticket for destination server
    > >> (Authenticates with principal test/admin@realm.com).
    > >> 2. Server receives request from client (Through soap transcation).
    > >> Generates a login context and tries to authenticate against the
    > >> kerberos server using test2/admin@realm.com. Server is returned an
    > >> error from the kerberos server (Integrity check on decrypted field
    > >> failed (31) - PREAUTH_FAILED).

    > >
    > >
    > > There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I believe.)
    > > It has to do with Jave assuming it knows the "salt" to use when
    > > generating
    > > the key from the password. key = fun(passwrod,salt); The salt is based

    > on
    > > user and realm. Jave assumes that the these have not changed since the
    > > password was last changed. Windows is also case insensitive but does
    > > preserve the case of the salt when changing the password.
    > >
    > > So if you have moved an AD account from one domain to another or changed
    > > the acount name (even the case) and not changed the password you could
    > > have problems.
    > >
    > > So make sure the case of the principal and the principal is the same
    > > as when the password for the acount was last changed.

    >
    > I think we have a different scenario here. If I understand correctly,
    > submitter says he can authenticate using same principal/password
    > "test2/admin" from the client-side, but cannot use the same
    > principal/password from the server-side.
    >
    > Laurence, can you try to simple JAAS Kerberos login, and check if you
    > can authenticate from the server-side.
    >
    > Seema
    >
    > >
    > >
    > >>
    > >> If I configured the client to use the same username/password I can
    > >> authenticate on the client, but no matter what I put in the server it
    > >> fails.
    > >>
    > >> I don't know the kerberos protocol well enough to know if I can even do
    > >> this (Having the server contact the KDC after a service ticket has been

    >
    > >> issued to the client to authenticate). Is that why I'm getting what
    > >> I've read indicates a password error?
    > >>
    > >> ________________________________________________
    > >> 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


  14. Re: Java GSS/Kerberos issue - Autheticating server

    If I do not try and use the lc.login() method and instead try to pull from
    the /etc/krb5.keytab file then I get the below error:

    10988 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - Setting Realm/KDC/Config to
    BWOO.COM/10.0.78.20//tmp/jaas.conf
    10988 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - In the run() method.
    10988 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - java.security.krb5.realm:
    BWOO.COM
    10988 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - java.security.krb5.kdc:
    10.0.78.20
    10988 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor -
    java.security.auth.login.config: /tmp/jaas.conf
    10988 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor -
    javax.security.auth.useSubjectCredsOnly: false
    10991 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - Got instance:
    sun.security.jgss.GSSManagerImpl@15d616e
    10991 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - Got kerberos:
    1.2.840.113554.1.2.2
    10991 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - Going to get a Name for
    another@admin : 1.2.840.113554.1.2.1.1
    10994 [http-8080-Processor25] DEBUG
    org.apache.ws.security.kerberos.GSSAuthorizor - Got Name: another@admin
    11004 [http-8080-Processor25] ERROR
    org.apache.ws.security.kerberos.GSSAuthorizor - GSSException: GSSException:
    No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT
    credentials failed!)

    [root@localhost laurence]# more /tmp/jaas.conf
    /** Login Configuration
    **/
    JaasServer {
    com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true
    storeKey=true keyTab="/etc/krb5.keytab";
    };

    *Code from GSSAuthorizor:*

    GSSManager manager = GSSManager.getInstance();
    Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    this.serverName = "another@admin";
    GSSName serverGSSName = manager.createName(this.serverName,
    GSSName.NT_USER_NAME);
    GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
    GSSCredential.INDEFINITE_LIFETIME,
    kerberos, GSSCredential.ACCEPT_ONLY);
    log.debug("Created credentials for the service");


    [root@localhost laurence]# /usr/java/jdk1.5.0_06/bin/klist -k
    FILE:/etc/krb5.keytab

    Key tab: FILE:/etc/krb5.keytab, 4 entries found.

    [1] Service principal: another/admin@BWOO.COM
    KVNO: 2
    [2] Service principal: another/admin@BWOO.COM
    KVNO: 2
    [3] Service principal: another/admin@BWOO.COM
    KVNO: 2
    [4] Service principal: another/admin@BWOO.COM
    KVNO: 2

    I have no idea what that error means. I have pointed it to the keytab file,
    the keytab file has the Service Principal for another/admin@BWOO.COM as
    indicated above and it still does not find it.

    Any help would be greatly appreciated. I do not have a policy file, does
    this need to be added?

    Laurence
    On 12/1/05, Douglas E. Engert wrote:
    >
    >
    >
    > Laurence Brockman wrote:
    >
    > > Tried that already too and received:
    > >
    > > GSSException: GSSException: No valid credentials provided (Mechanism

    > level:
    > > Failed to find any Kerberos Key)

    >
    > Then you have to get the key into the keytab. This is the way a server
    > works,
    > It does not try and get a ticket.
    >
    > Figure 2 provides a sample login configuration entry for a server
    > application. With this configuration, the secret key from the keytab
    > is used to authenticate the principal "nfs/bar.foo.com" and both the TGT
    > obtained from the Kerberos KDC and the secret key are stored in the
    > Subject's
    > private credentials set. The stored key may be used later to validate a
    > service
    > ticket sent by a client (See the section on Java GSS-API.)
    >
    > SampleServer {
    > com.sun.security.auth.module.Krb5LoginModule
    > required useKeyTab=true storeKey=true
    > principal="nfs/bar.foo.com"
    > };
    >
    > There should be an option above to set the file name. If not, it will use
    > the
    > default which is owned by root, and something like /etc/krb5.keytab or
    > /etc/krb5/krb5.keytab. (If you server is not run as root, then it should
    > have its
    > own keytab.) (If the KDC is a windows AD, then the Microsoft ktpass can be
    > used
    > to create the key, and a keytab, that can be copied to your server.)
    >
    >
    > Also note well that the @ is used GSS, and is changed
    > to a principal /@
    >
    > GSSName serverName = manager.createName("nfs@bar.foo.com",
    > GSSName.NT_HOSTBASED_SERVICE);
    >
    > The Kerberos V5 mechanism would map this name to the Kerberos specific
    > form nfs/bar.foo.com@FOO.COM where FOO.COM is the realm of the
    > principal.
    > This principal represents the service nfs running on the host machine
    > bar.foo.com.
    >
    >
    >
    > >
    > > If I don't setup the Kerberos stuff before calling that GSSCredentials I

    > get
    > > that error (See code below).
    > >
    > > GSSManager manager = GSSManager.getInstance();
    > > Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    > > GSSName serverGSSName = manager.createName(this.serverName, null);
    > > GSSCredential serverGSSCreds = manager.createCredential

    > (serverGSSName,
    > > GSSCredential.INDEFINITE_LIFETIME,
    > > kerberos, GSSCredential.ACCEPT_ONLY);
    > > this.serverGSSContext = manager.createContext(serverGSSCreds);
    > >
    > > this.serverName = "another/admin" (The principal that I want to

    > authenticate
    > > as).

    >
    > No. See the above about the gss name to principal mapping. Its not the
    > admin.
    > You need to ge the keytab.
    >
    > >
    > > Thanks for all the help!
    > >
    > > Laurence
    > >
    > > On 11/30/05, Douglas E. Engert wrote:
    > >
    > >>
    > >>
    > >>Laurence Brockman wrote:
    > >>
    > >>
    > >>>On 11/30/05, Douglas E. Engert wrote:
    > >>>
    > >>>
    > >>>>
    > >>>>So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen
    > >>
    > >>the
    > >>
    > >>>>clint and server. And the server accepts the authentication.
    > >>>
    > >>>
    > >>>
    > >>>Prior to the server even looking at the packet from the client, it

    > needs
    > >>
    > >>to
    > >>
    > >>>contact the kerberos server to get it's own credentials (GSS Uses these
    > >>>underlying credentials when communicating with the client).
    > >>
    > >>No.
    > >>
    > >>See:
    > >>

    > http://java.sun.com/j2se/1.4.2/docs/...le-signon.html
    > >>
    > >>
    > >> Credential acquisition on the server side occurs as follows:
    > >>
    > >> GSSCredential serverCreds =
    > >> manager.createCredential(serverName,
    > >> GSSCredential.INDEFINITE_LIFETIME,
    > >> desiredMechs,
    > >> GSSCredential.ACCEPT_ONLY);
    > >>
    > >> The behavior is similar to the client case, except that the kind of
    > >>credential
    > >> requested is one that can accept incoming requests (i.e., a server
    > >>credential).
    > >> Moreover, servers are typically long lived and like to request a

    > longer
    > >>lifetime
    > >> for the credentials such as the INDEFINITE_LIFETIME shown here. The
    > >>Kerberos V5
    > >> mechanism element stored is an instance of a subclass of
    > >> javax.security.auth.kerberos.KerberosKey containing the secret key of
    > >>the server.
    > >>
    > >> This step can be an expensive one, and applications generally acquire

    > a
    > >>reference
    > >> at initialization time to all the credentials they expect to use

    > during
    > >>their
    > >> lifetime.
    > >>
    > >>
    > >>There is an example of the server side later on, with gs name of "
    > >>nfs@bar.foo.com"
    > >>which when handled by the Kerberos would turn in into principal
    > >>"nfs/bar.foo.com@DEFAULT.REALM"
    > >>
    > >>
    > >>>
    > >>>>and the server is unable to authenticate to
    > >>>>
    > >>>>
    > >>>>>the KDC using any credentials (Same error) and the client can
    > >>>>
    > >>>>authenticate
    > >>>>
    > >>>>Normally the server does not talk to the KDC at all. SO what is it
    > >>
    > >>really
    > >>
    > >>>>trying to do?
    > >>>
    > >>>
    > >>>
    > >>>I'm refering to the kerberos server that granted the service ticket to
    > >>
    > >>the
    > >>
    > >>>client. My server will need to talk to that server to get it's shared
    > >>
    > >>key at
    > >>
    > >>>some point otherwise it will not be able to verify the ticket the

    > client
    > >>
    > >>is
    > >>
    > >>>sending.
    > >>>
    > >>>But the GSSAPI Delegation feature can be used be the client to delegate
    > >>>
    > >>>
    > >>>>a credential to the server so the server can act as the client. (The
    > >>>>client
    > >>>>gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    > >>>>for example where the user is logging in as the user.
    > >>>>
    > >>>>
    > >>>>
    > >>>>>using any credentials.
    > >>>>>
    > >>>>>Both use the same code:
    > >>>>>
    > >>>>>LoginContext("confName", new PasswordCallbackClass(....,....));
    > >>>>
    > >>>>So where is geting the password? Does the server think the principal
    > >>>>is that of the user, as the gssapi delegated a TGT to the server?
    > >>>
    > >>>
    > >>>
    > >>>The principal is manually submitted and the password is returned from
    > >>
    > >>the
    > >>
    > >>>callback class (The call back class is instiated in such a way that it
    > >>
    > >>has
    > >>
    > >>>the password stored on the object and when the method responsible for
    > >>>returning the password is called on the callback class it returns that
    > >>>password (1234567890 in our case). This is the same process that is

    > used
    > >>
    > >>on
    > >>
    > >>>my client and it works no problem (Using the same commands, same
    > >>
    > >>principals
    > >>
    > >>>and same variables).
    > >>>
    > >>>
    > >>>
    > >>>>lc.login();
    > >>>>
    > >>>>
    > >>>>>Thc lc.login() on the server portion is failing. The server is

    > runnning
    > >>>>
    > >>>>on
    > >>>>
    > >>>>
    > >>>>>my Windows XP devel box and is running as a Tomcat servlet. Any known
    > >>>>
    > >>>>issues
    > >>>>
    > >>>>
    > >>>>>with this type of setup?
    > >>>>>
    > >>>>
    > >>>>You can run Ethereal on the box, and watch the network traffic.

    > Ethereal
    > >>>>can format krb5 packets. Very helpfull is cases like this.
    > >>>
    > >>>
    > >>>
    > >>>Yup, this will be the next step.
    > >>>
    > >>>Don't know.
    > >>>
    > >>>
    > >>>>>Thanks all the help!
    > >>>>>
    > >>>>>Laurence
    > >>>>>
    > >>>>>
    > >>>>>On 11/30/05, Douglas E. Engert wrote:
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>>>Laurence wrote:
    > >>>>>>
    > >>>>>>
    > >>>>>>
    > >>>>>>
    > >>>>>>>Hey guys, hopefully someone can help me out here.
    > >>>>>>>
    > >>>>>>>I am having a problem with authenticating a user to a KDC (I

    > believe
    > >>>>>>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    > >>>>>>>through GSS.
    > >>>>>>>
    > >>>>>>>Here is the background:
    > >>>>>>>
    > >>>>>>>I have two processes running on one machine (Client and Server).
    > >>>>>>>
    > >>>>>>>1. Client authenticates to kerberos server and logs in, uses the

    > GSS
    > >>>>>>>libraries to create a service ticket for destination server
    > >>>>>>>(Authenticates with principal test/admin@realm.com).
    > >>>>>>>2. Server receives request from client (Through soap transcation).
    > >>>>>>>Generates a login context and tries to authenticate against the
    > >>>>>>>kerberos server using test2/admin@realm.com. Server is returned an
    > >>>>>>>error from the kerberos server (Integrity check on decrypted field
    > >>>>>>>failed (31) - PREAUTH_FAILED).
    > >>>>>>
    > >>>>>>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I
    > >>
    > >>believe.)
    > >>
    > >>>>>>It has to do with Jave assuming it knows the "salt" to use when
    > >>>>
    > >>>>generating
    > >>>>
    > >>>>
    > >>>>>>the key from the password. key = fun(passwrod,salt); The salt is

    > based
    > >>>>
    > >>>>on
    > >>>>
    > >>>>
    > >>>>>>user and realm. Jave assumes that the these have not changed since

    > the
    > >>>>>>password was last changed. Windows is also case insensitive but does
    > >>>>>>preserve the case of the salt when changing the password.
    > >>>>>>
    > >>>>>>So if you have moved an AD account from one domain to another or
    > >>
    > >>changed
    > >>
    > >>>>>>the acount name (even the case) and not changed the password you
    > >>
    > >>could
    > >>
    > >>>>>>have problems.
    > >>>>>>
    > >>>>>>So make sure the case of the principal and the principal is the same
    > >>>>>>as when the password for the acount was last changed.
    > >>>>>>
    > >>>>>>
    > >>>>>>
    > >>>>>>
    > >>>>>>
    > >>>>>>>If I configured the client to use the same username/password I can
    > >>>>>>>authenticate on the client, but no matter what I put in the server

    > it
    > >>>>>>>fails.
    > >>>>>>>
    > >>>>>>>I don't know the kerberos protocol well enough to know if I can

    > even
    > >>
    > >>do
    > >>
    > >>>>>>>this (Having the server contact the KDC after a service ticket has
    > >>
    > >>been
    > >>
    > >>>>>>>issued to the client to authenticate). Is that why I'm getting what
    > >>>>>>>I've read indicates a password error?
    > >>>>>>>
    > >>>>>>>________________________________________________
    > >>>>>>>Kerberos mailing list Kerberos@mit.edu
    > >>>>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
    > >>>>>>>
    > >>>>>>>
    > >>>>>>
    > >>>>>>--
    > >>>>>>
    > >>>>>>Douglas E. Engert
    > >>>>>>Argonne National Laboratory
    > >>>>>>9700 South Cass Avenue
    > >>>>>>Argonne, Illinois 60439
    > >>>>>>(630) 252-5444
    > >>>>>>
    > >>>>>
    > >>>>>
    > >>>>--
    > >>>>
    > >>>>Douglas E. Engert
    > >>>>Argonne National Laboratory
    > >>>>9700 South Cass Avenue
    > >>>>Argonne, Illinois 60439
    > >>>>(630) 252-5444
    > >>>>
    > >>>
    > >>>
    > >>--
    > >>
    > >>Douglas E. Engert
    > >>Argonne National Laboratory
    > >>9700 South Cass Avenue
    > >>Argonne, Illinois 60439
    > >>(630) 252-5444
    > >>

    > >
    > >

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444
    >

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


  15. Re: Java GSS/Kerberos issue - Autheticating server

    I think your problem is in the use of the createName.
    Normally a services uses a Kerbeors principal of /@
    You are trying to use a user principal another/admin@BWOO.COM

    The use of the @ when calling the createName is not the same
    as used in a Kerberos principal. (GSS is generic, and can handle
    mechanisum names that are not Kerberos.) As far as I know, there is no
    way to pass in the realm of the user or client to GSS at this time.
    The IETF Kitten group doies a a proposal on how to do this

    See:
    http://www.ietf.org/html.charters/kitten-charter.html
    and
    http://www.ietf.org/internet-drafts/...d-names-01.txt


    I beleieve the @ is treated special by createName only when called with
    the GSSName.NT_HOSTBASED_SERVICE. In this case is seperates the service
    from the host.

    See:
    http://java.sun.com/j2se/1.4.2/docs/...s/GSSName.html

    If you call it with GSSName.NT_USER_NAME and it looks like it treated
    the @ as part of the name. Note the " Got Name: another@admin" below.
    So if you want to use GSSName.NT_USER_NAME you may want to try
    "another/admin"

    But you should also look at a at based approach
    which is much more standard.


    Laurence Brockman wrote:

    > If I do not try and use the lc.login() method and instead try to pull from
    > the /etc/krb5.keytab file then I get the below error:
    >
    > 10988 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - Setting Realm/KDC/Config to
    > BWOO.COM/10.0.78.20//tmp/jaas.conf
    > 10988 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - In the run() method.
    > 10988 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - java.security.krb5.realm:
    > BWOO.COM
    > 10988 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - java.security.krb5.kdc:
    > 10.0.78.20
    > 10988 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor -
    > java.security.auth.login.config: /tmp/jaas.conf
    > 10988 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor -
    > javax.security.auth.useSubjectCredsOnly: false
    > 10991 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - Got instance:
    > sun.security.jgss.GSSManagerImpl@15d616e
    > 10991 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - Got kerberos:
    > 1.2.840.113554.1.2.2
    > 10991 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - Going to get a Name for
    > another@admin : 1.2.840.113554.1.2.1.1
    > 10994 [http-8080-Processor25] DEBUG
    > org.apache.ws.security.kerberos.GSSAuthorizor - Got Name: another@admin
    > 11004 [http-8080-Processor25] ERROR
    > org.apache.ws.security.kerberos.GSSAuthorizor - GSSException: GSSException:
    > No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT
    > credentials failed!)
    >
    > [root@localhost laurence]# more /tmp/jaas.conf
    > /** Login Configuration
    > **/
    > JaasServer {
    > com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true
    > storeKey=true keyTab="/etc/krb5.keytab";
    > };
    >
    > *Code from GSSAuthorizor:*
    >
    > GSSManager manager = GSSManager.getInstance();
    > Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    > this.serverName = "another@admin";
    > GSSName serverGSSName = manager.createName(this.serverName,
    > GSSName.NT_USER_NAME);
    > GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
    > GSSCredential.INDEFINITE_LIFETIME,
    > kerberos, GSSCredential.ACCEPT_ONLY);
    > log.debug("Created credentials for the service");
    >
    >
    > [root@localhost laurence]# /usr/java/jdk1.5.0_06/bin/klist -k
    > FILE:/etc/krb5.keytab
    >
    > Key tab: FILE:/etc/krb5.keytab, 4 entries found.
    >
    > [1] Service principal: another/admin@BWOO.COM
    > KVNO: 2
    > [2] Service principal: another/admin@BWOO.COM
    > KVNO: 2
    > [3] Service principal: another/admin@BWOO.COM
    > KVNO: 2
    > [4] Service principal: another/admin@BWOO.COM
    > KVNO: 2
    >
    > I have no idea what that error means. I have pointed it to the keytab file,
    > the keytab file has the Service Principal for another/admin@BWOO.COM as
    > indicated above and it still does not find it.
    >
    > Any help would be greatly appreciated. I do not have a policy file, does
    > this need to be added?
    >
    > Laurence
    > On 12/1/05, Douglas E. Engert wrote:
    >
    >>
    >>
    >>Laurence Brockman wrote:
    >>
    >>
    >>>Tried that already too and received:
    >>>
    >>>GSSException: GSSException: No valid credentials provided (Mechanism

    >>
    >>level:
    >>
    >>>Failed to find any Kerberos Key)

    >>
    >>Then you have to get the key into the keytab. This is the way a server
    >>works,
    >>It does not try and get a ticket.
    >>
    >> Figure 2 provides a sample login configuration entry for a server
    >> application. With this configuration, the secret key from the keytab
    >> is used to authenticate the principal "nfs/bar.foo.com" and both the TGT
    >> obtained from the Kerberos KDC and the secret key are stored in the
    >>Subject's
    >> private credentials set. The stored key may be used later to validate a
    >>service
    >> ticket sent by a client (See the section on Java GSS-API.)
    >>
    >> SampleServer {
    >> com.sun.security.auth.module.Krb5LoginModule
    >> required useKeyTab=true storeKey=true
    >>principal="nfs/bar.foo.com"
    >> };
    >>
    >>There should be an option above to set the file name. If not, it will use
    >>the
    >>default which is owned by root, and something like /etc/krb5.keytab or
    >>/etc/krb5/krb5.keytab. (If you server is not run as root, then it should
    >>have its
    >>own keytab.) (If the KDC is a windows AD, then the Microsoft ktpass can be
    >>used
    >>to create the key, and a keytab, that can be copied to your server.)
    >>
    >>
    >>Also note well that the @ is used GSS, and is changed
    >>to a principal /@
    >>
    >> GSSName serverName = manager.createName("nfs@bar.foo.com",
    >> GSSName.NT_HOSTBASED_SERVICE);
    >>
    >> The Kerberos V5 mechanism would map this name to the Kerberos specific
    >> form nfs/bar.foo.com@FOO.COM where FOO.COM is the realm of the
    >>principal.
    >> This principal represents the service nfs running on the host machine
    >>bar.foo.com.
    >>
    >>
    >>
    >>
    >>>If I don't setup the Kerberos stuff before calling that GSSCredentials I

    >>
    >>get
    >>
    >>>that error (See code below).
    >>>
    >>> GSSManager manager = GSSManager.getInstance();
    >>> Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    >>> GSSName serverGSSName = manager.createName(this.serverName, null);
    >>> GSSCredential serverGSSCreds = manager.createCredential

    >>
    >>(serverGSSName,
    >>
    >>>GSSCredential.INDEFINITE_LIFETIME,
    >>> kerberos, GSSCredential.ACCEPT_ONLY);
    >>> this.serverGSSContext = manager.createContext(serverGSSCreds);
    >>>
    >>>this.serverName = "another/admin" (The principal that I want to

    >>
    >>authenticate
    >>
    >>>as).

    >>
    >>No. See the above about the gss name to principal mapping. Its not the
    >>admin.
    >>You need to ge the keytab.
    >>
    >>
    >>>Thanks for all the help!
    >>>
    >>>Laurence
    >>>
    >>>On 11/30/05, Douglas E. Engert wrote:
    >>>
    >>>
    >>>>
    >>>>Laurence Brockman wrote:
    >>>>
    >>>>
    >>>>
    >>>>>On 11/30/05, Douglas E. Engert wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>So you are using GSSAPI, and passing the GSSAPI tokens via soap betwen
    >>>>
    >>>>the
    >>>>
    >>>>
    >>>>>>clint and server. And the server accepts the authentication.
    >>>>>
    >>>>>
    >>>>>
    >>>>>Prior to the server even looking at the packet from the client, it

    >>
    >>needs
    >>
    >>>>to
    >>>>
    >>>>
    >>>>>contact the kerberos server to get it's own credentials (GSS Uses these
    >>>>>underlying credentials when communicating with the client).
    >>>>
    >>>>No.
    >>>>
    >>>>See:
    >>>>

    >>
    >>http://java.sun.com/j2se/1.4.2/docs/...le-signon.html
    >>
    >>>>
    >>>> Credential acquisition on the server side occurs as follows:
    >>>>
    >>>> GSSCredential serverCreds =
    >>>> manager.createCredential(serverName,
    >>>> GSSCredential.INDEFINITE_LIFETIME,
    >>>> desiredMechs,
    >>>> GSSCredential.ACCEPT_ONLY);
    >>>>
    >>>> The behavior is similar to the client case, except that the kind of
    >>>>credential
    >>>> requested is one that can accept incoming requests (i.e., a server
    >>>>credential).
    >>>> Moreover, servers are typically long lived and like to request a

    >>
    >>longer
    >>
    >>>>lifetime
    >>>> for the credentials such as the INDEFINITE_LIFETIME shown here. The
    >>>>Kerberos V5
    >>>> mechanism element stored is an instance of a subclass of
    >>>> javax.security.auth.kerberos.KerberosKey containing the secret key of
    >>>>the server.
    >>>>
    >>>> This step can be an expensive one, and applications generally acquire

    >>
    >>a
    >>
    >>>>reference
    >>>> at initialization time to all the credentials they expect to use

    >>
    >>during
    >>
    >>>>their
    >>>> lifetime.
    >>>>
    >>>>
    >>>>There is an example of the server side later on, with gs name of "
    >>>>nfs@bar.foo.com"
    >>>>which when handled by the Kerberos would turn in into principal
    >>>>"nfs/bar.foo.com@DEFAULT.REALM"
    >>>>
    >>>>
    >>>>
    >>>>>>and the server is unable to authenticate to
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>the KDC using any credentials (Same error) and the client can
    >>>>>>
    >>>>>>authenticate
    >>>>>>
    >>>>>>Normally the server does not talk to the KDC at all. SO what is it
    >>>>
    >>>>really
    >>>>
    >>>>
    >>>>>>trying to do?
    >>>>>
    >>>>>
    >>>>>
    >>>>>I'm refering to the kerberos server that granted the service ticket to
    >>>>
    >>>>the
    >>>>
    >>>>
    >>>>>client. My server will need to talk to that server to get it's shared
    >>>>
    >>>>key at
    >>>>
    >>>>
    >>>>>some point otherwise it will not be able to verify the ticket the

    >>
    >>client
    >>
    >>>>is
    >>>>
    >>>>
    >>>>>sending.
    >>>>>
    >>>>>But the GSSAPI Delegation feature can be used be the client to delegate
    >>>>>
    >>>>>
    >>>>>
    >>>>>>a credential to the server so the server can act as the client. (The
    >>>>>>client
    >>>>>>gets a new Kerbveros TGT and sends to to the server.) Usefull with ssh
    >>>>>>for example where the user is logging in as the user.
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>using any credentials.
    >>>>>>>
    >>>>>>>Both use the same code:
    >>>>>>>
    >>>>>>>LoginContext("confName", new PasswordCallbackClass(....,....));
    >>>>>>
    >>>>>>So where is geting the password? Does the server think the principal
    >>>>>>is that of the user, as the gssapi delegated a TGT to the server?
    >>>>>
    >>>>>
    >>>>>
    >>>>>The principal is manually submitted and the password is returned from
    >>>>
    >>>>the
    >>>>
    >>>>
    >>>>>callback class (The call back class is instiated in such a way that it
    >>>>
    >>>>has
    >>>>
    >>>>
    >>>>>the password stored on the object and when the method responsible for
    >>>>>returning the password is called on the callback class it returns that
    >>>>>password (1234567890 in our case). This is the same process that is

    >>
    >>used
    >>
    >>>>on
    >>>>
    >>>>
    >>>>>my client and it works no problem (Using the same commands, same
    >>>>
    >>>>principals
    >>>>
    >>>>
    >>>>>and same variables).
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>lc.login();
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>Thc lc.login() on the server portion is failing. The server is

    >>
    >>runnning
    >>
    >>>>>>on
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>my Windows XP devel box and is running as a Tomcat servlet. Any known
    >>>>>>
    >>>>>>issues
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>with this type of setup?
    >>>>>>>
    >>>>>>
    >>>>>>You can run Ethereal on the box, and watch the network traffic.

    >>
    >>Ethereal
    >>
    >>>>>>can format krb5 packets. Very helpfull is cases like this.
    >>>>>
    >>>>>
    >>>>>
    >>>>>Yup, this will be the next step.
    >>>>>
    >>>>>Don't know.
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>Thanks all the help!
    >>>>>>>
    >>>>>>>Laurence
    >>>>>>>
    >>>>>>>
    >>>>>>>On 11/30/05, Douglas E. Engert wrote:
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>>Laurence wrote:
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>>Hey guys, hopefully someone can help me out here.
    >>>>>>>>>
    >>>>>>>>>I am having a problem with authenticating a user to a KDC (I

    >>
    >>believe
    >>
    >>>>>>>>>the MIT reference implementation) using Java (JDK1.5 and JDK1.4)
    >>>>>>>>>through GSS.
    >>>>>>>>>
    >>>>>>>>>Here is the background:
    >>>>>>>>>
    >>>>>>>>>I have two processes running on one machine (Client and Server).
    >>>>>>>>>
    >>>>>>>>>1. Client authenticates to kerberos server and logs in, uses the

    >>
    >>GSS
    >>
    >>>>>>>>>libraries to create a service ticket for destination server
    >>>>>>>>>(Authenticates with principal test/admin@realm.com).
    >>>>>>>>>2. Server receives request from client (Through soap transcation).
    >>>>>>>>>Generates a login context and tries to authenticate against the
    >>>>>>>>>kerberos server using test2/admin@realm.com. Server is returned an
    >>>>>>>>>error from the kerberos server (Integrity check on decrypted field
    >>>>>>>>>failed (31) - PREAUTH_FAILED).
    >>>>>>>>
    >>>>>>>>There is a bug in Java related to PREAUTH. (Its fixed in 1.6 I
    >>>>
    >>>>believe.)
    >>>>
    >>>>
    >>>>>>>>It has to do with Jave assuming it knows the "salt" to use when
    >>>>>>
    >>>>>>generating
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>>the key from the password. key = fun(passwrod,salt); The salt is

    >>
    >>based
    >>
    >>>>>>on
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>>user and realm. Jave assumes that the these have not changed since

    >>
    >>the
    >>
    >>>>>>>>password was last changed. Windows is also case insensitive but does
    >>>>>>>>preserve the case of the salt when changing the password.
    >>>>>>>>
    >>>>>>>>So if you have moved an AD account from one domain to another or
    >>>>
    >>>>changed
    >>>>
    >>>>
    >>>>>>>>the acount name (even the case) and not changed the password you
    >>>>
    >>>>could
    >>>>
    >>>>
    >>>>>>>>have problems.
    >>>>>>>>
    >>>>>>>>So make sure the case of the principal and the principal is the same
    >>>>>>>>as when the password for the acount was last changed.
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>
    >>>>>>>>>If I configured the client to use the same username/password I can
    >>>>>>>>>authenticate on the client, but no matter what I put in the server

    >>
    >>it
    >>
    >>>>>>>>>fails.
    >>>>>>>>>
    >>>>>>>>>I don't know the kerberos protocol well enough to know if I can

    >>
    >>even
    >>
    >>>>do
    >>>>
    >>>>
    >>>>>>>>>this (Having the server contact the KDC after a service ticket has
    >>>>
    >>>>been
    >>>>
    >>>>
    >>>>>>>>>issued to the client to authenticate). Is that why I'm getting what
    >>>>>>>>>I've read indicates a password error?
    >>>>>>>>>
    >>>>>>>>>________________________________________________
    >>>>>>>>>Kerberos mailing list Kerberos@mit.edu
    >>>>>>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>>>>>>>
    >>>>>>>>>
    >>>>>>>>
    >>>>>>>>--
    >>>>>>>>
    >>>>>>>>Douglas E. Engert
    >>>>>>>>Argonne National Laboratory
    >>>>>>>>9700 South Cass Avenue
    >>>>>>>>Argonne, Illinois 60439
    >>>>>>>>(630) 252-5444
    >>>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>--
    >>>>>>
    >>>>>>Douglas E. Engert
    >>>>>>Argonne National Laboratory
    >>>>>>9700 South Cass Avenue
    >>>>>>Argonne, Illinois 60439
    >>>>>>(630) 252-5444
    >>>>>>
    >>>>>
    >>>>>
    >>>>--
    >>>>
    >>>>Douglas E. Engert
    >>>>Argonne National Laboratory
    >>>>9700 South Cass Avenue
    >>>>Argonne, Illinois 60439
    >>>>(630) 252-5444
    >>>>
    >>>
    >>>

    >>--
    >>
    >>Douglas E. Engert
    >>Argonne National Laboratory
    >>9700 South Cass Avenue
    >>Argonne, Illinois 60439
    >>(630) 252-5444
    >>

    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  16. Re: Java GSS/Kerberos issue - Autheticating server

    Laurence Brockman wrote:

    >
    >[root@localhost laurence]# more /tmp/jaas.conf
    >/** Login Configuration
    > **/
    >JaasServer {
    > com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true
    >storeKey=true keyTab="/etc/krb5.keytab";
    >};
    >
    >*Code from GSSAuthorizor:*
    >
    > GSSManager manager = GSSManager.getInstance();
    > Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    > this.serverName = "another@admin";
    > GSSName serverGSSName = manager.createName(this.serverName,
    >GSSName.NT_USER_NAME);
    > GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
    >GSSCredential.INDEFINITE_LIFETIME,
    > kerberos, GSSCredential.ACCEPT_ONLY);
    > log.debug("Created credentials for the service");
    >
    >
    >
    >

    You can create GSSName as follows:

    GSSManager manager = GSSManager.getInstance();

    Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");

    // Identify the name of the server. This uses a Kerberos specific
    // name format.
    GSSName serverName = manager.createName("nfs/foo.sun.com",
    krb5PrincipalNameType);


    If you still have problems, send me a Kerberos debug output using
    "-Dsun.security.krb5.debug=true".

    Seema


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


  17. Re: Java GSS/Kerberos issue - Autheticating server

    Douglas E. Engert wrote:

    >
    >
    > Laurence Brockman wrote:
    >
    >> Tried that already too and received:
    >>
    >> GSSException: GSSException: No valid credentials provided (Mechanism
    >> level:
    >> Failed to find any Kerberos Key)

    >
    >
    > Then you have to get the key into the keytab. This is the way a server
    > works,
    > It does not try and get a ticket.


    Although it is recommended to use keytab for the server-end, Java
    GSS/Kerberos does provide the flexibility to work without keytab at the
    server-end. User can enter password for the service principal, and a key
    will be generated. However, once you generate keytab, entering passwords
    will not work; you'll need to reset the password for the service
    principal in the KDC.

    Seema


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


  18. Re: Java GSS/Kerberos issue - Autheticating server

    Thanks guys for all your help. I've now handed the project off to another
    group to look at... I could get the client to autheticate using either the
    JAAS methodology or use straight GSS with the keytab file, but I could not
    get the server portion to work either way.

    Thanks again so much!


    On 12/2/05, Seema Malkani wrote:
    >
    > Laurence Brockman wrote:
    >
    > >
    > >[root@localhost laurence]# more /tmp/jaas.conf
    > >/** Login Configuration
    > > **/
    > >JaasServer {
    > > com.sun.security.auth.module.Krb5LoginModule required

    > useKeyTab=true
    > >storeKey=true keyTab="/etc/krb5.keytab";
    > >};
    > >
    > >*Code from GSSAuthorizor:*
    > >
    > > GSSManager manager = GSSManager.getInstance();
    > > Oid kerberos = new Oid("1.2.840.113554.1.2.2");
    > > this.serverName = "another@admin";
    > > GSSName serverGSSName = manager.createName(this.serverName,
    > >GSSName.NT_USER_NAME);
    > > GSSCredential serverGSSCreds = manager.createCredential(serverGSSName,
    > >GSSCredential.INDEFINITE_LIFETIME,
    > > kerberos, GSSCredential.ACCEPT_ONLY);
    > > log.debug("Created credentials for the service");
    > >
    > >
    > >
    > >

    > You can create GSSName as follows:
    >
    > GSSManager manager = GSSManager.getInstance();
    >
    > Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
    >
    > // Identify the name of the server. This uses a Kerberos specific
    > // name format.
    > GSSName serverName = manager.createName("nfs/foo.sun.com",
    > krb5PrincipalNameType);
    >
    >
    > If you still have problems, send me a Kerberos debug output using
    > "-Dsun.security.krb5.debug=true".
    >
    > Seema
    >
    >
    >

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


+ Reply to Thread