JBoss 5.0.0.GA datasource security-domain and login-config.xml - database

Running into an issue where our datasources for two different DBMS (MS-SQLServer and Informix) are not picking up the security-domain configuration in the login-config.xml file.
Our datasources look like this:
<datasources>
<local-tx-datasource>
<jndi-name>ourTX</jndi-name>
<connection-url>jdbc:informix-sqli://our.server.com:1526/wlms:informixserver=ol_db</connection-url>
<driver-class>com.informix.jdbc.IfxDriver</driver-class>
<security-domain>ourDS</security-domain>
<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
<metadata>
<type-mapping>InformixDB</type-mapping>
</metadata>
<min-pool-size>5</min-pool-size>
<max-pool-size>50</max-pool-size>
<prefill>yes</prefill>
<prepared-statement-cache-size>10</prepared-statement-cache-size>
<idle-timeout-minutes>5</idle-timeout-minutes>
<new-connection-sql>set lock mode to wait 4;set isolation to cursor stability;</new-connection-sql>
<check-valid-connection-sql>SELECT count(*) FROM dummy;</check-valid-connection-sql>
</local-tx-datasource>
</datasources>
And our login-config.xml has the following entry:
<application-policy name="ourDS">
<authentication>
<login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">
<module-option name="userName">user</module-option>
<module-option name="password">-4e5f8b6c4217c342c03b57ed16d31678</module-option>
<module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=ourTX</module-option>
</login-module>
</authentication>
</application-policy>
However, once the JBoss server is deployed, we get an error like this for Informix:
13:23:13,521 WARN [JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Incorrect password or user com.informix.asf.IfxASFRemoteException: user#my.computer.com is not known on the database server.)
And for MS-SQLServer we get a similar error to Informix which looks like:
13:25:23,053 WARN [JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user ''. The user is not associated with a trusted SQL Server connection.)
Now if, we comment out the security-domain element in the *-ds.xml file and replace it with a simple user name and a clear text password, both datasource work with both database engines. We're using the 'all' server configuration in JBoss. We've made sure that login-config.xml is getting loaded on start-up. And the hqsqldb-ds.xml using the security-domain element works. But using our added application-policy to the login-config.xml, it seems that the datasource does not get the values when establishing a new connection.
Any ideas what we're doing wrong? Have we missed something?

We were testing the validity of the datasource through the admin-console. Because of where we were testing the database, this is bug in the JBoss EAP 5.0.0.GA version. While not confirmed, may also be a but bug in the admin-console for 5.0.1.GA and maybe 5.0.2.GA.
Everything above was actually working.

Related

Define Datasource validation in Thorntail

In WildFly standalone configuration we can define a validation query in the datasource. In case the DB connection is lost, after the background validation milliseconds defined, the connection can be recovered. Without this validation if the connection is lost, it will not be recovered until the application is restarted.
<datasource jndi-name="java:jboss/datasources/MyDS" pool-name="MyDS" enabled="true" use-java-context="true">
<connection-url>jdbc:postgresql://localhost:5432/myDB</connection-url>
<driver>postgresql</driver>
<security>
<user-name>dbuser</user-name>
<password>password</password>
</security>
<validation>
<check-valid-connection-sql>select 1</check-valid-connection-sql>
<validate-on-match>false</validate-on-match>
<background-validation>true</background-validation>
<background-validation-millis>30000</background-validation-millis>
</validation>
</datasource>
How can I achieve the same in Thorntail project.yml file?
thorntail:
datasources:
data-sources:
MyDS:
driver-name: postgresql
connection-url: jdbc:postgresql://localhost:5432/myDB
user-name: dbuser
password: password
I tried adding a validation node, but it didn't work
validation:
check-valid-connection-sql: select 1
validate-on-match: false
background-validation: true
background-validation-millis: 30000
Here's an example PostgreSQL datasource taken from this documentation: https://docs.thorntail.io/2.7.0.Final/#_example_datasource_definitions It includes connection validation, too.
thorntail:
datasources:
data-sources:
MyDS:
driver-name: postgresql
connection-url: jdbc:postgresql://localhost:5432/postgresdb
user-name: admin
password: admin
valid-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
validate-on-match: true
background-validation: false
exception-sorter-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
Other connection validation options, including those that you use, are described in the same documentation.

WiX Toolset - How to determine the SQL Server DATA path

I've tried to do this a few ways. Here's my latest attempt, which does not work, but should help illustrate what I'm looking to do.
Note: My assumption for the GetSQLServerInstalledInstance Id is that it will return one instance.
My goal is to find the DATA directory path for an instance of SQL Server installed on the machine that will also be installing my companies product.
<util:RegistrySearch Id='GetSQLServerInstalledInstance'
Variable='SQL_SERVER_INSTALLED_INSTANCE'
Root='HKLM'
Key='SOFTWARE\Microsoft\Microsoft SQL Server'
Value="InstalledInstances"
Format="raw" />
<util:RegistrySearch Id='GetSQLServerInstalledInstanceName'
Variable='SQL_SERVER_INSTALLED_INSTANCE_NAME'
Root='HKLM'
Key='SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL'
Value="[SQL_SERVER_INSTALLED_INSTANCE]"
Format="raw"
After="GetSQLServerInstalledInstance" />
<util:RegistrySearch Id='GetSQLServerInstallPath'
Variable='SQL_SERVER_INSTALL_PATH'
Root='HKLM'
Key='SOFTWARE\Microsoft\Microsoft SQL Server\[SQL_SERVER_INSTALLED_INSTANCE_NAME]\Setup'
Value="SQLPath"
Format="raw"
After="GetSQLServerInstalledInstanceName" />
<SetProperty Id='SQL_SERVER_FILE_PATH' Value="[SQL_SERVER_INSTALL_PATH]\DATA" After="CostFinalize" Sequence="first" />
In the end, I'm looking for the SQL_SERVER_FILE_PATH property to contain this path. (e.g. C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA)
It's also important that the calls are sequenced at that subsequent calls can contain information derived from previous calls.
I'm still fairly new to WiX, but I could imagine how to do this pretty easily if the SetProperty element allowed a RegistrySearch child element to set it's value. Can this be handled by a sequence of CustomActions that would act similar to a SetProperty element that allows a RegistrySearch child element to set it's value?
Thanks
I found a simpler method for determining the SQL Server DATA directory path using WiX. For future reference, this was how I solved this:
<Property Id='SQL_SERVER_INSTALL_PATH'>
<RegistrySearch Id='GetSQLServerInstallPath' Root='HKLM'
Key='SOFTWARE\Microsoft\MSSQLServer\Setup'
Name='SQLPath' Type='directory' Win64="yes" />
</Property>
<SetProperty Id='SQL_SERVER_DATA_PATH' Value="[SQL_SERVER_INSTALL_PATH]DATA" After="CostFinalize" Sequence="first" />
Hope this helps others

How to select only specific active directory groups to sync with Sitecore

Let say the Active Directory have Group A, B and C.
How to specified like only Group A sync to Sitecore?
Thanks for any help! :)
If you just want to get the members in a specific group, you can do this using a customFilter.
If for membership, you can add the following under your membership element in the web.config:
<add name="ad"
type="LightLDAP.SitecoreADMembershipProvider"
connectionStringName="ManagersConnString"
applicationName="sitecore"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
connectionUsername="user"
connectionPassword="12345"
attributeMapUsername="sAMAccountName"
enableSearchMethods="true"
customFilter="(memberOf=cn=test role 1,OU=CRM,DC=VM)"
/>
Just ensure that you have a connection string configured for your AD, which would be something like: <add name="ManagersConnString" connectionString="LDAP://testsrv/OU=Managers,DC=testdomain,DC=sitecore,DC=net" />
And ensure that your custom filter gets to the specific group you're trying to allow access for. I used LDAP Browser to navigate to my groups using a simple GUI and then copied the path.
See more in the documentation about customFilters in section 4.1.
Try to specify your group in the connection string:
<connectionStrings>
<add name="ManagersConnString"
connectionString="LDAP://testsrv/OU=Managers,DC=testdomain,DC=sitecore,DC=net" />
</connectionStrings>
This example is copied from the Documentation (see chapter 2.1.3). In this example, Managers is just a sample organization unit. But this is a normal LDAP connection string, so you can insert and filter there whatever you want.

Camel route using spring-ws client occasionally throws javax.xml.transform.stax.StAXSource exception

I have a camel 'seda' route that contains code roughly:
JaxbDataFormat jaxb = new JaxbDataFormat(false);
jaxb.setContextPath("com.example.data.api");
from("seda:validate")
.marshal(jaxb)
.to("spring-ws:" + getDataServiceURL())
.unmarshal(jaxb)
I send an object from com.example.data.api, the JaxbDataFormat formatter sets it up as a SOAP request and passes it along wo spring-ws to actually send to my service. This works like a charm most of the time.
I say "most" because every now and then, spring-ws throws an exception like so:
org.springframework.ws.client.WebServiceTransformerException: Transformation error: Can't transform a Source of type javax.xml.transform.stax.StAXSource; nested exception is javax.xml.transform.TransformerException: Can't transform a Source of type javax.xml.transform.stax.StAXSource
at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:608)
at org.springframework.ws.client.core.WebServiceTemplate.sendAndReceive(WebServiceTemplate.java:537)
at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:492)
at org.springframework.ws.client.core.WebServiceTemplate.sendSourceAndReceive(WebServiceTemplate.java:479)
at org.springframework.ws.client.core.WebServiceTemplate.sendSourceAndReceive(WebServiceTemplate.java:470)
at org.apache.camel.component.spring.ws.SpringWebserviceProducer.process(SpringWebserviceProducer.java:81)
at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
The core of that is this error message: "Can't transform a Source of type javax.xml.transform.stax.StAXSource".
None of that makes sense. The Jaxb marshalling will have already made sure that the object in question is an XML string (according to any debug logging I do). Furthermore, this exact code works most of the time and only occasionally will fail. It appears random.
For instance, I ran a test just a few minutes ago where I sent a message into my route and got this error. I then restarted my service and resend the exact same message... and it worked like a charm. Same code; same environment; same test -- two different results.
It's this randomness that makes this so maddening. Any ideas what I should be looking for to making sure this never happens?
The issue is not with Camel but Spring-WS. Modifying the transformerFactoryClass in WS template config would work
<bean id="baseCamelMarshallerWSTemplate" class="org.springframework.ws.client.core.WebServiceTemplate" scope="prototype">
<constructor-arg ref="messageFactory" />
<property name="messageSender">
<ref bean="httpSender"/>
</property>
<property name="checkConnectionForError" value="true"/>
**<property name="transformerFactoryClass" value="com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl"/>**
</bean>
If you still face the issue, please share spring WS config and a test case

Property 'attributeMapFailedPasswordAnswerLockoutTime' cannot be mapped to schema attribute 'lockoutTime' as the attribute is already in use

I am trying to use the ADMembershipProvider to connect to a local ADAM server and I am getting the error in the title. If I remove the enable password reset and the properties it relies on I am able to connect.
I have tried to google it and nothing has come up. Below is my provider config. Any advice would be highly appreciated.
<providers>
<add name="AspNetActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADService"
connectionUsername="[username]"
connectionPassword="[password]"
connectionProtection="Secure"
enableSearchMethods="true"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
applicationName="/"
description="Default AD connection"
requiresUniqueEmail="true"
clientSearchTimeout="30"
serverSearchTimeout="30"
attributeMapPasswordQuestion="department"
attributeMapPasswordAnswer="division"
attributeMapFailedPasswordAnswerCount="badPwdCount"
attributeMapFailedPasswordAnswerTime="badPasswordTime"
attributeMapFailedPasswordAnswerLockoutTime="lockoutTime"
attributeMapEmail = "mail"
attributeMapUsername = "userPrincipalName"
maxInvalidPasswordAttempts = "5"
passwordAttemptWindow = "10"
passwordAnswerAttemptLockoutDuration = "30"
minRequiredPasswordLength="7"
minRequiredNonalphanumericCharacters="1"/>
</providers>
FYI... The closest thing to a similar result was someone who got this error on a similar attribute and he just restarted the machine. That didn't work for me. I did find this article as well http://blogs.msdn.com/b/dansellers/archive/2005/10/20/483272.aspx but I am struggling to get the LDAP admin to make this change. Especially since we already have those properties.
I finally had the LDAP admin perform the steps in the following link an we are up and running.
http://blogs.msdn.com/b/dansellers/archive/2005/10/20/483272.aspx

Resources