We'd like to manage user pricipal or keytab file in web application, how to generate user principal or keytab file via programming in kerberos ?
Finallly, I do that in python, doing something like: commands.getstatusoutput('kadmin.local -q "addprinc test"')
Related
I'm struggling with is the use of keytabs and service principals. I always thought keytabs were a combination of an encrypted password and Kerberos principal. For services or hosts, however there are no actual passwords unless I'm missing something.
In my case, I'm trying to use config Apache Kafka to run with Kerberos to Active Directory. Specifically I joined AD and created the SPN using the adcli command. I can create a keytab using the ktutil command for the service principal. However it prompts me for the password. I've tested using a service account password and the root password with no luck.
Any suggestions would be greatly appreciated.
I'm struggling with is the use of keytabs and service principals. I always thought keytabs were a combination of an encrypted password and Kerberos principal. For services or hosts, however there are no actual passwords unless I'm missing something.
There can be a password. Windows AD member hosts indeed have a "machine password" that is stored in the Windows LSA secrets storage – which is why they don't need a keytab. Similarly, "service" accounts1 in AD are just user accounts that have a (hopefully!) randomized password.
But to Kerberos, the original password doesn't actually matter. Only the derived key is what gets used. This means the key doesn't have to be derived from a password, and indeed in "traditional" MIT/Heimdal Kerberos the whole key is randomly-generated for host or service principals.
(Note that I said "derived", not "encrypted". For password inputs, the keys are the result of a one-way hash. Kerberos uses PBKDF2 for AES keys, while RC4-HMAC keys are "NTLM hashes".)
1 Oh, and don't try to re-use the "machine" account created via AD join for Kafka. Create a separate "user" account and assign it the SPN.
In my case, I'm trying to use config Apache Kafka to run with Kerberos to Active Directory. Specifically I joined AD and created the SPN using the adcli command. I can create a keytab using the ktutil command for the service principal. However it prompts me for the password. I've tested using a service account password and the root password with no luck.
ktutil could work, but there are two big issues to note:
First, when deriving the AES keys (using PBKDF2), you must use the correct salt. In Kerberos it can often be derived from the principal name, but not always; e.g. a renamed account will retain its original pre-rename salt. And in AD, all SPNs assigned to a custom user account will use that user's main account name as the salt, as the KDC knows about this relationship – but ktutil doesn't!
So you should always use the -f option to addent, which actually asks the KDC for the correct salt (just like kinit also would).
(RC4-HMAC keys use an NTLM hash, which is not salted. One of the reasons RC4-HMAC should become obsolete as soon as possible, and why you should also manually check whether the service account is indeed flagged for AES support.)
Second, you have to add keys for the same enctypes (algorithms) that the KDC thinks the service will support.
Fresh AD accounts are only considered to support arcfour-hmac (obsolete-ish), but I believe adcli sets the correct flags to indicate support for aes256 and aes128 as well. This means you need to repeat ktutil's addent 3 times, with different -e options.
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e aes256-cts -f
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e aes128-cts -f
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e arcfour-hmac -f
ktutil: wkt kafka.keytab
It might be easier to find a Windows host with RSAT installed, which has ktpass.exe that'll create a keytab for you.
(And unfortunately, samba-tool domain exportkeytab is not an option, as it assumes it'll be run directly on a Samba-based AD DC and wants to access the raw database and extract the current keys, instead of doing the normal thing and going via LDAP.)
We are using Java Kerberos authentication to connect to our SQL Server DB from Linux. Here we had used the prinicipal name and the password to generate a keytab file on the Linux system. Currently the connectivity works fine.
But there has been an additional requirement to use expiring passwords, which expire every 3 months. In our other applications we use an API called CyberArk which retrieves the password from a vault and Ops team need not bother about changing the password on the application server located on the Linux system.
Does anyone have any experience on using Kerberos in such an enironment? We are basically looking at avoiding to regenerate the keytab file every time the password expires.
I don't think you can avoid to regenerate the keytab file in the event of password change or expiring. What you can do, however, is to make it painless to generate the keytab file on the Linux server. this require the Linux server joining the Active Directory, using RHEL native tool realm or Centrify software.
RHEL tool document is here https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/realmd-domain
For Centrify user, https://community.centrify.com/t5/Centrify-Express/Replace-SSH-Keys-with-Kerberos-Keytabs/td-p/10112
I have setup Kerberos following below document
http://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Security_Guide/content/ch_configuring_amb_hdp_for_kerberos.html
Further, I would like to configure ranger to sync all Kerberos principals to create ACLS. There is an option to sync users from AD but I don't see any option to sync from Kerberos. See options in image below
Can anyone please help with options for doing this. Thanks
I'm not sure I understand what exactly you want to import, but I assume you have AD and local cluster KDC which are configured with trusted relations and you want all your principles to be represented in Ranger by standalone user accounts. If you have trusted relations configured that means that your entire list of principles would consist of both local KDC and AD and they all would be valid for authentication. But in ranger you work not with the actual Kerberos principles, but with the usernames, which are obtained from auth_to_local configuration setting according to the mapping rules specified there.
If you are running LDAP sync, it will pass all matching principles through the collection of rules in this configuration property and will create the end user account with names obtained after execution of these rules. You can check the end results using:
hadoop org.apache.hadoop.security.HadoopKerberosName principle#domain.com
For local KDC it really does not make sense to pass the principles from KDC through this mapping stage as at the end they all will be mapped to local UNIX accounts. That is why you can just point your group and passwd files in UNIX sync source and you can assume that all your local Kerberos principles would be represented in the Ranger database with proper user accounts.
You can find some more details about the aspects of Kerberos mappings in this article
I have read all the command on ftp which contains no command to change passwd.
I am a user of proftpd ,how can change my password after logining into proftpd by myself not by admin?
User can change it's own password in ssh service ,not by admin,it is convenient.
As far as i know ProFTPD does not contain its own users, but rather uses external resources to authenticate. That means that if you want to edit a user (or it's password) you need to edit whatever source ProFTPD authenticated that user against (i.e. /etc/passwd, PAM, LDAP, etc).
This, unfortunately for you, means that you can not edit your password from within an FTP session, but rather have to access the server via SSH or similar to change it.
More info can be found in the documentation: http://www.proftpd.org/docs/howto/Authentication.html
I just want to find out what the purpose of mapping a user to a service using ktpass is. For example I am on Windows and I run ktpass like this:
ktpass -out <keytab location> -princ <host/domain.com> -mapUser useraccount#domain.com -mapOp add .........
When we map a user to the -princ does it mean that only "useraccount" can authenticate the service? And how do we use the -add and -set option? what is the difference?
My issue is this: I have many users wanting to use a service I have, and authenticate through kerberos (JASS Krb5LoginModule) but I don't want to specify many user principal names in the jaas.config file. So I am thinking of using SPN instead, and mapping the users.
Option -mapUser useraccount#domain.com tells ktpass to store 'principal' in attribute userPrincipalName of this user in Active Directory, so that Active Directory would be able to find it, when clients ask for KerberosServiceTicket for this 'principal' and issue such ticket.
-mapUser specifies name of a user, which represents your service in Active Directory.
Using ktpass you're doing two things: generating keytab for your service (so that it could open Kerberos tickets received from clients, i.e. authenticate them), and registering principal in Active Directory (so that clients could get tickets for service at all).
In jaas.config file you specify just one principal name (for service), not for the clients. Once user logs into Active Directory domain, he/she has right to get service ticket for your service.