I'm working on configuring SSO in obiee 11.1.1.7.14, where in which I'm facing issue in the step while configuring krb5.conf and executing the kinit command.
few notes regarding the Active Directory
we have more than one domain controller and to balance the request we are maintaing the load balancer with port 3269.
And the integration between obiee and MSAD is successfully done with the load balancer name as host and port as 3269.
and few certificates have been added in the demotrust.jks and to the ovd store and SSL is enabled in the new provider.
Keytab file generated and placed in obiee domain home, krb5.conf and krb5Login.conf file modified accordingly.
I have created the keytab file and placed it in the obiee domain home, then modified the krb5.conf by keeping kdc as the one of the ip address of the domain controller and admin-server as the name of the domain controller. And while executing the
kinit -V -k -t /location/keytabfile.keytab HTTP/obiee_host_name
i have got and error "kinit(v5): Client not found in Kerberos database while getting initial credentials" . Please share your ideas/suggestions to solve this issue.
thanks in advance
We have a Active Directory server where 2 domain controllers are used for it. And a load balancer with port 3269 is used to connect to the Active directory from OBIEE and similar connections can be used in the krb5.conf and where ever required.
And consider the base domain as DOM1 and all our groups are created under sub-domain SUBDOM. So the SPN is set at the SUBDOM.DOM1.COM.
Here are the few suggestions we have followed to integrate AD with OBIEE and Solved the most of the kinit issues
Instead of specifying the principal name with the absolute path, just mention with the accout_name#FullyQualifiedDomainName.
Changes in KRB5.conf
Since the attribute "crypto" is specified as "all" while creating keytab and setting the SPN, all the encryption types which is present in the keytab file as to be mentioned in the krb5.conf (default_tkt_enctypes and default_tgs_enctypes).
Have included the primary domain controller IP address for the attribute kdc in [realms] section, this will be same as Michael-O specified in point 2.
in [domain_realm] of krb5.conf keep as .subdom.dom1.com=DOM1.COM.
include the host name of load balancer name in the admin_server attribute of [realms] section in krb5.conf
Once all the above changes are done, most of the kinit issues would be solved and the kinit command will be executed successfully by creating the initial ticket in the desired directory.
First of all, this is serverfault.
3269 is not Kerberos, this is SSL-backed global catalog. Pure LDAP not Kerberos. Not interesting here.
Do not put KDC IP addresses in the krb5.conf but rather rely on DNS SRV records just like Windows does.
You cannot kinit with a SPN. kinit expects a UPN (from AD) from the keytab. Something like accountname$#EXAMPLE.COM if this is a machine account. Always remember, a SPN is always bound to some account, whether machine or functional.
Related
showing "Unable to obtain dns hostname of active directory domain controller with ntdsa object name" msg while authentication with Active Directory on Windows Server 2012.
It depends on where your DNS is routing you.
Could be as simple as getting your DNS to talk to your server properly / take you to another DC in priority.
Since you just enter "the AD" here... You need to prioties to one DC since you are using more than one DC.
You can also refer this document1 and Document2 for troubleshooting your issue.
Been integrating Kerberos authentication in my SSO project. Came across a peculiar scenario.
I made a new user and attached an SPN to it. Followed steps on this question and got everything working. By everything I mean :-
kinit username - and then entering password gave me the message that ticket was saved.
kinit spn(int the format HTTP/FQDN) - and then entering password gave me the message that ticked was saved.
After some time I decided to try this over once again, and so I used the command
setspn -D spn username
to detach the spn from username. Then I deleted this user(username) from AD.
Next I created a new user say username1 and did as per this question to register the same spn as in above step for this new user.
Now kinit username1 - and entering password gave the message that ticket is saved, however kinit spn - and entering password gave me the error
client not found in Kerberos database.
Note that everything works fine if I use a different(new) spn.
So the question is, does Windows server have certain cache wherein some links are still present due to which I am not able to use this spn again? Or did I do some mistake while detaching the spn from user?
Thanks,
Nikhil
After reviewing what you wrote in Chat, as well as the full problem history, the problem is actually two problems. (1) You need to always delete the in-use SPN before creating the keytab. (2) Inside the ktpass.exe keytab creation command, you will need to map the user using the SPN of HTTP/vinw12sec5225.eqsectest.local, instead of the short logon name krbspn. Also, I will just make an observation - you do not need to place the SPN in all caps. That makes it hard to read, though for sake of continuity, I did not change that. Only the Kerberos realm should be in all caps. Based on the information you provided, to resolve this case, you should perform the following commands:
setspn -D HTTP/VINW12SEC5225.EQSECTEST.LOCAL krbspn
ktpass /princ HTTP/VINW12SEC5225.EQSECTEST.LOCAL#EQSECTEST.LOCAL /ptype krb5_nt_principal /crypto All /mapuser krbspn#EQSECTEST.LOCAL /out c:\ticket\krbspn.keytab -kvno 0 /pass eQ#12345
klist -e -k -t c:\ticket\krbspn.keytab
For a reference, I show an example of how to create a keytab when Microsoft Active Directory is in use as the Directory Service here: Kerberos Keytabs – Explained. I also provide an accompanying explanation of each ktpass.exe syntax parameter.
To help resolve what still could be wrong after the above steps, then using Notepad++ (not regular Notepad) right-click and edit your keytab file, simply copy the contents of the keytab file (don't make any changes) and then examine the results. The secret key inside will be encrypted - that's ok, look at how the SPN is formulated inside the keytab. It should match to what is shown for the SPN on the AD account. When these don't match you will get "client not found in Kerberos database" error. Also ensure the application server config is pointed to the right keytab file and restart the application service if anything is changed regarding the keytab.
We have one domain with trust (not-transitive) to two other domains. The base domain user can login without any problems, but the users from other domains cannot.
We get exception from ADFS like this:
The Federation Service encountered an error during an attempt to
connect to a LDAP server at {trusted domain}.
Additional Data Domain Name: {trusted domain} LDAP server hostname:
{trusted domain dc} Error from LDAP server: Exception Details: A
local error occurred.
User Action Check the network connectivity to the LDAP server. Also,
check whether the LDAP server is configured properly.
After reserching we found out, it's the one-way trust problem. The problem is, we don't have any posibility to change the trust configuration or to set up other ADFS on trusted domains.
Is there some possibility to get it to work? Maybe some work around solution?
Is it possible to change the FormSignin page, search the user manualy with DirectoryServices and manualy create the token?
Thanks All!
Not sure if there's a way to do it if you keep your ADFS service account in the trusting domain (in a one-way trust scenario). You would need to allow that account to be able to query LDAP in the trusted domain, which would usually mean a two-way trust.
Absent that, you may try to setup use an ADFS service account from the trusted domain. Of course, this would only work for one of your domains (unless the two other domains have trusts between themselves).
I am trying to authenticate my apache against kerberos.
I have two websites running on the same server, and I use VirtualHosts to achieve that and set DNS to have two names for this server to have a separate one for each website.
I added recently a new ldap/Kerberos server and trying to connect one of my websites to it, but I failed to get the correct credentials to get it works.
After adding some debugs, I found that apache looks for HTTP/fist-server-name instead of HTTP/second-server-name and for that reason couldn't find the correct principal in Kerberos database and keytab.
How to force apache to do its check against the second server name to validate the call from my second website? It looks adding ServerName attribute in apache configuration is not enough to do that!
I am able to do that by changing the server name orders in hosts file, but this can't help if I want to authenticate from the both server names!
Thanks.
I'm assuming that you're using mod_auth_kerb. You need to add:
KrbServiceName Any
to your Apache configuration. This will tell mod_auth_kerb to accept authentications to any principal for which there is a key stored in the keytab it uses, rather than making assumptions about what principal will be used and only accepting authentications to that principal.
You need to identify which Kerberos SPN you want to use for each website. You can check what SPNs are listed in your keytab by running: klist -k <Keytab> -- make sure that you're checking the keytab file that Apache uses.
In the VirtualHost declaration you need to change the KrbServiceName value to match the one that you identified from the keytab. Restart Apache and it should start using that when communicating with Kerberos.
An example would look something like:
KrbServiceName HTTP/yourservice.domain#REALM.COM
Make sure that AD has a service account and SPN that matches and that it can resolve via DNS back to the Apache server.
I found this recently in the MIT Kerberos documentation on Principal names and DNS:
Applications can choose to use a default hostname component in their service principal name when accepting authentication, which avoids some sorts of hostname mismatches. Because not all relevant applications do this yet, using the krb5.conf setting:
[libdefaults]
ignore_acceptor_hostname = true
will allow the Kerberos library to override the application’s choice of service principal hostname and will allow a server program to accept incoming authentications using any key in its keytab that matches the service name and realm name (if given). This setting defaults to “false” and is available in releases krb5-1.10 and later.
The setup:
There is a central AD domain (CENTRAL) and multiple seperate forests, each of which has their own domain (BRANCH1, BRANCH2, BRANCH3)
There are 2-way domain trusts between CENTRAL and all other domains.
An application I'm working on runs on the CENTRAL domain and performs LDAP searches on all domains, using the credentials CENTRAL\ldapreader.
This works perfectly for CENTRAL and BRANCH1, but BRANCH2 and BRANCH3 refuse the connection with an invalid credentials error. If the search instead uses an account in those domains (BRANCH2\ldapreader, etc) then the search works fine.
What level of permissions are needed to read AD as an LDAP server? Everything I've found indicates that this is allowed for AUTENTICATED USERS, which should work fine with CENTRAL\ldapreader due to the two way trust but that isn't the behavior we're getting.
I think the permission you're looking for is "List Contents". You should ensure "CENTRAL\ldapreader" has this permission for BRANCH2 and BRANCH3.
I'm wondering if you set up the trusts with selective authentication or forest-wide authentication and whether you can manualy browse BRANCH2 and BRANCH3.