Re: AW: AW: Using a Kerberized application outside the Kerberos Realm





Florian Frankenberger wrote:

First of all thank you all for participating and sorry for being unclear.
By saying that Alice is not in a domain I mean that
Alice is not part of a Windows domain, thus not part of an AD and also is not
part of a Kerberos Realm.

But the Alice service could be part of the Kerberos realm supported by
AD. We do this all the time with Unix machines.

The host on which Alice is running, is not reachable from the KDC and cannot
reach the KDC directly.

Thats OK, the KDC and server don't communicate with each other.

So what I was trying to ask is if there is a possibility
to check a service ticket on authenticity by means of sharing secret key
between Alice and the KDC once and then decrypting incoming service tickets by
an own implementation, without establishing a connection between the KDC and
Alice.

Yes thats how Kerberos works! The client needs access to the KDC, and gets tickets
to present to the server. The server and KDC don't communicate. (Initially you do
have to get the principal setup in the KDC and the keytab onto the server. But that
can be done out of ban.


o do so, I would have to know if it is possible to create a Kerberos
service for a service that is not reachable, thus not really existing from the
point of view of the KDC. I'd then have to extract the secret key after creating
this - let's call it "virtual" - service.

The Windows "ktpass -out keytab" can be run on Windows, and create the keytab.
Manually copy this to the server, put it on a floppy if you have too.

I'd have to pass it to Alice once and
then let Alice check incoming service ticket for authenticity by decrypting them
with the symmetric service key. Is this possible?

Yes that is Kerberos!!

I've been trying to do this
for many days now but I am at a dead end.
I tried to use those ktpass and kinit tools, but I simply don't know if I am
doing right. As I understand, ktpass creates a principal in my AD for the
service. This is my first problem. what do I pass ktpass about the host and
the realm the service is running in?

Pass it the service name, usually "host" that is used by services like sshd
that all run as root in in effect log you on to the system.

the hostname is the FQDN of the host.

The realm name is the AD domain name in uppercase.

Is it possible to tell ktpass to create
a principal for a service in a realm that doesn't really exist?

No. ktpass only works with AD domains, where the realm is the AD domain
in upper case. You have to have admin authority in the domain to get
ktpass to run.

If so, how can I get the secret key after that?

Use the -out option to ktpass

And how can I get a service ticket for this service that is not really existing?

The client gets an initial TGT using kinit, login or KfW on windows.

The client application will cal the Kerbgeros libraries which will use the
TGT to get a service ticket from the KDC. but hte application usually
established a network connection of its own before attempting to get
the service ticket.

I know that all this is quite unusual

No its not.

but any help is very appreciated. If
someone has a completely different solution for my problem, please tell me.
Thank you very much.


Have you read:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx

You are trying to do sction:

Support for Kerberos Services

It says create a "user" account for the service. Since AD does everything by
accounts, this is not a real user, but an account to represent the service.
The ktpass then changes the password on this account( which AD uses to generate
the shared secret for the service) , adds a servicePrincipalName for the service
to the acounts and generates a keytab with the shared secret.)


Flo


-----Ursprungliche Nachricht-----
Von: Douglas E. Engert [mailto:deengert@xxxxxxx]
Gesendet: Dienstag, 22. August 2006 20:58
An: Florian Frankenberger
Cc: Michael B Allen; kerberos@xxxxxxx
Betreff: Re: AW: Using a Kerberized application outside the Kerberos
Realm




Florian Frankenberger wrote:

Thank you, Mike.

In my case, Alice isn't running in a domain at all.


Do you mean DNS domain or Windows AD domain? Kerberos deals with realms.
A service is in a realm if there exists a principal for the service
in the realm, and the service has a copy of the keytab file with the
shared secret for the principal. A client can then request a service
ticket from the KDC if in knows the principal name of the service.
The service principal in usually of the form <service>/<hostname>@<realm>
but the client and service agree on some other name that can work too.
By convention the service ticket has the FQDN of the host, but that is
really upto the client and server to agree.

But is your service is tied to Active Directory i.e. it is a windows
based service then it is using AD for more then Kerberos authentication.
It using AD for authorization information too.

With Unix there is normally a host/<hostname>@<realm> principal
that represents the machine (usually for login) and this could be referred
to as the machine is in the realm. But there is no requirement that
there be such a principal. You could have you own XYZ/<hostname>@<realm>
principal representing your XYZ service running on that host,
and that is the only Kerberos service running.

Also note that a service could have multiple principals in different realms.
and have these in the same keytab file. It could then accept service
tickets from either realm.

Mike was talking about cross realm, where two realms trust each other,
say AI-AG.US and AI-AG.DE. The user@xxxxxxxx can use cross realm to get
a service ticket for service/host@xxxxxxxx



That's why I have to implement the check for authenticity on Alice's side in my own way.

> So what about the idea of having the service ticket encrypted with the symmetric key that
> only the KDC and Alice know?

But that is the definition of a service ticket!


Doesn't this mean a kind of secure proof of authentcity to Alice if the ticket passed

> by Bob can be decrypted with the shared secret key? Or is it simply impossible
> to get a service ticket for a service that doesn't exist in this or any other domain?


Again the use of existing in a domain. Its not clear what you mean.



-----Ursprungliche Nachricht-----
Von: Michael B Allen [mailto:mba2000@xxxxxxxxxx]
Gesendet: Montag, 21. August 2006 20:49
An: Florian Frankenberger
Cc: kerberos@xxxxxxx
Betreff: Re: Using a Kerberized application outside the Kerberos Realm


On Mon, 21 Aug 2006 18:40:28 +0200
"Florian Frankenberger" <ffrankenberger@xxxxxxxx> wrote:



My problem is that Alice is not in the domain in which the KDC is running.

To be more precise, the KDC and the service Alice are set up in different


network environments and thus do not know each other.

Is it possible to create a kerberized service that is not part of the


Kerberos realm? If yes, what do I have to do?


Alice and Bob have to be in the same realm or in separate realms that
have a trust established between them. Otherwise the is no basis for
establishing trust between Alice and Bob. Kerberos is a "thrid party
authentication system" so there needs to be someone both principals trust.



I thought of sharing the symmetric service key between the KDC and Alice. To do so, I tried to create the service Alice with ktpass, give the so created encryption key to Alice and let Alice decrypt the service tickets, that will be delivered by Bobs later.

Is this procedure possibly in theory? Does anyone know how to obtain the service ticket by using JAAS? I only managed to get the TGT.


If Bob requests a ticket for ALICESVC/apps22.ai-ag.de@xxxxxxxx then
even if Bob is bob@xxxxxxxx he should have no problem looking up the
KDC for AI-AG.DE using DNS and getting a ticket per usual. But a trust
relationship would be required between AI-AG.DE and AI-AG.US.

Mike




--

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

.



Relevant Pages

  • AW: AW: Using a Kerberized application outside the Kerberos Realm
    ... Alice is not part of a Windows domain, thus not part of an AD and also is not ... part of a Kerberos Realm. ... I would have to know if it is possible to create a Kerberos ... then let Alice check incoming service ticket for authenticity by decrypting them ...
    (comp.protocols.kerberos)
  • Re: AW: Using a Kerberized application outside the Kerberos Realm
    ... If Alice can share a key with the KDC then Alice can be issued a service ... Betreff: Re: Using a Kerberized application outside the Kerberos Realm ... Is it possible to create a kerberized service that is not part of the Kerberos realm? ... establishing trust between Alice and Bob. ...
    (comp.protocols.kerberos)
  • Re: AW: Using a Kerberized application outside the Kerberos Realm
    ... Alice isn't running in a domain at all. ... Kerberos deals with realms. ... A service is in a realm if there exists a principal for the service ... By convention the service ticket has the FQDN of the host, ...
    (comp.protocols.kerberos)
  • User delegation in Kerberos V5
    ... I am wondering if I can do the following in Kerberos. ... I am a user of some realm. ... How can I give access to Alice to some of the files stored on a ... Kerberos a user can delegate his/her token to another user. ...
    (comp.protocols.kerberos)
  • Re: cross-realm authentication problem
    ... Windows client are in KLIENT.UIB.NO, Windows user accounts are in UIB.NO, Unix/Linux machines and accounts are in UNIX.UIB.NO. ... I have one web server running RHEL4, apache 2.0.52 and Kerberos 1.3.4 as provided by Redhat, self-compiled mod_auth_kerb 5.4, and another running RHEL5, apache 2.2.3 and Kerberos 1.6.1 as provided by Redhat, self-compiled mod_auth_kerb 5.4. ... After authenticating against UIB.NO on a Linux machine (which have UNIX.UIB.NO as primary realm in krb5.conf) cross-realm authentication works fine. ... But using a Windows machine where the user is authenticated in UIB.NO I get cross-realm authentication only to the web server running RHEL4, not the one running RHEL5, I never even get a ticket for UNIX.UIB.NO from AD when trying to access the RHEL5 server web page. ...
    (comp.protocols.kerberos)