I want to be able to log into mobilefirst console on my MobileFirst v6.3 Server which is running on a Liberty Profile using accounts from an LDAP repository.
I have edited my server.xml with the following LDAP Registry and LTPA configuration:
<ldapRegistry id="AD_Example" realm="WASLTPARealm"
host="example.com" port="389" ignoreCase="true"
baseDN="dc=example,dc=com,dc=ar"
bindDN="cn=binduser,cn=Users,dc=example,dc=com,dc=ar"
bindPassword="ThisIsAnExample"
ldapType="Microsoft Active Directory">
<activedFilters userFilter="sAMAccountName=%v"
userIdMap="user:sAMAccountName">
</activedFilters>
<group name="worklightadmingroup">
<member name="user1"/>
</group>
<group name="worklightdeployergroup">
<member name="user1"/>
</group>
<group name="worklightmonitorgroup"/>
<group name="worklightoperator"/>
</ldapRegistry>
<ltpa keysFileName="ltpa.keys" keysPassword="WebAS" expiration="120"/>
I took some info from the following places:
ftp://ftp.software.ibm.com/software/products/en/MobileFirstPlatform/docs/v630/mobilefirst_platform_foundation_doc.pdf (Page 127)
worklight server authentication with Ldap
But I can't seem to get this running. There is also going to be a DataPower integration scenario, but I need to test the LDAP connection first and I thought this might be the best approach. Any suggestions?
EDIT: Here you can take a look at the full logs (Console, Messages and ffdc). There is an "LDAPConnection" exception, but I can't understand the info it is giving to me.
I have succeeded logging into worklightconsole by using a user in a LDAP registry (in my case an OpenLDAP, not a Microsoft Active Directory). What I find strange is that you are specifying groups as <ldapRegistry> children, shouldn't your groups be defined in your LDAP registry (and not in the server.xml) ?
And then you can use the group activedFilters
<activedFilters
userFilter="(&(sAMAccountName=%v)(objectcategory=user))"
groupFilter="(&(cn=%v)(objectcategory=group))"
userIdMap="user:sAMAccountName"
groupIdMap="*:cn"
groupMemberIdMap="memberOf:member" >
</activedFilters>
given in example there (there is a part on Microsoft Active Directory Server, of course you'll have to adapt to your case).
Also according to this doc (in Feature configuration elements click on ldapRegistry; you'll have all the attributes and children nodes that can be used), <ldapRegistry> doesn't seem to possess <group> child.
The following LDAP exception is emitted : javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1
data 775 means that your user account (apmovil1) is locked. You must ask the LDAP administrator to unlock your user and then use the right password in the server.xml file since it is probable it was locked due to too many connection attempts with a wrong password.
Related
I'm going to describe an odd situation.. We have a product with a properly working CAS and LDAP integration. The problem is that not all of our clients use LDAP, which is fine, EXCEPT that the integration is still in place and so CAS is actively attempting to connect to the ldap server (and failing of course). It attempts to connect every five minutes, which creates a very bloated Tomcat log. My goal is to prevent it from attempting to connect without gutting the integration. I'm hoping someone knows of a way to prevent or manage when/how CAS attempts to connect to the defined LDAP server.
I've attempted to remove key components of the CAS property file as well as the deployerConfigContext.xml but the integration has too many dependencies, and I haven't been successful.
Here are some of the properties that are used in the cas.properties file. Setting the ldap.auth.enabled to false allows our integration to not use LDAP when authenticating the user but doesn't prevent CAS from attempting to connect to the LDAP server:
ldap.auth.enabled=false
ldap.url=ldap://xyz.customurl.com
ldap.useStartTLS=false
ldap.rootDn=DC=xyz,DC=xyz,DC=com
ldap.baseDn=DC=xyz,DC=xyz,DC=com
ldap.connectTimeout=3000
ldap.managerDn=CN=xyz,CN=Users,DC=xyz,DC=xyz,DC=com
ldap.managerPassword=xyz
ldap.authn.searchFilter=(&(sAMAccountName={user})(objectClass=user))
ldap.domain=123.456.7.890
ldap.pool.minSize=1
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
ldap.pool.blockWaitTime=3000
ldap.pool.validatePeriod=300
ldap.pool.prunePeriod=300
ldap.pool.idleTime=600
ldap.usePpolicy=false
ldap.allowMultipleDns=true
This is the relevant section from the deployerConfigContext.xml. I've tried commenting the entire ldap section but have received various other errors that caused TomCat to crash:
<bean id="ldapAuthenticationHandler"
class="org.jasig.cas.authentication.LdapAuthenticationHandler"
p:principalIdAttribute="sAMAccountName"
c:authenticator-ref="authenticator" lazy-init="true"/>
<ldaptive:ad-authenticator id="authenticator"
ldapUrl="${ldap.url}"
userFilter="${ldap.authn.searchFilter}"
bindDn="${ldap.managerDn}"
bindCredential="${ldap.managerPassword}"
allowMultipleDns="${ldap.allowMultipleDns:false}"
connectTimeout="${ldap.connectTimeout}"
validateOnCheckOut="${ldap.pool.validateOnCheckout}"
failFastInitialize="false"
blockWaitTime="${ldap.pool.blockWaitTime}"
idleTime="${ldap.pool.idleTime}"
baseDn="${ldap.baseDn}"
maxPoolSize="${ldap.pool.maxSize}"
minPoolSize="${ldap.pool.minSize}"
validatePeriodically="${ldap.pool.validatePeriodically}"
validatePeriod="${ldap.pool.validatePeriod}"
prunePeriod="${ldap.pool.prunePeriod}"
useSSL="${ldap.use.ssl:false}"
subtreeSearch="${ldap.subtree.search:true}"
useStartTLS="${ldap.useStartTLS}"/>
The stack trace for the CAS to LDAP server connection is huge. Here is a small snippet. I can attach the whole thing if that is useful.
org.ldaptive.provider.ConnectionException:
javax.naming.CommunicationException: ldap.url.com:389 [Root exception
is java.net.UnknownHostException: ldap.url.com
I toggle between JDBC and LDAP/AD Handlers. Ensure that you comment out your ldap handler under:
deployerConfigContext.xml
xpath:
/beans
/bean[class=org.jasig.cas.authentication.AuthenticationManagerImpl]
/property[name=authenticationHandlers]
/list/
We satisfactorily resolved this by disabling this log4j property in the log4j configuration file in CAS:
<Logger name="org.ldaptive.pool.BlockingConnectionPool" level="debug">
<AppenderRef ref="console" />
</Logger>
Another option may have been to create a log4j filter and target the particular message that was causing the tomcat file to become huge.
I installed WSO2 AM(API Manager) 1.10.0 and used the user-mgt.xml from working AM 1.9.0, but now I cannot login to carbon admin UI.
API Manager is configured with LDAP read only primary user store.
Additionally API Manager is configured to work with default H2. But I think this is not a reason.
If I configure API Manager with a standard user store (without any changes to user-mgt.xml, i.e. without adding readOnlyLdap config and removing default JDBC UserStoreManager), login to admin-dashboard works OK.
I got the warning message from wso2carbon.log:
TID: [-1234] [] [2016-07-03 05:55:54,731] WARN {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - Failed Administrator login attempt 'admin[-1234]' at [2016-07-03 05:55:54,730+0000] {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil}
I made the changes as suggested per I am unable to login to admin-dashboard application in WSO2 API manager , unfortunately that solution did not work for me.
Basically I installed brand new WSO2 am 1.10.0, with default settings, all works fine, until I changed user-mtg.xml to enable LDAP, I cannot login to carbon/admin UI anymore. So LDAP does not work out of the box with wso2 am 1.10.0? I followed the instructions related to LDAP set up, but it just did not work.
The strange thing is, LDAP works with am 1.9.0. So any difference in setting up LDAP between version 1.10.0 and 1.9.0?
UPDATE:
For the moment, I gave up integarting LDAP with wso2 am 1.10.0. I moved to SAML2. But keep the question open in case someone has worked out of this with a solution, or this might help others. Thanks.
What is the value of the GetAllRolesOfUserEnabled property under AuthorizationManager in user-mgt.xml?
<AuthorizationManager class="org.wso2.carbon.user.core.authorization.JDBCAuthorizationManager">
<Property name="AdminRoleManagementPermissions">/permission</Property>
<Property name="AuthorizationCacheEnabled">true</Property>
<Property name="GetAllRolesOfUserEnabled">false</Property>
</AuthorizationManager>
That property is not part of the 1.9 config and in 1.10 the default config has this set to false and we were seeing similar login issues. Setting this to true resolved this issue for us.
Joe
I can provide following hints.
Since you haven't mentioned about the master-datasources.xml, I doubt the following. Do you have a external userstore database used in 1.9.0? If so, have you pointed 1.10.0 to the same database?
Log doesn't clearly say whether it failed due to authentication or authorization error. To find this out, you need to enable debug logs for the package org.wso2.carbon.user.core. This can be done in the repository/conf/log4j.properties file and needs a restart. Then, when your next login attemp fails, it will show you more details.
I'm trying to set up the user mapping on SonarQube (Latest) so it can fetch the organizational structure from LDAP.
I already installed the LDAP plugin on Sonar (1.5.1), and created a minimal configuration to connect the two:
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://ldap:389
# User Mapping
ldap.user.baseDn=ou=users,ou=udd,dc=example,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={uid}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
All my users are under the example.com domain:
But then, as I try to login to Sonar using the LDAP entries I get the following error on the logs:
Error from external users provider: exception Java::OrgSonarApiUtils::SonarException: Unable to retrieve details for user dev1 in <default>
Which is pretty frustrating, since all those properties are configured on the configuration file above.
Any ideas about the source of this issue?
EDIT:
I found this when I increased the log depth to DEBUG:
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap:389, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, com.sun.jndi.ld
ap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapUsersProvider] integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
javax.naming.directory.InvalidSearchFilterException: integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
at com.sun.jndi.toolkit.dir.SearchFilter.format(SearchFilter.java:602) ~[na:1.7.0_95]
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1785) ~[na:1.7.0_95]
...
I don't see why is an integer supposed to be expected between the {}'s, and that doesn't make much sense compared to my LDAP structure.
Try to set ldap.user.request to (&(objectClass=inetOrgPerson)(uid={login}) (instead of using (uid={uid})).
Details:
The LDAP Plugin does not recognise {uid} and therefore doesn't know what to do with it. It then passes it to the LDAP javax.naming API, which chokes on this. This behaviour is made explicit at SonarQube startup (logs in my case):
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={uid})), realNameAttribute=cn, emailAttribute=mail}
Using {login} instead (keyword shown in the documented default values) will let the LDAP Plugin build a well-formed request with a {0}:
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={0})), realNameAttribute=cn, emailAttribute=mail}
The javax.naming API will then replace this {0} by a parameter which SonarQube will set to the actual username value you fill in the login form.
I have jetty working with SSL set up, client and server certificates (X.509) provided as required according to Spring Security and upto this it all seems working fine and verified by logs.
Now! The problem is when I access a secure page, client(Chrome) is sending a certificate and server is receiving it successfully but after that it is returning me an empty user. Does any body have any idea what is happening here?
I am providing some information about what I am trying here :
Environment
Windows/Jetty (version: 8.1.11.v20130520)/Spring Security (3.2.0)
Connector in jetty (version: 8.1.11.v20130520)
<connector implementation="org.eclipse.jetty.server.ssl.SslSocketConnector">
<port>9443</port>
<keystore>src/test/resources/server.jks</keystore>
<needClientAuth>true</needClientAuth>
<keyPassword>password</keyPassword>
<password>password</password>
</connector>
Security Configuration file
<sec:x509 subject-principal-regex="CN=(.*?)"
user-service-ref="myUserDetailsService" />
Log extract
09:42:24:214 DEBUG org.springframework.security.web.authentication.preauth.x509.SubjectDnX509PrincipalExtractor (SubjectDnX509PrincipalExtractor.java:43) - Subject DN is 'CN=rod, OU=Spring Security, O=Spring Framework'
09:42:24:218 DEBUG org.springframework.security.web.authentication.preauth.x509.SubjectDnX509PrincipalExtractor (SubjectDnX509PrincipalExtractor.java:58) - Extracted Principal name is ''
The subject-principal-regex you use is wrong. If you want the extracted principal to be rod for the DN in the log message, set the pattern to CN=(.*?), (note the comma at the end). Btw, I think it is the default pattern, so you might as well just skip this setting.
Element <security:x509 /> is used to enable X.509 authentication in spring security.
Attribute subject-principal-regex of element <security:x509 /> is used to provide a regular expression to extract user name out of client certificate.
Regular expression helps in customizing which part do we want to extract out of object of client certificate as our user, like first middle or what ever as specified in regular expression and I was getting null user because of invalid regular expression.
Further more, attribute subject-principal-regex is optional and if we don't provided it explicitly then corresponding class (SubjectDnX509PrincipalExtractor) constrtuctor provides it with following, by default regex "CN=(.*?)(?:,|$)"
Here is the issue,
The JAAS realm connects to the database fine, the user name and password match, the session is authenticated. HOWEVER, none of the roles seem to be getting into the Principal. Tomcat's isInUserRole returns false for every role, and tomcat security doesn't see them either.
Here is the realm configuration in the Server.xml
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="TomcatTimedLogin"
userClassName="com.tagish.auth.TypedPrincipal"
roleClassNames="org.ovasp.java.jaas.RolePrincipal" />
Here is the login.config
TomcatTimedLogin
{
org.owasp.java.jaas.TomcatTimedLogin required
useDS=true
dsJNDI="jdbc/resourceName"
dbDriver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
dbURL="jdbc:sqlserver://server\\DBSERVER;databaseName=DBName"
dbUser="username"
dbPassword="password"
debug=true
loginTable="loginTable"
clippingLevel="3"
interval="10"
loginQuery="SELECT UserID,Password FROM Users WHERE LogonUserName=? AND RetirementDate is null"
rolesQuery="SELECT Role.RoleDescription FROM User_Role,Role WHERE User_Role.UserID=? AND User_Role.RoleID=Role.RoleID";
};
And in catalina.properties I refer to the configuration like this
java.security.auth.login.config=file:///C:/config/login.config
When start the application I do get the following message in the Debug output, not sure why as all classes should be accessible by the server
SEVERE: Class org.ovasp.java.jaas.RolePrincipal not found! Class not added.
Any help would be appreciated. I have already read post after post and tutorial after tutorial, and those who do have this problem, don't have solution posted.
Btw, I am using Tomcat 5.5, not my choice, legacy code, you know how it is! I also using the OWASP login module (OWASPJaasLoginModule.jar). This jar file is located in the server/lib directory.
Okay... I solved it myself... again, VERY STUPID! If this was my code I would be mad at myself, but it is not, and after 4 days of screwing around with this app, I am close to fed up. The problem was that the CLASS is not
org.ovasp.java.jaas.RolePrincipal
its
org.owasp.java.jaas.RolePrincipal
STUPID!!!