Some simple questions about Kerberos - kerberos

I am learning about kerberos and i have few questions about it that i didnt found on the network and i wanna ask you.
The questions are:
What happen when I change user's password? What really gonna behind? What the service it use? I want to know what the steps and how the KDS behave after change password
Why kerberos's name called about the hades dog / 3 head dog? What the connection between them?
In kerberos system how I can see my tickets I recive from the KDC?
Thank you in advance.

I only have an answer to your 2nd question.
The reference to the three-headed dog is that there are 3 different entities:
The client system
the Authentication Server
the Service Server (the thing you're trying to access)
Most authentication protocols only involve the client and server.

From "Kerberos: The definitive guide" book by Jason Garman:
The Greeks believed that when a person dies, his soul is sent to Hades to spend eternity. While all souls were sent to Hades, those people who had led a good life would be spared the eternal punishment that those who had not would have to endure. Cerberus, as the gatekeeper to Hades, ensured that only the souls of the dead entered Hades, and he ensured that souls could not escape once inside.
As the gatekeeper to Hades, Cerberus authenticated those who attempted to enter (to determine whether they were dead or alive) and used that authentication to determine whether to allow access or not. Just like the ancient Cerberus, the modern Kerberos authenticates those users who attempt to access network resources.
You can see list of your tickets with klist command. If you mean literally see file where tickets stored, this command provides you with path to ticket cache as well. On *nix systems using MIT Kerberos it's /tmp/krb5cc_%{uid} by default. This command also should work in windows, but I'm not sure is it installed by default.

****1. What happen when I change user's password?****
They will get a new password, nothing special really, it shouldn't affect an existing kerberos ticket cache that i am aware of as long as the ticket is valid. If they have to enter their password anywhere at a later point for example if you have to run the kinit command to get a ticket where you enter your password then you must use the new password.
There shouldn't be much "sync" time or anything but it is vital that the time on your server is synced with the KDC as Kerberos is strict about times being in sync, by default there is a 5 minute clock skew, so it can only be off my no more than 5 minutes or things will start failing. Typically you would do this on linux by running the ntpdate command to sync the clocks.
***1a. What really gonna behind? What the service it use? I want to know what the steps and how the KDS behave after change password****
What happens depends on your setup, of which you have a variety of options but here a few more common setups.
The most common setup is running a corporate Active Directory environment. In a basic Active Directory setup your Domain Controller(s) run your KDC automatically. So for this you would just reset your Active Directory users password then pretty much be good to go, it will take care of the changes to the KDC for you.
The second would be running an OpenLDAP type environment for your users in place of Active Directory where you would change the passwords in OpenLDAP then update the password in the MIT Kerberos KDC using the kpasswd command to reset the password for your principal on the MIT KDC unless you have setup something such as pass-through authentication.
The third setup I see in an MIT Kerberos KDC with no LDAP environment whatsoever. Usually the kerberos users are local user accounts on the operating system. In this case you would just update the password on the MIT KDC using the kpasswd command I mentioned before to update the keberos principal password for the user on the MIT KDC.
2. Why kerberos's name called about the hades dog / 3 head dog? What the connection between them?
In addition to build on the previous answers Kerberos is similar to the 3 headed dog since it performs a 3 way handshake when authenticating. The three pieces are the Key Distribution Center (KDC), the client, and the server. This article gives a good explanation in detail, it is slightly off as it is talking about specific software but at the bottom of page 1 from Paper 476-2013 Kerberos and SAS® 9.4: A Three-Headed Solution for Authentication by Stuart Rogers, SAS Institute you will find the specific details.
3. In kerberos system how I can see my tickets I recive from the KDC?
If you have a ticket you can run the klist command. Append a -ef for klist -ef to see your encryption types along with any flags such as forwarded, initial, renewal, and others. See the MIT Documentation in klist documentation at http://web.mit.edu/Kerberos/krb5-1.13/doc/user/user_commands/klist.html .
You can get a ticket by running the kinit command then entering your principals password.
You can destroy a ticket cache by running kdestroy to clear your current tickets. This won't necessarly remove them from your cache directory though.
If you have a keytab file you can see details about it by running klist -kt /path/to/myuser.keytab to see the principal the keytab is for. There will be a principal per encryption type you are using, that is why it lists multiple of the same sometimes. You will see a KVNO number, which is your key version number, this number should always match for each principal.

Answers to you questions are:
Once the password for the principal is changed then after that point of time whenever you are running kinit command to get the ticket you should use new password
The name Kerberos was taken from Greek mythology; Kerberos (Cerberus) was a three-headed dog who guarded the gates of Hades. The three heads of the Kerberos protocol represent a client, a server and a Key Distribution Center (KDC).
To view the ticket you get from KDC you can run klist command if will give the details of principal , ticket lifetimes etc.
The location where ticket really exists depends on what you have given in /etc/krb5.conf which by default is default_ccache_name = FILE:/tmp/krb5cc_%{uid}

Related

Kinit autentication does not create klist ticket

I´ve been trying to connect to a HDFS server protected by Kerberos for days.
I alterady have have Kerberos for windows installed here. And it shows me the valid/active ticket.
But as I run 'Klist' on prompt, I see no tickets
If I run Kinit on prompt, it asks for my password and returns 'Authenticated to Kerberos v5' but still does not show me any klist ticket.
If I create a new tickt, using prompt or Kerberos GUI, it comes back showing me an active/valid ticket, but klist still does not.
I am trying to connect to hdfs using KerberosClient, but as I connect, somehow it does not "see" my active ticked (as klist too), so I got a connection denial.
I´ve setup the KRB5_CONFIG and KRB5CCNAME system variables to the folder exposed above.
What am I doing wrong?
Your system has two Kerberos libraries (MIT KfW & Windows SSPI) and two different klist tools:
the Windows klist.exe, which only shows the Windows LSA in-memory ticket cache that will be used by "Windows native" SSPI-based applications;
the MIT Kerberos klist.exe, which shows the file-based $KRB5CCNAME ticket cache that will be used by MIT "gssapi32.dll" GSSAPI-based applications.
(sometimes also the Java JRE klist.exe as well!)
If your HDFS client uses $KRB5CCNAME (e.g. if it uses GSSAPI via gssapi32.dll), then you need to run the MIT KfW klist.exe specifically. Use where.exe kinit to find out where it's located, then run it by full path.
On the other hand, if your HDFS client uses SSPI, then MIT KfW won't help you much – it can access tickets in the "MSLSA:" cache, but as far as I know it cannot put new tickets there. (It is possible to easily make SSPI acquire tickets for non-AD Kerberos services, but that's a different topic.)

How can i specify keytab file when connecting to postgres with golang pq using kerberos?

I am currently using golang pq library to connect to postgres database. I am successfully connecting using kerberos principal, but i can't figure out where can i specify keytab file to use to. In the source code it kinda happens magically, using some third-party library. It actually works, but i need to know for sure how does it know where my keytab is stored, so it can request initial ticket.
Usually Kerberos clients do not directly use a keytab; they expect the initial ticket to be already acquired and present in the environment. That is, you're expected to kinit before running the program, and afterwards the client's GSSAPI library looks for the KRB5CCNAME environment variable, which points at a file containing the ticket cache left by kinit.
(Normally with MIT Kerberos or Heimdal it could be many other things besides a file... but the 'pq' library uses a very minimal pure-Go Kerberos implementation which only accepts a traditional file-based ccache. So be careful if Krb5 on your distro was set up to use 'DIR' or 'KEYRING' or 'KCM' cache types, those aren't going to work here.)
If the initial ticket isn't present, the MIT Krb5 implementation will in fact automatically use a keytab to acquire the ticket if the KRB5_CLIENT_KTNAME environment variable is pointing to one. Unfortunately, the 'pq' library doesn't use the system Kerberos library, so that won't work here either. (But it also wouldn't work if your OS was using Heimdal Kerberos; it's a MIT-specific extension.)
So the approach that will always work is to set KRB5CCNAME to a temporary path, then use either kinit or k5start to acquire a ticket from the keytab, before running your program. (The k5start tool will also keep automatically renewing or re-acquiring the ticket before it expires, without needing to use cron.)
Really, the whole krb_unix.go file is disappointing. If they can call the native SSPI on Windows, surely they could call the native GSSAPI on Linux...

Kerberos keytab works on different hosts

I have encountered a problem. A keytab is generated for test01/host01#xxxx.com. I thought it only work on host01. But it works on other hosts. The host01 doesn't make sense. How can I use the keytab on only host01.
Thanks a lot!
Keytabs are not host specific. They are equivalent of passwords.
Keytab contains SPN and corresponding password entries. SPN is nothing but the name of the Application Service - E.g. HTTP/HOSTNAME:PORT
Microsoft recommends one keytab per application.In such case, if there are two different applications running on two different hosts, the same keytab won't work on both hosts. (Note that - a keytab can have multiple SPN entries, then the same keytab may work for two applications).
If you are using a load balanced environment where face url and actual application url is different, then keytab can be generated using face url as SPN. The Same keytab can be shared(copied) across all the internal nodes.
There isn't nearly enough information here to provide you a meaningful answer.
Keytabs are designed to be portable key storage formats so that any service can request or accept tickets based on the keys within the file. All Kerberos needs to succeed is having the key the KDC knows and the key in the file to match. Once they match all the crypto works and out pops a ticket.
So without knowing exactly what kind of environment you're in or the code you're running to try and limit per machine the best that can be said is: this is by design.

Why an invalid service principal name (SPN) can be created using setspn

Today, I was able to create totally random and invalid SPN using the setspn command, but I dont understand why invalid SPNs are allowed. For example:
setspn -s RandomSvc/randomname.random.random valid_user was run successfully for valid_user in my domain (I substitute the actual user name here, but the user is a valid user in the domain).
Then if I do setspn -l valid_user, it will list this invalid entry.
I guess nobody can actually connect to this service since it does not exist. however, if I try to add a valid SPN, but typed it by mistake, I won't notice it until my application gives me an error. So why setspn does not do any validation (other than checking for duplicate with -s)?
The setspn command won't stop you from creating an invalid SPN, and for good reason, so there is no actual problem here believe it or not. Your definition of a valid SPN - that of a representation of an actual service running on an actual machine having a host name in DNS which can be reached over TCP/IP, is not going to be enforced by setspn for reasons I am about to describe. According to a KDC, while an SPN represents an actual service running on an actual machine having a host name in DNS which can be reached over TCP/IP, it doesn't actually have to be real at the time though. Here's why. Have you considered the case where perhaps the service, or even the machine it will be run on, will be installed later? The service and even the machine it is running on, and the DNS entry for said machine, doesn't have to be in place in the here and now when you create the SPN. Setspn.exe is simply a rudimentary tool which exists that allows you to create SPNs which will conform the RFCs for Kerberos. Its up to you to architect it right though, it's not going to hold anyone's hand in the process. I work for a large company and create SPNs all the time for services, and even for machines, which do not yet exist. That way the Developers or sys admins don't have to contact me to have an SPN created after the fact. They are following a project plan and savvy managers are going to have the SPN, DNS entires, IP addresses for machines, all planned out and created ahead of time before the OS admins get around to actually spinning up a live server for such use. So if setspn prevented people from creating an SPN for a service which is not yet up and running, there would be some very angry system admins out there. That is why it is allowed to create "invalid" SPNs, when you think it shouldn't. If you want something to do extra layers of validation not afforded by the generic setspn.exe, to catch mistakes before your application does, then you will have to create such a thing yourself. Ask yourself though, is this worth the time for something so specific? I mean, how often are you creating SPNs? This should all make sense to you now. I periodically run a setspn -X to catch duplicate sin my domain. I've never had the time, but I suppose I could also list out all the current SPNs in the domain and check if they are each currently valid, and take corrective action if they weren't. I'm sure there are probably more than a few which no longer are active. I don't consider it that big of a deal.

Return a checked-out license in MATLAB/Lincese Manager (Flexera Software)

I have a MATLAB server which hosts a license manager (LMTOOLS by Flexera Software LLC) and few clients.
When you run use a toolbox function such as datestr(busdate(date)) you automatically checkout the Financial Instruments toolbox from the server. The license is returned to the server only when you close the session. Is there a way to force a particular client to return the license? A user forgetting to close his/her session can affect everyone as the administrator has no way to return the license to the server.
You can use:
lmutil lmstat -a -c "MYPATH\network.lic" --> to check license-borrower details
Output: ......john.doe PCNAME PCNAME (vxx) (SERVER/3300 123), start Tue 8/5 10:30
I tried using:
lmutil lmremove -c "MYPATH\network.lic" Fin_Instruments_Toolbox john.doe PCNAME PCNAME
but it returned just 1 line output lmutil - Copyright (c) 1989-2012 Flexera Software... and did not check-in the borrowed license. Any idea how to do this without closing the borrowing Matlab session? I even disconnected the client from the network but that didn't help.
Useful links: weblink1 weblink2
There's no way to do that - the client has to close their MATLAB session.
Mathworks use Flexnet and doesn't allow 'reread' or 'lmremove' like the other editors that use Flexnet. If I must make available a token I try the following solutions :
stop/start of the license server;
block the IP address of the computer where the toolbox is used.
Start/stop :
The users that have a token can use it during 20 minutes before lost it if the license server doesn't respond, but some new users can't take a token. Before make this, I check the number of Tcp/IP ports opened for the license service. I know that below 180/190 sessions (users), I can make a start/stop of the server.
If the faulty client doesn't make an other checkout after the start of the license server, the token will be available for other users.
If the user use a floating (CN) license and try to make an 'OUT' too rapidly (like a while(1)), I modify the option file to block the user by putting an 'EXCLUDE' for the user - a log file that grows continuously could be dangerous for the server. Or, if the user takes too many CN tokens for the same toolbox, I put a 'MAX' directive for him.
Block the IP address :
If the client using a token doesn't contact the server during 4 hours, the server consider that the token is 'Idle' and get it, it makes an 'IN', then the token is available. I use a 'Iptable' command to block the IP of the user's computer. This is only valid if the computer isn't shared between many users like a cluster node. The 4 hours is the value of the 'TIMEOUT' directive, but don't hope to reduce this value, even if you change it in the option file, you can only increase it. The minimum value is locked by Mathworks.