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.
Related
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.
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.
i wonder why postgres allows trust Authentication method as it allow any role to connect without providing a password!!
if any role change the pg_hba.conf to trust then the server will be unsecure and will open to any role with any password
i would like to prevent any connection to the server without providing the right password , so how can we prevent this ?
is their any best practices follow in order to secure postgres server ?
As described in the manual, the postgresql daemon should be run as a separate user account which is not used for other purposes. The data directory and all the files in it should be owned by this user and permissions set so that only this user has access to it.
The initdb command which is used to initialise the database cluster will set it up like this.
If set up correctly, only the postgres user, or root, can edit pg_hba.conf.
The basic assumption behind the trust method is that the user is pre-authenticated by the environment. For example, if the database is not configured to listen on any external interface, and you are sure only authorised users can log into the server.
Section 19.3.1 describes in more detail the circumstances under which you might want to use the 'trust' method.
Check 19.3. Authentication Methods
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).
One can use
new PrincipalContext(ContextType.Domain,null)
without providing any connection strings for the Active Directory.
When using ActiveDirectoryMembershipProvider you must provide an LDAP endpoint in web.config.
The site I'm working on will be deployed on multiple sites and I don't want to have to fill the details in the web.config for each deplyoment.
How To: Use Forms Authentication with Active Directory in Multiple Domains on MSDN specifies 3 (!) membership providers to deal with 3 domains which is not impressive. However, this article is from 2005 and it deals with a different tasks then what I'm after.
The question:
Is is possible to use ActiveDirectoryMembershipProvider in a way that the LDAP end point is not hard-coded in the web.config?
I would prefer to use ActiveDirectoryMembershipProvider rather than PrincipalContext to have (potentially) the ability to call ChangePassword etc.
No, it is not possible to use ActiveDirectoryMembershipProvider without specifying a target LDAP server.
The connection string must be specified, and the string must contain a server (contains ADS_FORMAT_SERVER)
You must create a connectionStrings Element (ASP.NET Settings Schema)
entry in the Web.config file that identifies the Active Directory
server, Active Directory domain, or ADAM application partition to use.
The provider will only operate at domain scope, or in a subscope
within a domain.
If you want to support an active directory forest, and losing forms authentication is an option, consider using Windows Authentication. Windows Authentication will use NTLM and Kerberos to get the user's identity within a forest, and you can still change a users password via impersonation. See WindowsIdentity.Impersonate().