Yesterday TIBCO announced security vulnerability in TIBCO ActiveMatrix Products. ActiveMatrix Runtime and Administrator components contain a critical vulnerability in the handling of JMX connections. An attacker with access to an affected system could gain administrative control over the system, allowing the attacker to execute arbitrary code on any host that is a participant in the system.

TIBCO has released updated versions of the affected software products. If an upgrade is not possible, use a firewall to restrict access to the ActiveMatrix Runtime and Administrator components.

Additional information and list of affected products versions here.

The idea was to let users, who have accounts in the MS AD, log on to Informix database running on Solaris without requiring to enter credentials again as they are already authenticated in the domain on their Windows workstations. So, we will configure Informix for Kerberos and Single Sign-On (SSO) authentication for Windows clients. This configuration can be called the logical conclusion of a previous configuration with PAM.

Informix box must be preconfigured and joined AD domain like in this my example for Solaris and MS AD. Installing the latest patches is strongly recommended as some related bugs were fixed recently in Solaris and Informix.

1. On any Domain Controller:
   • create a service account in AD, one per server/alias
   • run setspn -A <sso_alias>/<informix_server>.domain.com@DOMAIN.COM <informix_server>
   • run ktpass -princ <sso_alias>/<informix_server>.domain.com@DOMAIN.COM -mapuser <serv_acc>@DOMAIN.COM -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -mapop set -pass <serv_acc_password> -out my.keytab
   • upload generated keytab file to Informix server
2. On the Informix box:
   • run ktutil and insert generated key to existing keys file:
     ktutil:  rkt /upload/my.keytab
ktutil:  wkt /etc/krb5/krb5.keytab
ktutil:  quit
   • run klist -e -k /etc/krb5/krb5.keytab to check keys file
   • create <informix_home>ids/etc/concsm.cfg file with one row like this:
     GSSCSM("/app/informix/ids/lib/csm/libixgss.so", "", "c=1,i=1")
   • add sso alias to Informix onconfig file
   • add sso alias to sqlhosts file:
     ssoalias         ontlitcp        hostname      1526   s=7,csm=(GSSCSM)
3. On all Windows workstations:
   • latest version of IBM Informix-Connect must be installed
   • create concsm.cfg file in the C:\Program Files\IBM\Informix\Connect\etc folder with one row like this:
     GSSCSM("client=C:\Program Files\IBM\Informix\Connect\lib\client\csm\igsss11a.dll", "", "c=1,i=1")
   • run setnet32 and describe server like on my screenshot, don’t forget specify options: s=7,csm=(GSSCSM)
   • test using ilogin or define ODBC source; leave username and password fields empty

To check AD accounts from Unix or debug Kerberos and SSO use the following tools:

• klist, ldapsearch, ldaplist, getent
• krb-diag

Some text from Wikipedia for introduction:

pluggable authentication modules, or PAM, is a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independently of the underlying authentication scheme.

In my case the idea was to let users, who have accounts in the MS AD, log on to Informix Dynamic Server using their AD username and password.

Your OS must be ready to use PAM and Kerberos, configured like in this example for Solaris and MS AD.

So, lets start:

1. Better to limit number of enctypes for Kerberos, especially if KDC is Windows 2008 R2.
   To do that, add the flowing rows in the /etc/krb5/krb5.conf:
   [libdefaults]
default_tkt_enctypes = des-cbc-crc des-cbc-md5 arcfour-hmac-md5
default_tgs_enctypes = des-cbc-crc des-cbc-md5 arcfour-hmac-md5
default_etypes = des-cbc-crc des-cbc-md5 arcfour-hmac-md5
default_etypes_des = des-cbc-crc
2. To define Informix for PAM, add its name to /etc/pam.conf, I will name it ids_pam_service:
   ids_pam_service auth sufficient pam_krb5.so.1
ids_pam_service auth sufficient pam_unix_auth.so.1
   First line for Kerberos authentication, second to allow local users (defined in passwd) to login through pam-enabled Informix alias.
3. Configure one or many Informix aliases to enable PAM. Do that in sqlhosts file:
   <alias_name>           ontlitcp        <host_name>      <service_name>    s=4,pam_serv=(ids_pam_service),pamauth=(password)
   like in my example:
   onpam           ontlitcp        serv-inf01      1526    s=4,pam_serv=(ids_pam_service),pamauth=(password)

After Informix restart, PAM authentication will be enabled. Clients will be prompted to enter their local or AD credentials to connect.

If it doesn’t work, you can debug PAM, just touch /etc/pam_debug file and put auth.debug string in the /etc/syslog.conf file:
auth.debug /var/adm/dmessages
Keep in mind that spaces not allowed in syslog.conf, only tabs, and syslog daemon restart is required.

Main disadvantage of PAM is that due to limits of the PAM API, it is not possible for a PAM module to request a Kerberos service ticket from a Kerberos Key Distribution Center (KDC), allowing the user to utilize the application without re-authenticating. pam_krb5 only fetches ticket granting tickets, which involves prompting the user for credentials and are only used for initial login in an SSO environment. To fetch a service ticket for a particular application, and not prompt the user to enter credentials again, that application must be specifically coded to support Kerberos, as pam_krb5 cannot itself get service tickets.

I will describe how to configure Informix for Kerberos and Single Sign-On (SSO) authentication in the next post.

Update: each account in AD must have the following attributes specified: uid, uidNumber, gidNumber, unixHomeDirectory, loginShell. The easiest way to do that is using ADSI Edit snap-in for MMC.

Yes, it is possible. We can connect from BusinessWorks applications to MS SQL database using Windows authentication. Even more, we can run TIBCO Domain and store all data in MS SQL instance, where only Windows authentication enabled. Do it simply.

Get the latest version of Microsoft SQL Server JDBC Driver from microsoft.com site. Unzip it. Then:

• copy sqljdbc.jar to <tibco_home>\tpcl\5.6\jdbc
• copy \auth\x86\sqljdbc_auth.dll to C:\WINDOWS\SysWOW64 (or to C:\WINDOWS\System32 on 32bit system) and to <tibco_home>\tra\5.6\bin

Configure your BW-application to use appropriate driver and connection string:
JDBC_Driver: com.microsoft.sqlserver.jdbc.SQLServerDriver
URL: jdbc:sqlserver://<server_name>;
instanceName=<instance>;
databaseName=<database>;
integratedSecurity=true;

The process must be started under Windows domain user who has the database rights. To do that just start domain Hawk Agent service under this user (should be in local admins or has appropriate permissions). Then all BW-applications on this particular machine, started by TIBCO Administrator or using appmanage tool, will also run under this user and can connect to MS SQL database using Windows authentication.

If you would like to create TIBCO Domain and use MS SQL Win auth only instance to store the data, you can use the same JDBC driver and URL. All you need is just run TIBCO Administrator and Hawk Agents in the TIBCO domain under Win domain user who has the database rights.

If the EMS admin password has been lost, it is easy to recover. In EMS all local users and their passwords stored in the users.conf file by default. You can find correct file in the tibemsd.conf:
users = "C:/tibco/tibco/cfgmgmt/ems/data/users.conf"

In the users.conf find admin user:
admin:$2$Z1t2XOwg$vsDsUT+GVRHRiX+OPU/oOsn0:"Administrator"
and remove encrypted password between colons:
admin::"Administrator"

Then restart EMS daemon. Connect to your EMS using EMS Administration Tool and login as admin without password:
> connect
Login name (admin):
Password:
Connected to: tcp://localhost:7222

Then set a new password for admin:
tcp://localhost:7222> set password admin 123
Password of user 'admin' has been modified

If you manage EMS in the TIBCO Administrator, then you need to change EMS admin password there. Start TIBCO DomainUtility, select “TIBCO EMS Plugin”, “Update TIBCO EMS Server”, press “Next”. Select domain and enter domain (not EMS!) admin user name and password. Select EMS server to update, and change EMS password there, test connection on the next screen and press “Next” to save new configuration.

So, EMS password recovery is very simple, isn’t it?

Here are my notes applicable for Solaris 10. First of all install latest patches – a lot of related things fixed (but new bugs may appear :))

1. Synchronize the system clock with AD server
   domain ntp server(s) must be in /etc/inet/ntp.conf
   then restart ntp daemon svcadm restart /network/ntp
2. Solaris server must have a record in the DNS
3. Domain name and name servers (DNS servers) must be in /etc/resolv.conf
4. In the /etc/nsswitch.conf file dns and files must be specified for hosts and ipnodes
   ...
hosts: dns files
ipnodes: dns files
...
5. In the /etc/nodename and /etc/hostname.<nic> files host name must be specified only, not a fully qualified domain name
6. Run adjoin script. You can find it here. It will:
   • auto-detects the Active Directory domain controllers
   • creates a machine account (also called a Computer object) for the Solaris host in Active Directory and generates a random password for this account
   • configures the Solaris host as a Kerberos client of the Active Directory domain controller by using the /etc/krb5/krb5.conf file
   • configures the /etc/krb5/krb5.keytab file on the Solaris host by using the keys for the machine account (also called host credentials)

   Execute adjoin script with following options:
   ./adjoin -d <domain_name> -p <administrator_principal> -f -x
   where -f to delete any pre-existing computer account for this host and -x to debug output.

   If your domain if geographically distributed with a lot of domain controllers (DC), script can detect inappropriate controllers. Just before entering admin password, check prepared adjoin-krb5.conf.XXXXXX file in the /tmp folder and remove unnecessary controllers from it.

   Adjoin script can stop work with pkcs11_kernel.so syntax error on some SUN servers:
   + ./adjoin[859]: /usr/lib/security/$ISA/pkcs11_kernel.so:: syntax error
   Then all you need is just to temporary rename this file and execute adjoin again
   mv /usr/lib/security/$ISA/pkcs11_kernel.so /usr/lib/security/$ISA/pkcs11_kernel.so.orig
   when adjoin finished successfully, rename it back

7. Run ldapsearch and klist to check Kerberos
   ldapsearch -R -T -h dc1.xxxxxx.com -o authzid= -o mech=gssapi -b CN=Computers,DC=xxxxxx,DC=com -s sub cn=<computer_name>
klist
klist -e -k /etc/krb5/krb5.keytab
8. Enable dns client and cache daemons
   svcadm enable /network/dns/client
svcadm enable /system/name-service-cache
9. In the /etc/nsswitch.ldap file dns and files must be specified for hosts and ipnodes
   ...
hosts: dns files
ipnodes: dns files
...
10. Set up a server as a client of an LDAP. Execute ldapclient
    ldapclient -v manual \
-a credentialLevel=self \
-a authenticationMethod=sasl/gssapi \
-a defaultSearchBase=dc=xxxxxx,dc=com \
-a defaultSearchScope=sub \
-a domainName=xxxxxx.com \
-a defaultServerList="dc1.xxxxxx.com dc2.xxxxxx.com dc3.xxxxxx.com" \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor="passwd:ou=Accounts,ou=European office,dc=xxxxxx,dc=com?sub;ou=Accounts,ou=American Office,dc=xxxxxx,dc=com?sub" \
-a serviceSearchDescriptor=group:ou=Groups,dc=xxxxxx,dc=com?sub
    ldapclient should finish without errors. To check use ldapclient list
11. Edit the /etc/nsswitch.conf file: files and ldap must be specified for passwd and group only
    ...
passwd: files ldap
group: files ldap
hosts: dns files
ipnodes: dns files
networks: files
protocols: files
...
    remove ldap from everywhere else
12. Restart LDAP client
    svcadm restart /network/ldap/client
13. Add pam_krb5.so.1 in the /etc/pam.conf file
    ...
login auth sufficient pam_krb5.so.1
krlogin auth required pam_krb5.so.1
krsh auth required pam_krb5.so.1
ktelnet auth required pam_krb5.so.1
other auth sufficient pam_krb5.so.1
other account required pam_krb5.so.1
other password sufficient pam_krb5.so.1
...

To ensure that users could login on the host under their AD accounts, accounts in AD must have following additional attributes:
uid the same as sAMAccountName
uidNumber unique number
gidNumber number
unixHomeDirectory for example /tmp
loginShell for example /usr/bin/bash or /bin/false

To check it use getent or ldapsearch
getent passwd <uid>
ldapsearch -R -T -h dc1.xxxxxx.com -b "ou=Accounts,ou=American Office,dc=xxxxxx,dc=com" -o mech=gssapi -o authzid='' "uid=<uid>"

If you would like read more: link to SUN’s article “Using Kerberos to Authenticate a Solaris 10 OS LDAP Client With Microsoft Active Directory”.

Yesterday TIBCO announced vulnerability in TIBCO Runtime Agent (TRA). To be more specific, in TIBCO Domain Utility (domainutility and domainutilitycmd). To say even more specifically, vulnerability is that the local users (whether they are on your server?) have read access to the properties files where administration domain credentials are stored. Not in clear text, by the way. Here is the advisory.

Here is the list of all security advisories for TIBCO products.

I like TIBCO.

If you need to change password for admin user in TIBCO Administrator please keep in mind that it is not enough just to change the admin password from Administrator GUI. But whole procedure is not so complex.

1. Always have full backup of Administrator configuration files and repository files or database!
2. Change admin password in the Administrator GUI.
3. Start DomainUtility on each machine in the TIBCO Domain, select Server Settings => Update Domain Credentials and change password there or use domainutilitycmd and ChangeDomainCredentials.xml as a template.
4. Make sure that password has been changed in tibcoadmin_<domain>.tra file. Or you can put new password manually there like this repo.securePassword=#!tibco and use obfuscate utility to encrypt it.
5. Restart Administrator daemon and Hawk Agents everywhere in TIBCO domain.

That’s all. But, if you change password in the Administrator GUI only, and Administrator service (on the Windows) or daemon (on the Unix) has been restarted as nothing is working as before, then you can find picture like this on your screen when you try to login into Administrator. If your daemon has been started using nohup utility as mine, then you have a chance to find little more in the nohup.out file:
com.tibco.infra.repository.RepoSecurityException: Can not read policy domain for repository server HM : Failed in authentication.

If you start DomainUtility at this time and try to change password there, following error will appear.

To solve this problem you need to disable security option in the tibcoadmin_<domain>.tra file
#repo.isSecurityEnabled=true
repo.isSecurityEnabled=false
then restart Administrator.

Now it is possible to continue the procedure from step 3: DomainUtility will work. When password will be changed, you can enable security back in tra file. Do not forget to restart Administrator daemon and Hawk Agents everywhere in the domain!

After all, redeployment of all applications may be necessary.