Kerberos and multiple SPNs - kerberos

I managed to setup Kerberos authentication for 1 server and is up and running ok. Now I have a project where I have to add another server to Kerberos configuration as follow:
1) AD server
2) server1 where service is running
3) server2 where same service will be running
so I executed setspn command to assing both to single "spn" user:
setspn -s serviceX/server1.domain.com#DOMAIN.COM spn
setspn -s serviceX/server2.domain.com#DOMAIN.COM spn
Then I executed comman ktpass:
ktpass -princ serviceX/server1.domain.com#DOMAIN.COM -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -mapuser serviceX\spn -out C:\keytab +rndPass
What should I do next to make it work?
How to execute ktpass for server2?
When I tried same command for server2 I'm getting Warning:
Warning: Failed to set UPN serviceX/server2.domain.com ptype 1 vno 10 etype 0x12
kinits to "serviceX/server2.domain.com" will fail.
How do you guys setup kerberos authentication for same service but on different servers?
Do you create 2 spn users and 2 keytabs?
I think I need to have everything in 1 keytab as the service requires it.
Any help?

You can run serviceX on the two different servers using the same keytab by using an SPN tied to a user account in the Directory rather than to each of the servers. To do this, you tie the SPN to a virtual server name (aka a "VIP") instead of a real one. We do this all the time at my current organization. So since the SPN would use a virtual server name in DNS, you just configure the load-balancer to send any queries for that virtual name to the real servers behind it "answering" to that name. So in this case, instead of worrying about having unique keytabs for both server1 and server2, your just create one keytab for what I'll refer to as server-vip, and then copy that same keytab to both servers. If you don't have a load balancer then you can do this just using DNS round robin. So the below example would be your new keytab creation syntax, notice how only one thing changes. Another reason why this is good is because it is resilient to to server changes. When you eventually decommission server1 and server2, you can easily just copy the keytab to server3 and server4 when that day comes.
ktpass -princ serviceX/server-vip.domain.com#DOMAIN.COM -ptype
KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -mapuser serviceX\spn -out
C:\keytab +rndPass

friend...
when you try bind the SPN:
serviceX/server-vip.domain.com#DOMAIN.COM
with the UPN
spn
The error: kinits to "serviceX/server2.domain.com" will fail. indicate some problem, but not exactly where or how. I had the same problem today, but another log revealed the main cause of the error:
Failed to set property 'userPrincipalName'
When we try generate the keytab with ktpass, this message is displayed, what we don't imagine, is that the UPN object have so many attributes, one of them is UserPrincipalName. So why we cant set the attribute UserPrincipalName with "spn" value? because it already configured in another UPN attribute! unhappiness you will need verify all attributes of yours UPN, searching for "spn" value.
you can use adsiedit to manual search:
adsiedit.msc
or make a loop with users searching for userPrincipalName attribute:
$users = get-aduser -filter *
foreach ($var in $users) { $var | select Name, UserprincipalName | fl }
I solved my problem finding my "UserPrincipalName" attribute wrong configured in another UPN.
► Each UserPrincipalName need be configured with the same name of your UPN.
UPN=s_user_http, then UserPrincipalName=s_user_http#YOUR_DOMAIN, verify this!
answering your question:
one UPN can be a multiples SPN, but its dangerous, if you increment the kvno accidentally, all anothers keytabs will be invalidate. Use one UPN for each SPN.
I hope this help.

Related

Weblogic Server contains NONE value during session ID generation

We have setup weblogic 12.2.1.4 clustered environment with 2 nodes in a cluster. We use session ID as part of authentication mechanism to log our user session info to the database. When both managed servers are up, the server generates this session ID:
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!-533469515!1605782630842
When we tried to test session replication, by bringing down the server that currently serves the HTTP request, we have noticed that the session ID has changed and contains NONE as part of the generated ID.
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!NONE!1605782630842
This has caused session replication inconsistency. Has anyone encountered the same issue and how did you resolve it? Your inputs are highly appreciated.
Thank you in advance for the help.
Enable the Debug Flags to Track Session Replication Failures
To gather more logging information about session replication failures, you should enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails.
To Enable:
In WebLogic Server 9.x and higher, the reccommended approach is to use the admin console. For each server in the domain, navigate to Servers -> -> Debug and enable the desired flag(s).
You can use the weblogic.Admin command line utility to dynamically turn the debug options on and off.
For example, to turn on DebugCluster on all administration instances of ServerDebug Mbean (i.e., Admin Server or a Managed Server):
java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -type ServerDebug -property DebugCluster true
Alternatively, you can edit the config.xml and the Mbean element in the stanza for each server that you want to debug and set the value to "true" to enable or "false" to disable. Then you must restart the Admin Server. Managed Servers will reconnect to the Admin Server and the debug flags will then dynamically take effect. Example:
At the end, with all the flags set, in your config.xml the ServerDebug tag would like below:
Make sure the stdOutSeverity level of the server is INFO and StdoutDebugEnabled is set to "true". The debug information will be logged into the server log as well as to the standard out.
Validate the Weblogic.xml entries
Make sure weblogic.xml has all the parameters that need to be set for each Session Replication type. For example, when using in-memory replication the sample weblogic.xml would look like:

Is it possibe to have multiple kerberos tickets on same machine?

I have a use case where I need to connect to 2 different DBS using 2 different accounts. And I am using Kerberos for authentication.
Is it possible to create multiple Kerberos tickets on same machine?
kinit account1#DOMAIN.COM (first ticket)
kinit account2#DOMAIN.COM (second ticket)
Whenever I do klist, I only see most recent ticket created. It doesn't show all the tickets.
Next, I have a job that needs to first use ticket for account1 (for connection to DB1) and then use ticket for account2 (for DB2).
Is that possible? How do I tell in DB connection what ticket to use?
I'm assuming MIT Kerberos and linking to those docs.
Try klist -A to show all tickets in the ticket cache. If there is only one try switching your ccache type to DIR as described here:
DIR points to the storage location of the collection of the credential caches in FILE: format. It is most useful when dealing with multiple Kerberos realms and KDCs. For release 1.10 the directory must already exist. In post-1.10 releases the requirement is for parent directory to exist and the current process must have permissions to create the directory if it does not exist. See Collections of caches for details. New in release 1.10. The following residual forms are supported:
DIR:dirname
DIR::dirpath/filename - a single cache within the directory
Switching to a ccache of the latter type causes it to become the primary for the directory.
You do this by specifying the default ccache name as DIR:/path/to/cache on one of the ways described here.
The default credential cache name is determined by the following, in descending order of priority:
The KRB5CCNAME environment variable. For example, KRB5CCNAME=DIR:/mydir/.
The default_ccache_name profile variable in [libdefaults].
The hardcoded default, DEFCCNAME.

Configuring FQDN for GCE instance on startup

I am trying to start a google compute engine (GCE) instance with a pre-configured FQDN. We are intending to run an application that is licensed based on the contents of /etc/hosts.
I am starting the instances using the Google Cloud SDK utility - gcloud.
I have tried setting the "hostname" key using the metadata option like so:
gcloud compute instances create mynode (standard opts) --metadata hostname=mynode.example.com
Whenever I log into the developer console, under computer, instances, I can see hostname under "Custom metadata". This appears to be a new, custome key - it has no impact on what:
http://metadata.google.internal/computeMetadata/v1/instance/hostname
returns.
I have also tried setting "instance/hostname" like the below, which causes a parsing error when using gcloud.
--metadata instance/hostname=mynode.example.com
I have successfully used the startup scripts functionality of the metadata server to run a startup script that parses the new, internal IP address of the newly created instance, updated /etc/hosts. This appears to work but doesn't feel "like the google way".
Can I configure the FQDN (specifically, a domain name, as the instance name is always the hostname) of an instance, during instance creation, using the metaserver functionality?
try this:
Go to your GCE >> VM instances panel.
stop your gce instance.
clic on the instance name.
Edit your instance, adding this values on Custom metadata fields:
Key field: hostname / Value field: your.server.hostname
Key field: startup-script / Value field: sudo -s hostnamectl set-hostname your.server.hostname
setup-example-image.png
Finally, start your instance and test with a hostnamectl command.
regards!
According to this article 'hostname' is part of the default metadata entries that provide information about your instance and it is NOT possible to manually edit any of the default metadata pairs. You can also take a look at this video from the Google Team. Within the first few minutes it is mentioned that you cannot modify default metadata pairs. As such, it does not seem like you can specify the hostname upon instance creation other than through the use of a start-up script like you've done already. It is also worth mentioning that the hostname you've specified will get deleted and auto-synced by the metadata server upon reboot unless you're using a start-up script or something that would modify it every time.
If what you're currently doing works for what you're trying to accomplish, it might be the only workaround to your scenario.
Here is a patch for /usr/share/google/set-hostname to set FQDN to GCE instance.
https://gist.github.com/yuki-takeichi/3080521322f0f1d159ea6a343e2323e6
Before you use this patch, you must set your desired FQDN in your instance's metadata by specifying hostname key.
Hostname is set each time instance's IP address is renewed by dhclient. set-hostname is just a hook script which dhclient executes and serves new IP address and internal hostame to, and modifies /etc/hosts. This patch changes the source of hostname by querying instance's metadata from metadata server.
The original set-hostname script is here:
https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google_config/bin/set_hostname.
Use this patch at your own risk.
When creating a VM, you can specify a custom FQDN hostname as an optional parameter. This feature is currently in Beta.
$ gcloud beta compute instances create INSTANCE_NAME --hostname example.hostname
This should work across OSes, and eliminate the need for workaround scripts.
More info in the docs.
-- Sirui (Product Manager, Google Compute Engine)
I've looked throughout this site to find answered questions and found a few things that work but with a couple solutions combined. This thread seems the place to answer.
1) echo example.com > /etc/hostname
2) add -- 127.0.1.1 example.com in /etc/hosts
3) add -- hostnamectl set-hostname
example.com -- command to /etc/rc.local script
4) uncomment /etc/dhcp/dhclient.conf line:
supersede domain-name "example.com";
5) profit.... Seems to stick after each reboot
(Note example.com is your domain name: fqdndomain.com - yourfqdndomain.org)
Also note this is for Ubuntu or Debian. Other Unix May slightly vary. I've tested this on Ubuntu 16.04
Always on the wording NOT possible to manually edit any of the default metadata pairs, how about the instant level default metadata "/scheduling"? we could set them manually as mentioned in this article

Enable SSO on redhat Environment

I need to enable SSO on my redhat environment. I need to know which rpms needs installation.
believe it’s a case of configuring AD to support the single sign-on against the WebSeal instance.i am installing WebSeal 6.1(Tivoli Access Manager WebSeal 6.1).
I have no knowledge regarding this.Can anyone brief me out and help me here how to proceed and what steps should be taken. What should be the prerequisites ?
There is a good writeup on IBM's InfoCenter about how to do this:
TAM 6.0:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc_6.0/rev/am60_webseal_admin211.htm?path=5_8_1_6_0_6_0_2_1_10_1_2#spnego-cfg-unix
TAM 6.1.1:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame.doc_6.1.1/am611_webseal_admin709.htm?path=5_8_1_3_1_11_1_2#spnego-cfg-unix
SAM 7.0:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.isam.doc_70/ameb_webseal_guide/concept/con_config_win_desktop_sso_unix.html
You have to:
Install IBM Kerberos client for WebSEAL
Create an entry in AD for the Linux server to auth against
Map the Kerberos principal to that AD user (the hardest part)
Enable SPNEGO on WebSEAL
Here are some of my notes that may help. However, I would strongly recommend walking down through the instructions on the InfoCenter site, as they are almost right on.
For step 1, in the linux_i386 directory, install the IBM Kerberos client using:
rpm -i IBMkrb5-client-1.4.0.2-1.i386.rpm
For step 2, the ktpass command you run on your AD controller should look something like:
ktpass -princ HTTP/WEBSEAL_SERVER_NAME_NOTFQDN#ad-domain.org -pass new_password -mapuser WEBSEAL_SERVER_NAME_NOTFQDN -out c:\WEBSEAL_SERVER_NAME_NOTFQD_HTTP.keytab -mapOp set
Transfer that keytab file to your Linux server.
Also make sure the keytab file on the Linux server is chown ivmgr.ivmgr; chmod 600. Otherwise the WebSEAL process won't be able to read it.
For step 3, you will need to edit /etc/krb5/krb5.conf and configure the KDC, AD realm, and local DNS name. You can use the mkkrb5clnt utility to help with this:
config.krb5 -r AD-DOMAIN.ORG -c ad-domain.org -s ad-domain.org -d AD-DOMAIN
Edit krb5.conf and change:
[libdefaults]
default_tkt_enctypes = des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des-cbc-md5 des-cbc-crc
From my notes, I had you can test the Kerberos configuration using (this is all documented on the infocenter article):
/usr/krb5/bin/kinit webseal#AD-DOMAIN.ORG
Enter the password for the WebSEAL user, then use klist to check things.
For step 4, just edit the WebSEAL config file and change:
[spnego]
spnego-auth = https
[authentication-mechanisms]
kerberosv5 = /opt/PolicyDirector/lib/libstliauthn.so
If you are clients are configured correctly, as long as their AD account name matches their TAM account name then it will work. You can also have WebSEAL prepend the #DOMAIN.ORG when mapping to a TAM user, which is handy if you are going to have multiple domains setup for SSO. However, you have to have TAM accounts with user#domain.org within your directory to map to.
You can specify what auth level SPNEGO comes in by modifying the [authentication-levels] section in the WebSEAL config file. That level would be level = kerberosv5
Good luck and have patience. Getting the Kerberos client setup on the Linux box was the most difficult part. It's a bit tricky when it wants capital DNS domain name, lower case DNS domain name, or just the plain vanilla AD domain name.

BizTalk MSMQ userid and password in a bindings file

I'm setting up a solution to deploy, driven by a batch file so it's reproducible
- I've got a binding file that works but I've now added on my MSMQ adapters
- works on my local machine, but I've found I have to add a userid and password to get it to work on the actual server
- it's in the domain, my virtual dev machine is just workgroup
Is there someway to add the userid and password to the file ?
- seems unlikely as that'd have the password in clear text, but what's the solution
- I sort of think something w.r.t. SSO, but that is an area I've not been near
You can put the userid and password into any BizTalk binding that supports authentication, including MSMQ. For security, the password is not exported, you just get a mask.
The userName and password sections of the binding file are not exported unless they have been configured, so the simplest thing to do is configure a MSMQ send port with userName and password manually and export the bindings - this forces the elements containing userName and the masked password to be generated into the binding file.
What you are looking for in your binding file is the <TransportTypeData> element of your MSMQ send port. This contains all of your adapter config information as encoded data.
Within that element there is a userName and password section. The password will be masked out with asterisks. Put the password for the environment there and import the binding.
The part of the encoded data with username and password will look something like below:
&lt;userName&gt;YourUserName&lt;/userName&
amp;gt;&lt;password&gt;******&lt;/password&gt;
For security reasons, when you export
bindings, BizTalk Server removes the
passwords for the bindings from the
file. After importing the bindings,
you must reconfigure passwords for
send ports and receive locations
before they will function. You
configure passwords in the Transport
Properties dialog box of the BizTalk
Server Administration console for the
send port or receive location. For
instructions, see How to Create a Send
Port. See also How to Create a Receive
Location.
From http://msdn.microsoft.com/en-us/library/aa558708.aspx
If you however open the biding file and scroll down to the line with the properties for the MSMQ Adapter you'll find the empty nodes. All you then have to do is to fill these out and the right values and they will be used the next time you import the binding file.
Of course you'll have to remember to redo this every time you export a new binding ...