on 04-21-2009 9:34 AM
Hi,
We are using Crystal Report Server 2008 (BOE 3.1) with Tomcat installed on Windows Server 2003. We have configured Windows authentication and Vintela SSO with Kerberos, and it works fine...for 1 domain.
We have multiple AD domains, all in the same forest. For the moment I have declared only 2 of them in the Krb5.ini file, but only the one where CRS is installed works fine (domain1.com). I have been able to import a user from the other domain (domain2.com) in the database (via CMC, and using the "UseFQDNForDirectoryServers" registry thing - ), but this user cannot connect to the Java Apps (CMC or Infoview...). This fails with following log:
>>> KrbKdcReq send: kdc=+kdc.domain2.com+ TCP:88, timeout=30000, number of retries =3, #bytes=2719
>>>DEBUG: TCPClient reading 2682 bytes
>>> KrbKdcReq send: #bytes read=2682
>>> KrbKdcReq send: #bytes read=2682
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> Credentials acquireServiceCreds: got tgt
>>> Credentials acquireServiceCreds: continuing with main loop counter reset to 1
>>> Credentials acquireServiceCreds: main loop: [1] tempService=krbtgt/+domain1.com[AT]parentdomain.com+
default etypes for default_tgs_enctypes: 16 23 1 3.
>>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> Credentials acquireServiceCreds: no tgt; searching backwards
>>> Credentials acquireServiceCreds: no tgt; cannot get creds
KrbException: Fail to create credential. (63) - No service creds
at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:279)
While trying the kinit command it succeeds with the message: "New ticket is stored in cache file ...".
Where could this come from..?
Hi Tim,
More info about my situation:
SSO with vintela works fine for both domains, that's why I think my Krb5.ini is wrong. But testing it with kinit also works for both domains...
I follow your post:
1) This is OK
2) I can add my parent1 to the \[domain_realm] section, but what about the \[realms]? I mean, parent1 is not really a realm, it does not contain any user or kdc. What I call parent1 is our "company.com", and users are in "subsidiary.company.com". Am I misunderstanding something..?
3) This is OK too. As I said "kinit" works, and connecting to the Central Configuration Manager (no Web App) also works for both domains
4) SSO works
Another point: the domain controller for this domain2 is on Windows Server 2008, could this be a clue?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
sorry forgot that the kinit doesn't test the trusts, you still need the parent for manual auth, SSO uses DNS so that's why it's fine(no krb5.ini at all)
2008 could be an issue, not sure why but sometimes we need to force RC4 with 2008
add these to the krb5.ini as well in the lib defaults
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac
In regards to your query about realms
here is an example
[realms]
WINAUTHTZ.COM = {
kdc = BOBJ-W2K3-DB-TZ.WINAUTHTZ.COM:88
default_domain = WINAUTHTZ.COM
}
CH08.WINAUTHTZ.COM = {
kdc = W2K8-GEN.CH08.WINAUTHTZ.COM:88
default_domain = CH08.WINAUTHTZ.COM
}
If the parent in my case (winauthtz.com) was not specified then users from ch08 would be able to kinit but not login if the CMS were residing in another child of winauthtz.com. this is because TGS requests go out to the users domain, followed by the parent, then CMS domain (or something like that as they all get hit)
Regards,
Tim
When using the krb5.ini for multiple domains it seems we have to follow certain rules.
1) when adding another domain make sure you use the FQDN in all caps
2) make sure any transitive trust domains are defined as well for instance.
parent1 child1 and child2, BO is in child1
to login to child 1 all you neeed is the domain for child1 added to the krb5.ini
to login from child2 the krb5.ini must have both domains added (parent1, and child2). This is due to a limitation of the java SDK
the option CApath can also be used but honestly it's more complicated that way.
3) When users from other domains login they must specify the FQDN DNS DOMAIN in all caps (i.e. taking the scenario above for child2 a user would need to logon with username @CHILD2.PARENT1.COM. This is a limitation of the Sun java SDK we use to authenticate
test java issues by using kinit
test the service account/SPN by logging into client tools (regular username will work here)
4) the service principal name filed in the CMC>authentication>AD must be either the UPN of the service account(user @domain.com) or the SPN (PRINC/fqdn.com or PRINC/fqdn.com @domain.com). SPN is required for SSO with vintela.
Regards,
Tim
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
88 | |
10 | |
10 | |
9 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.