kinit(v5): KRB5 error code 68 while getting initial credentials

[Djihangiroff, Matthias (KC-DD)]

I have a huge Problem.

Im trying to install a SSO for our Intranet-Webserver (Apache 2.0.55) on
a SuSE Linux 10.0.
Ist running very fine.

But we have some Computers, which are NOT Part of the Active Directory
Domain, so there the sso doesnt work.
If the paste their Usernames into the Auth-Box
(firstname...@persona.de) it doesnt work. But the Useraccount
exists in the AD.

If they paste the real username (e.g. firstname...@KONZERN.INTERN)
it works fine.
The problem: The user dont Know his real AD-Name. He knows just hier
emailadress (firstname...@persona.de)

Anyone a solution?

My krb5.conf

"[libdefaults]
default_realm = KONZERN.INTERN
clockskew = 300

[realms]
KONZERN.INTERN = {
kdc = w2kroot.konzern.intern
default_domain = konzern.intern
admin_server = w2kroot
}

persona.de = {
kdc = w2kroot.konzern.intern
default_domain = konzern.intern
admin_server = w2kroot
}

[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
[domain_realm]
.konzern.intern = KONZERN.INTERN
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 0
try_first_pass = true
}
"

Running from the command shell: kinit
matthias.d...@KONZERN.INTERN, all is fine (look at the missing f
in my name)
If i run kinit matthias.d...@persona.de (which ist my regular
windows login), i get an kinit(v5): KRB5 error code 68 while getting
initial credentials.

I hope someone can help me.

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[Jeffrey Altman]

KDC_ERR_WRONG_REALM 68 Reserved for future use

is being returned by Active Directory because your users are
attempting to obtain a Kerberos TGT for a realm that
is not hosted on the server to which they are authenticating.

The existing MIT Kerberos distribution that you are using does
not know how to respond to this error. Windows machines can
attempt to search the Active Directory Global Catalog in order
to determine the actual principal name to use for authentication.

Perhaps someone has a PAM module written that can re-write the
principal name based either upon local rules or a series of LDAP
lookups against Active Directory. Unfortunately, I am
not aware of one.

Jeffrey Altman