First, the Service principal name is registered for a user using setspn command.
setspn -a CS/dummy#abc.com dummyuser
setspn -l dummyuser
gives the output as
CS/dummy#abc.com
Next, when ktpass command is executed with /mapUser option, the service principal name of the user account gets modified so that the domain component gets dropped.
ktpass /pass Password#123 -out dummy.1.keytab -princ CS/dummy#abc.com
-crypto DES-CBC-MD5 +DumpSalt -ptype KRB5_NT_PRINCIPAL +desOnly /mapOp set /mapUser dummyuser
setspn -l dummyuser
gives the output as
CS/dummy
Are both of the following commands correct and work in the same way?
setspn -a CS/dummy dummyuser
setspn -a CS/dummy#abc.com dummyuser
While specifying service name in the SPN, is mandatory to include the domain component too? Can you please clarify?
As you did not mention it, I will assume you are in a Windows Active Directory domain environment? I say that because the command "ktpass" given in your example is native to Windows. Based on this I will assume that your Active Directory DNS domain name is abc.com and Kerberos realm name is ABC.COM.
When you create a keytab, the SPN gets mapped to the user or computer object (principal, in Kerberos terms) at that time so you don't need to adjust the SPN of that principal afterwards unless you are adding them as secondary SPNs.
Do yourself a favor and place the Kerberos realm name in upper-case inside your keytab creation command. Its best to randomize the password so nobody knows it. Kerberos SSO functionality will work just fine with that. And the Kerberos realm name needs to be appended to the "/mapUser" argument. I've modified your example into a better one you should use.
Its outside the scope of your question but don't use DES encryption anymore. It's long been out of favor in the industry. I won't say more on that because that's not what you're asking about.
Don't use the "setspn -a" syntax to add or create SPNs on principals, use "setspn -s" instead as the "-s" checks for duplicates SPNs while the "-a" does not (see: “setspn -s” vs. “setspn -a”).
Ensure that you fully-qualify the host part of the SPN (i.e., dummy.abc.com, rather than just dummy). Else, the authentication mechanism might immediately try NTLM instead of Kerberos which is not what you want.
In a simple environment consisting of just a single DNS domain and single Kerberos realm, and having the Kerberos realm to DNS domain mappings are already set (usually by /etc/krb5.conf when on UNIX/Linux, Windows handles that automatically but if it doesn't then it will try C:\Windows\krb5.ini if present), while you would not need to qualify the Kerberos realm as part of the SPN when running "setspn -a" or "setspn -s", you should do so inside your Kerberos creation command.
So, in your case, based on everything I mentioned, while you can use:
setspn -a CS/dummy dummyuser
It would be better to do it this way instead:
setspn -s CS/dummy.abc.com dummyuser
For extra credit I've also modified your keytab creation command accordingly, though keeping the DES part so as not to further confuse.
ktpass +rndPass -out dummy.1.keytab -princ CS/dummy.abc.com#ABC.COM -crypto DES-CBC-MD5 +DumpSalt -ptype KRB5_NT_PRINCIPAL +desOnly /mapOp set /mapUser dummyuser#ABC.COM
Related
I am using tmux 3.3a on an Ubuntu 22.10 system with two users, bob and alice.
Both users are members of the multiplexer group.
Bob has created a tmux session on an custom socket like so:
tmux -S /tmp/our_socket new -s our_session
and then changed the group of the socket file to multiplexer and added read/write permissions for that group:
chgrp multiplexer /tmp/our_socket
chmod g+rw /tmp/our_socket
Now alice, who is also a member of the multiplexer group, is trying to connect to this session using:
tmux -S /tmp/our_socket attach -t our_session
which throws an access not allowed error.
However when alice uses sudo-privileges, she is able to connect to the tmux session.
I do not understand why access is denied without elevated privileges, as the socket file has read/write permissions for the multiplexer group and both bob and alice are members of that group. My guess is, that it's connected to the sticky bit enabled for the /tmp directory, but I'm not sure.
I had a similar problem. It seems that the later versions of tmux have its own access check as well. So, in addition to making the socket accessible to the user you want to share the session with, you also need to tell tmux that this user is allowed.
tmux server-access -a {user_to_share_with}
For more info, see the description of tmux "server-access" command.
P.S. As a bonus, the user can be allowed read-only access only now!
Invoking kinit with the principal name to get kerberos ticket asks for password, even though I want it to authenticate with client certs which I have configured in /etc/krb5.conf. What is the way to force it skip password and only use the client cert in the AS REQ and do the pki authentication to get the kerberos ticket? I have the principal in the UPN of the kclientcert2.pem whose priv key is kclientkey2.pem and is issued by kclientca.pem. I have all of them in my /root folder. I then invoke kinit with principal name as parameter. Then I am prompted for password.
My /etc/krb5.conf realm config looks like below.
[realms]
myrealm = {
kdc = <ldap server IP>:88
kdc_tcp_ports = 88
pkinit_eku_checking = kpServerAuth
pkinit_anchors = FILE:/root/kclientca.pem
pkinit_identities = FILE:/root/kclientcert2.pem,/root/kclientkey2.pem
}
Now I installed krb5-pkinit package in one ubuntu client. After this it did not prompt for password here. But it gave the message "kinit: KDC name mismatch while getting initial credentials". the tcpdump shows a 2nd AS-REQ with AS-REP with code 11.
On an embedded client running linux, I couldn't install the package like in ubuntu, so I copied krb5 shared libs like preauth/pkinit.so and other s0 to /usr/lib path which is the standard path of the embedded client, but it still prompts for password. ###https://stackoverflow.com/users/696632/michael-o, we got disconnected on the other thread, can you please help to understand why the kdc name mismatch occurs on ubuntu and which library I am missing on the embedded client.
I need to restart my open shift PODs whenever I see Kerberos authentication failure exception. To get that done, I need to check the Kerberos authentication as part of liveness check. Can you someone please let me know how do I check Kerberos authentication without proceeding a message to kafka broker? Thanks.
A simple klist command can be used to list the Kerberos principal and tickets held in a credentials cache or the keys held in a keytab.
I also read another method here: https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-52-01/configuring/policy-server-configuration/authentication-schemes/configure-kerberos-authentication/troubleshoot-kerberos-authentication-setup.html
Windows:
Verify whether the keytab file is valid. Run the following command:
kinit -k -t keytab_file_location
respective_spn
This command returns no error when the keytab file is valid.
UNIX:
Run the following command:
kinit -k -t keytab_file
service_principal_name
If you get no errors, keytab files are fine, and the krb.conf file has valid values.
Hope this helps or at least gives you some ideas on how to test without producing a message to the topic!
In my Kerberos system:
run kinit test and input passwd, succeed.
generate keytab by kadmin.local -q "xst -k test.keytab test".
run kinit test and input passwd, failed:
kinit: Password incorrect while getting initial credentials
run kinit -k -t test.keytab test, succeed.
Is this normal ? If not, what are possible reasons?
Thanks.
I found that the attribute krbLastPwdChange(a timestamp value) in kerberos's database changed after I run:
kadmin.local -q "xst -k test.keytab test"
While add the option -norandkey will just create the keytab without changing password:
kadmin.local -q "xst -norandkey -k test.keytab test"
I can not find the detail document about kadmin xst.
This is by design. You cannot have both a password and a keytab in Kerberos. The reason is if both were enabled, if someone was able to pull a keytab on your behalf or was in possession of a copy of your keytab, then they could masquerade as you and you would never know it. They would be able to generate a TGT via kinit.
By pulling a keytab, the password is invalidated, so if you then tried to log in with a password, you would get an error. And even if you didn't know exactly what was going on, if you reset your password, it would invalidate the keytab.
For one simple reason:
kinit tells you that the client has not been found in the database, right? By default, when kinit is invoked with a keytab it uses the default server pricipal to obtain TGT. In your case host/<hostname>#REALM but your keytab contains a key for principal test#REALM.
I had this issue too until I have asked the MIT Kereros mailing list.
I would like to login to Perforce(P4) from the command line.
I tried using
p4 -u My_Username login
But how do I provide the password. I need this to check-in a file from the command line.
Before connecting to the server, set P4PORT (to tell the client where the server is) and P4USER (to tell the server who you are). P4PORT is specified as hostname:port, with the port usually (but not always) being 1666. If you're not sure what your Perforce server address and user name are, check with your sys admin.
p4 set P4PORT=your.server.hostname:1666
p4 set P4USER=your.username
You can also use "set" or "setenv" or "export" as appropriate to your shell, but with a 2014.2 or newer Perforce client (use "p4 -V" to check your version information) you can use "p4 set" as a persistent cross-platform alternative. Another option is to use the "-u" and "-p" flags on every command you run (e.g. "p4 -p your.server.hostname:1666 -u your.username sync ..."), but this gets tiresome quickly.
To verify that your connection is correct, run:
p4 info
If this gives you an error message, or says that your user is unknown, check with your Perforce administrator to make sure you have the correct P4PORT and P4USER values.
To login, run:
p4 login
If the client is able to connect to the server and your user name is correct, you will be prompted for the password. Enter it and you will be logged in.
If you are scripting Perforce commands that require login credentials, and you don't want your script to stop in the middle to prompt for a password, my recommendation would be to run "p4 login" as above at some point prior to running the script. The login ticket will persist on your machine and the script will pick it up (provided that it's connecting with the same P4PORT and P4USER that you used to generate the ticket). This is the most secure method because your cleartext password is not stored anywhere on your machine, and the login ticket is not usable from other machines by default (it is also probably time-limited, depending on how your admin has configured things).
The insecure method is to put the plaintext password into your script:
echo my.formerly.secure.password|p4 login
Piping the cleartext of the password into the "p4 login" command will cause it to behave as if you'd entered it at the prompt, and continue executing rather than waiting for additional input.
Setup Perforce login details in Windows cmd
After installing perforce and setup your workspace through p4v, you could set up your workspace in Windows cmd.
The command you need is:
p4 set
Set your server
p4 set P4PORT= xx.xxx.xx.xxx:xxxxx
Set your user name
p4 set P4USER=username
Set your password
If you want to secure your password, you could download the MD5 encryptor to encrypt your password.
p4 set P4PASSWD=hashedpasswd
Set you client (workspace)
In order to select your workspace, you could use the following command:
p4 set P4CLIENT=nameofworkspace
The name of your workspace could look like: username_hostmachinename_numbers.
Set your ignore file
You can set up your ignore file so that when adding your project to perforce, some files (building results) could be automatically ignored.
p4 set P4IGNORE= filepath
I believe you can do this:
p4 -P My_Password login