I was looking for answer to above question on different web sites but in the every case there was how to generate keytab file. I need keytab to get hbase connection which contains kerberos authentication.
In order to generate a keytab on Windows, you need to be running some version of Kerberos which talks back to a Directory server. On Windows, by far the most prevalent example of this is Active Directory, which has Kerberos support built-in. You'll need to create the keytab on a Windows server joined to the Active Directory domain, using the ktpass command to actually create the keytab.
Keytab generation syntax example:
ktpass -out centos1-dev-local.keytab -mapUser krbCentos#DEV.LOCAL +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -princ HTTP/centos1.dev.local#DEV.LOCAL
The above command example successfully creats a keytab for use in an AD domain named DEV.LOCAL. Note: notice the use of the randomize password syntax (+rndPass). In my opinion, there is no need to specify a password in the keytab creation command syntax. Instead, it's better to allow the password to be randomized - that provides much better security since it prevents anyone from being able to manually logon as the AD account surreptitiously and bypass the keytab.
For additional reference, I highly suggest you read my article on Kerberos keytab creation on the Windows platform on Microsoft Technet which greatly expands on what I said here: Kerberos Keytabs – Explained. I frequently go back and edit it based on questions I see here in this forum.
Related
I have a number of Unix Shell scripts that logon to SQLPLUS in a batch environment. In order to logon to SQLPLUS the user and password are currently available to the shell script in plain text from a text file. Not Good ! I need to change this so that the password is protected and possibly encrypted, but the shell script can pick up the password and decrpyt to use. I'm not really sure how I would go about achieving my objectives, other than I presume I need to write some shell script code that can be in a library and pulled into all my shell scripts as required. Any suggestions would be welcome.
Probably not what you want to hear.
Encrypting or otherwise obfuscating the password in your shell script does not provide any real security: only "security by obscurity" which isn't actually secure. This is a good reading about passwords in plaintext.
So in my opinion it would be best, that as less people as possible have access to the shell script.
IMHO best possible solution in this case something like HashiCorp Vault Vault
You are setting up Vault server in secure/audited network/host and store your password there (vault will encrypt it for you). Then you generating vault access token with rights to read db password. With Vault you have http(s) API which will give your secret if you have correct token (curl inside shell script). Examples: api documentation
It is not best solution but with this you centralizing your secrets storage, everything encrypted, you can audit and revoke access to your secrets. This is way better than db passwords in plaintext all over your infrastructure.
I have deployed Kerberos in hadoop cluster. According to the theory, the KDC will verify you are the one as you clared, according to the private key.
However, using that system confused me. For example, if you need access to the HDFS, what you need to do is just to input "kinit hdfs#MY.REALM" and the password from a client. Then you will get ticket and manipulate the HDFS as the superuser "hdfs".
Does this the real process of kerberos? If the user are only verified by password, why don't we directly build a list inside the server and require the user to input its username/password? Where is the private key mentioned in the theory? Can anyone explain this to me please?
We configured our Hadoop clutser with Kerberos and everything started fine .We are trying to generate ticket for our hdfs principal using
kinit hdfs#HADOOP.COM
it is asking for password that we never configured although we are able to login using keytab file using
kinit hdfs#HADOOP.COM -t <keytab file location>
but now we wan the ticket that was generated using the keytab file to expire
I am very new in using Kerberos ,any pointers in right direction will be of a great help.
To list the kerberos ticket details, execute the below command in terminal
klist
Make sure JAVA_HOME is set in bashrc file
Not sure what you really mean by "now we wan the ticket that was generated using the keytab file to expire".
AFAIK you cannot force expiration of a ticket, but...
you can delete it completely with kdestroy
you can re-create it (delete + create) with kinit, either in
interactive mode (prompts for password then encrypts it to be shipped
to KDC) or background mode (uses provided keytab, which contains a
pre-encrypted password)
you can renew it (shift the expiration date, as far as you don't
bump into the max renewal lifetime)
So my best bet is that you just need to run kdestroy.
I'd come to this conclusion through experience and various things I've read on this internet, but in stating it to a co-worker, it seems illogical. Can you verify the following statement is true, or provide a counter to it?
On Vista/Win7, two standard (non-elevated users) cannot read/write the same location in the registry.
On Vista/Win7, two standard (non-elevated users) cannot read/write the same location in the registry.
This is a false statment
On Vista/Win7, two standard (non-elevated users) cannot write the same location in the registry in the default configuration.
But this is true. By default, users only have write access to their own hive (HKEY_CURRENT_USER) and read access to the machine hive (HKEY_LOCAL_MACHINE).
If you want to configure a location where any user can read and write, you can certainly do by configuring a key's ACL, as #Dark Falcon said. A good place for this is somewhere inside your application's key in HKEY_LOCAL_MACHINE, and at install time (when your installer has elevated privileges to do so).
That would be incorrect. A registry key can have an ACL specified which allows any user, elevated or not, to write to it. By default, I am not aware of any keys which have this configured, but it certainly is possible.
If a password is stored with reversable encryption in Active Directory, how does an administrator/developer extract and decrypt this password?
Specifically, I'm referring to this setting.
The following series of blog posts explains some details:
Passwords stored using reversible encryption: how it works (part 1)
Passwords stored using reversible encryption: how it works (part 2)
The author of this blog, Niels Teusink, also made the source code of his tool RevDump available for download.
It goes without saying that reversible encryption should not be used globally and only in very exceptional cases.
Although Dirk's answer is correct, the RevDump tool only works on Windows Server 2003, as newer versions of Windows store the reversibly encrypted passwords in a different way. Therefore I have created a new tool that supports Windows Server 2008+.
Simplest usage example:
Get-ADReplAccount -SamAccountName April -Domain Adatum -Server LON-DC1
Sample output (partial):
DistinguishedName: CN=April Reagan,OU=IT,DC=Adatum,DC=com
Sid: S-1-5-21-3180365339-800773672-3767752645-1375
SamAccountName: April
SamAccountType: User
NTHash: 92937945b518814341de3f726500d4ff
SupplementalCredentials:
ClearText: Pa$$w0rd