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.
Related
I created an admin user with password in pgadmin4:
CREATE USER admin WITH
LOGIN
SUPERUSER
CREATEDB
CREATEROLE
INHERIT
REPLICATION
CONNECTION LIMIT -1
PASSWORD 'xxxxxx';
But I can login to the respective server with the admin user and any wrong password.
I used psql command line to check if the user has been created, and it is.
# SELECT usename FROM pg_user;
usename
------------
postgres
xxxxxxxxxxx
admin
(3 rows)
I checked if I can login with the admin user and a wrong password through psql command line, and it worked...
Am I doing something wrong?
Pgadmin4 v1.1
Postgresql v9.6
Same problem on Centos 6.8 and macOSX 19.12.1
This is speculation, but it's educated speculation, as I encountered a similar issue.
If your pg_hba.conf file, I am pretty confident you have the admin user set up as "trust." This pretty much means it can log in from anywhere you specified, without a password.
If you change this to "md5," it should resolve the issue.
# TYPE DATABASE USER ADDRESS METHOD
host all admin <whatever> trust
change to
host all admin <whatever> md5
Of course some of these fields may be different, depending on how you have the server set up, but you get the idea.
I have a password protected PostgreSQL database (running on windows) which has been accessed by an unauthorized person several times using this simple trick as described here:
Stopping PostgreSQL Windows service
Changing md5 to trust in pg_hba.conf file
Starting Windows service
Accessing database via pgAdmin without a need of password
Is there any way to block this mechanism? I've been thinking about multiple windows users (there's only one administrator account on the machine right now) with limited file change privileges, but I am worried about database functionality and I would prefer a little bit more straight-forward solution.
UPDATE
Thank you all for your responses, they were all very helpful.
It's obvious to me now the user accounts are the way - probably the only right way at all.
Indeed the way to solve the problem is not by looking into PostgreSQL, but by looking into your Windows security. Once someone gains administrator privileges, there is nothing which stops the person from changing anything - this includes your PostgreSQL settings. Even if you set a database password and set proper permissions for the pg_hba.conf file, the unauthorized person can still change the permissions back, or start the database in single user mode (no password required) and modify the passwords.
Create separate Windows user accounts, protect the Admin with a password, and stop using the Admin account for day-to-day work.
Perhaps change all your users to limited. Create a user called postgres thats also limited and set it so that that its the only user that can read/write its own files. You will have your administrator account, that still can do whatever you want to do. Now run the postgres service as the user postgres and youre done.
... and stop giving people your admin password -- you should be fine ;)
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 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.
I have wrapper web services to read from Active Directory. It works fine on DEV; but on Staging / QA, I am getting this error
Logon failure: unknown user name or bad password.
I am able telnet to the Active directory server on 389 (LDAP port) from both DEV & Staging boxes. I tried with different user accounts who has even read only access to active directory; all worked fine on DEV but not on Staging / QA. Any clues?
That could be a lot of things, from improperly escaping the password (it probably has characters that are not in "normal" strings in whatever language you're using) to not including the AD DOMAIN name in the username (DOMAIN\username)
You might check the permissions of the account that runs the web service, usually on the Staging/QA the security requirements are higher.
UPDATE http://www.velocityreviews.com/forums/t619647-impersonating-and-windows-authentication.html