I have gone through other questions of stackoverflow but none seems to resolve my issue with configurating tomcat with ldap for manager access.
Here is what I have done
Configured JNDIRealm with ldap config.
Manager application deployed on tomcat.
I'm able to validate that user authentication is successful however the logs complain that there is no role associated.
2017-04-25 14:17:54,644 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- Checking constraint 'SecurityConstraint[HTMLManger and Manager command]' against GET /html --> true
2017-04-25 14:17:54,644 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- Checking constraint 'SecurityConstraint[HTMLManger and Manager command]' against GET /html --> true
2017-04-25 14:17:54,644 [http-8080-1] DEBUG org.apache.catalina.authenticator.AuthenticatorBase- Calling hasUserDataPermission()
2017-04-25 14:17:54,644 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- User data constraint has no restrictions
2017-04-25 14:17:54,644 [http-8080-1] DEBUG org.apache.catalina.authenticator.AuthenticatorBase- Calling authenticate()
2017-04-25 14:17:54,648 [http-8080-1] DEBUG org.apache.catalina.realm.CombinedRealm- Attempting to authenticate user "manager" with realm "org.apache.catalina.realm.JNDIRealm/1.0"
2017-04-25 14:17:54,667 [http-8080-1] DEBUG org.apache.catalina.realm.CombinedRealm- Authenticated user "manager" with realm "org.apache.catalina.realm.JNDIRealm/1.0"
2017-04-25 14:17:54,667 [http-8080-1] DEBUG org.apache.catalina.authenticator.AuthenticatorBase- Authenticated 'manager' with type 'BASIC'
2017-04-25 14:17:54,667 [http-8080-1] DEBUG org.apache.catalina.authenticator.AuthenticatorBase- Calling accessControl()
2017-04-25 14:17:54,667 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- Checking roles GenericPrincipal[manager()]
2017-04-25 14:17:54,667 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- Different realm org.apache.catalina.realm.LockOutRealm#2eeb0945 org.apache.catalina.realm.JNDIRealm#4af37bb8
2017-04-25 14:17:54,667 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- Username manager does NOT have role manager
2017-04-25 14:17:54,668 [http-8080-1] DEBUG org.apache.catalina.realm.RealmBase- No role found: manager
2017-04-25 14:17:54,668 [http-8080-1] DEBUG org.apache.catalina.authenticator.AuthenticatorBase- Failed accessControl() test
Note: I have validated that manager role exists in manager/WEB-INF/web.xml and also I have a ldap attribute called tomcatRole=manager. I have userRoleName="tomcatRole" in server.xml for the JNDIRealm config.
What part of configuration am I missing ?
Version: tomcat6
LDAP: OUD
Thanks.
I have identified the issue. The ACI's were missing on the ldap server due to which the tomcat process couldn't find the role on ldap. Added new aci's which resolved the issue.
Related
I'm using AD users to connect to SQL Server with keytab files containing the AD users authentication data.
The relevant section in the application.yaml looks like that:
datasource:
url: ${MSSQL_CONNECTION_STRING:jdbc:sqlserver://mysqlserv01.sqltestenv.srv:1111;DatabaseName=MY_DB;integratedSecurity=true;authenticationScheme=JavaKerberos;jaasConfigurationName=SQLJDBCDriver;}
driverClassName: com.microsoft.sqlserver.jdbc.SQLServerDriver
jpa:
database-platform: org.hibernate.dialect.SQLServerDialect
database: SQL_SERVER
show-sql: true
#open-in-view: false
hibernate:
ddl-auto: validate
dialect: org.hibernate.dialect.SQLServer2012Dialect
naming:
physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
The dependency in the pom.xml is:
<dependency>
<groupId>com.microsoft.sqlserver</groupId>
<artifactId>sqljdbc</artifactId>
<version>6.0.0</version>
</dependency>
My jaas.conf file looks like that (I copied it to both project root folder and the resources folder). The keytab file is present in both root folder and resources folder:
SQLJDBCDriver {
com.sun.security.auth.module.Krb5LoginModule required
principal="TSTUSRAD02#TESTNT.SOMETHING"
useKeyTab=true
debug=true
keyTab="TSTUSRAD02.keytab"
useTicketCache=false
doNotPrompt=true
};
And I pass the jass.conf in the VM Options:
-Dsun.security.krb5.debug=true -Djava.security.krb5.conf="<FULL PATH>\krb5.conf" -Djava.security.auth.login.config="jaas.conf"
I can see in the console output that the krb5.conf is found and loaded but not the jaas.conf (I also tried to provide the jaas.conf full path). It tries to send the logged in user (my user) as credentials and not the keytab described in the jaas.conf file.
Console output:
Loading krb5 profile at <FULL PATH>\krb5.conf
>>> Obtained TGT from LSA: Credentials:
client=<MY LOGGED IN USER>
server=krbtgt/MY USER DOMAIN#MY USER DOMAIN
authTime=20221030065701Z
startTime=20221030065701Z
endTime=20221030165701Z
renewTill=20221106065701Z
I have no idea what to try next... Any thoughts will be highly appreciated...
I have Jenkins set up on GCE and from there I am trying to access k8s cluster on GKE. I get unauthorized when I try to test a connection on the plugin.
I have enabled GKE API access, created a service account on GKE, created role and role binding.
Installed kubernetes plugin on Jenkins and configured it by providing kubernetes url, certificate and token. I still get following exception -
Expected is - Connection to Kubernetes cluster succeeds.
Actual is - Error testing connection https://35.193.108.106: java.security.cert.CertificateException: Could not parse certificate: java.io.IOException: Empty input (With Disabled Https)
AND
With (Disable https certificate check enabled)
Error testing connection https://35.193.108.106: Failure executing: GET at: https://35.193.108.106/api/v1/namespaces/default/pods. Message: Unauthorized. Received status: Status(apiVersion=v1, code=401, details=null, kind=Status, message=Unauthorized, metadata=ListMeta(_continue=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Unauthorized, status=Failure, additionalProperties={}).
Check gcp network rules settings and check connection with kubectl from jenkins vm. I use "Secret text" type credentials to store token. I use jenkins vm in same gcp network to skip such issues.
Service account creation in namespace jenkins with "admin" permissions
kubectl create namespace jenkins && kubectl create serviceaccount jenkins --namespace=jenkins && kubectl describe secret $(kubectl describe serviceaccount jenkins --namespace=jenkins | grep Token | awk '{print $2}') --namespace=jenkins && kubectl create rolebinding jenkins-admin-binding --clusterrole=admin --serviceaccount=jenkins:jenkins --namespace=jenkins
My camel route picks up files from a sftp endpoint configured with username and password. Before the connection is made, i get a prompt for username and password from Kerberos.
I skip this by pressing enter, and authentication proceeds as expected, the files i picked up. Edit: After going through the versioning logs and the program logs i'm not entirely sure this is what happend, and i cannot reproduce it.
What i see it that my (one) screen-copy with the Kerberos prompt coincides with the one of several logs showing authentication failure because my username is wrong.
Why do i get the prompt? My endpoint looks like this:
sendEmptyMessageWhenIdle: sendEmptyMessageWhenIdle=true
useHostFile: knownHostsFile=known_hosts&strictHostKeyChecking=yes
workDirectory: /omg/myprogram/${env}/WorkDirectory
fromParams: streamDownload=true&maximumReconnectAttempts=2&throwExceptionOnConnectFailed=true&consumer.bridgeErrorHandler=true&disconnectOnBatchComplete=true
mypassword: password=blablabla
fromUri: sftp://myuser#accept.server.nu:22/TST?${mypassword}
from: ${fromUri}&${sendEmptyMessageWhenIdle}&${routeScheduler}&delete=true&${useHostFile}&localWorkDirectory=${workDirectory}&${fromParams}
Actually when i dont use a hosts file the same thing happens:
useUserKnownHostsFile=false
The camel version is 2.22.2.
What can i do to disable Kerberos in Apache camel?
Could you please set preferredAuthentications attribute on the SFTP component and see if makes a difference? This is an example preferredAuthentications=publickey,keyboard-interactive,password. Documentation for FTP component here. The docs say if you don't set this, the component will use default list of mechanisms in JSCH.
Edit:
I see a similar question here but in JSCH perspective.
It appears that the Kerberos prompt appears when authentication with the provided user-name and password fails.
That is, i have not been able to reproduce the problem i described above but i have found that the Kerberos prompt appeared when the username was incorrect.
Log:
2019-01-31 12:42:30,767 DEBUG [main] myprogram.StartUpVerneProphet - - - Running with Spring Boot v2.0.8.RELEASE, Spring v5.0.12.RELEASE
2019-01-31 12:42:30,769 INFO [main] myprogram.StartUpVerneProphet - - - No active profile set, falling back to default profiles: default
2019-01-31 12:42:36,003 WARN [main] org.apache.camel.component.file.remote.SftpOperations - - - JSCH -> Permanently added 'accept.server.nu' (DSA) to the list of known hosts.
2019-01-31 12:43:01,537 WARN [main] org.apache.camel.component.file.remote.SftpOperations - - - JSCH -> Permanently added 'accept.server.nu' (DSA) to the list of known hosts.
2019-01-31 12:44:13,940 WARN [main] org.apache.camel.component.file.remote.SftpOperations - - - JSCH -> Permanently added 'accept.server.nu' (DSA) to the list of known hosts.
2019-01-31 12:44:24,963 WARN [main] org.apache.camel.component.file.remote.SftpConsumer - - - Error auto creating directory: TST due Cannot connect to sftp://faulty-username#accept.server.nu:22. This exception is ignored. org.apache.camel.component.file.GenericFileOperationFailedException: Cannot connect to sftp://faulty-username#accept.server.nu:22
at org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:144)
at org.apache.camel.component.file.remote.RemoteFileConsumer.connectIfNecessary(RemoteFileConsumer.java:197)
Screen-copy:
12:42:30,761 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - first clean up after appender initialization
12:42:30,763 |-INFO in c.q.l.core.rolling.helper.TimeBasedArchiveRemover - Multiple periods, i.e. 32 periods, seem to have elapsed. This is expected a t application start.
2019-01-31 12:42:30 DEBUG myprogram.StartUp - - - Running with Spring Boot v2.0.8.RELEASE, Spr ing v5.0.12.RELEASE
2019-01-31 12:42:30 INFO myprogram.StartUp - - - No active profile set, falling back to defau lt profiles: default
2019-01-31 12:42:36 WARN org.apache.camel.component.file.remote.SftpOperations - - - JSCH -> Permanently added 'accept.server.nu' (DSA) to the list of known hosts.
Kerberos username [root]:
Kerberos password for root:
2019-01-31 12:43:01 WARN org.apache.camel.component.file.remote.SftpOperations - - - JSCH -> Permanently added 'accept.server.nu' (DSA) to the list of known hosts.
Kerberos username [root]:
Kerberos password for root:
Unfortunately, i made only one screencopy, so i am unsure if there was any occasion where the Kerberos prompt appeared after i used the correct user-name.
It hasn't appeared totday.
We are using a service account to deploy our app to App Engine using Travis.
On every merged PR, Travis pulls the code from our GitHub repository, and pulls a Docker image which contains Google Cloud SDK and executes the gcloud app deploy command. We use a Service Account to perform the deployment with "Project Owner" role.
Everything used to work fine until I added a new service to the project which automates SSL certificate generation and renewal, along with a dispatch.yaml file to route traffic incoming from Let's Encrypt for domain verification. I needed to add more permissions to allow updating the SSL certificates we use for our custom domain. I removed the current service account, and created a new one with a new private key. I created a new role with the required permissions to update and view SSL certificates in addition to the previous permissions (all appengine.* permissions). I assigned the new role and the Project Owner role to the new account. After these changes, the deployment fails with the following error when executing the deploy command:
Permissions error fetching application [apps/hollowverse-c9cad]. Please make sure you are using the correct project ID and that you have permission to view applications on the project.
I used the same service account on my local machine with logging level set to debug. I got this error:
DEBUG: HttpError accessing <https://appengine.googleapis.com/v1/apps/hollowverse-c9cad?alt=json>: response: <{'status': '403', 'content-length': '335', 'x-xss-protection': '1; mode=block', 'x-content-type-options': 'nosniff', 'transfer-encoding': 'chunked', 'vary': 'Origin, X-Origin, Referer', 'server': 'ESF', '-content-encoding': 'gzip', 'cache-control': 'private', 'date': 'Wed, 02 Aug 2017 14:33:50 GMT', 'x-frame-options': 'SAMEORIGIN', 'alt-svc': 'quic=":443"; ma=2592000; v="39,38,37,36,35"', 'content-type': 'application/json; charset=UTF-8'}>, content <{
"error": {
"code": 403,
"message": "Operation not allowed",
"status": "PERMISSION_DENIED",
"details": [
{
"#type": "type.googleapis.com/google.rpc.ResourceInfo",
"resourceType": "gae.api",
"description": "The \"appengine.applications.get\" permission is required."
}
]
}
}
>
DEBUG: (gcloud.beta.app.deploy) Permissions error fetching application [apps/hollowverse-c9cad]. Please make sure you are using the correct project ID and that you have permission to view applications on the project.
The description says that appengine.applications.get is required to perform the deployment. Looking at the permissions granted to the role assigned to the Travis account we use to deploy, appengine.applications.get is clearly granted:
I assigned every possible App Engine and Project role to the account, but deployment still fails with the same error. However, using the default service account, which is automatically created for every new project on GCP, seems to be working.
I removed the current service account, and created a new one with a new private key.
This is where it went wrong. The new account had the same ID as the previous one. Although I could not find this behavior documented anywhere, it looks like that once an ID is used for a service account, it cannot be used again for a new account, even if the previous one is removed.
We created a new account with a new ID (travis2#hollowverse-c9cad.iam.gserviceaccount.com) instead of travis#hollowverse-c9cad.iam.gserviceaccount.com) and the issue is now resolved.
I've set up two Tomcat servers as described in the README's and the http://cxf.apache.org/ site. The tests for the IDP server work; I can see the WSDL for the web service. But when I go to https://localhost:8443/fedizhelloworld/secure/fedservlet, I just get a blank page.
The log output of the IDP server says:
16:56:45.379 [http-nio-9080-exec-7] DEBUG o.a.c.a.AuthenticatorBase - Security checking request GET /fediz-idp-sts/REALMA/STSServiceTransport
16:56:45.380 [http-nio-9080-exec-7] DEBUG org.apache.catalina.realm.RealmBase - No applicable constraints defined
16:56:45.381 [http-nio-9080-exec-7] DEBUG o.a.c.a.AuthenticatorBase - Not subject to any constraint
On the RP server, I see:
16:58:04.941 [http-bio-8443-exec-3] DEBUG o.a.c.a.FormAuthenticator - WsFedAuthenticator:invoke()
16:58:04.941 [http-bio-8443-exec-3] DEBUG o.a.c.a.AuthenticatorBase - Security checking request GET /fedizhelloworld/secure/fedservlet
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.a.FormAuthenticator - authenticate invoked
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.a.FormAuthenticator - reading configuration for context path: /fedizhelloworld
16:58:04.942 [http-bio-8443-exec-3] INFO o.a.c.a.FormAuthenticator - No valid principal found in existing session. Redirecting to IDP
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - Issuer url: https://localhost:9443/fediz-idp/federation
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - WAuth: null
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - WReq: null
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - HomeRealm: null
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - Freshness: null
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - SignIn Query: null
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - wreply=https://localhost:8443/fedizhelloworld/secure/fedservlet
16:58:04.942 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - wtrealm=urn:org:apache:cxf:fediz:fedizhelloworld
16:58:04.943 [http-bio-8443-exec-3] DEBUG o.a.c.f.c.p.FederationProcessorImpl - wctx=b6ae9556-5e4f-49ca-a9ee-493403cf1ab3
16:58:04.943 [http-bio-8443-exec-3] DEBUG o.a.c.a.FormAuthenticator - Save request in session '271D4C59304744F60BDF1B84B386896C'
16:58:04.943 [http-bio-8443-exec-3] DEBUG o.a.c.a.AuthenticatorBase - Failed authenticate() test
The README promises:
The browser is redirected to the IDP and prompts for username and password.
but I just get a blank page with the URL https://localhost:9443/fediz-idp/federation?wa=wsignin1.0&wreply=https%3A%2F%2Flocalhost%3A8443%2Ffedizhelloworld%2Fsecure%2Ffedservlet&wtrealm=urn%3Aorg%3Aapache%3Acxf%3Afediz%3Afedizhelloworld&wct=2015-12-03T15%3A58%3A04.942Z&wctx=b6ae9556-5e4f-49ca-a9ee-493403cf1ab3
My guess is that there is something wrong with the configuration but what?
Make sure you have both WARs (fediz-idp.war and fediz-idp-sts.war) deployed on the IDP server.
When you have, you should see this output right after Not subject to any constraint:
2015-12-04 10:19:25,030 [http-nio-9443-exec-8] INFO org.apache.cxf.fediz.service.idp.STSPortFilter - STSAuthenticationProvider.wsdlLocation set to https://localhost:9443/fediz-idp-sts/REALMA/STSServiceTransportUT?wsdl
2015-12-04 10:19:25,117 [http-nio-9443-exec-8] INFO org.springframework.web.context.support.GenericWebApplicationContext - Refreshing Flow ApplicationContext [federation]: startup date [Fri Dec 04 10:19:25 CET 2015]; parent: WebApplicationContext for namespace 'idp-servlet'
2015-12-04 10:19:25,118 [http-nio-9443-exec-8] INFO org.springframework.beans.factory.support.DefaultListableBeanFactory - Replacing scope 'request' from [org.springframework.web.context.request.RequestScope#447feb96] to [org.springframework.web.context.request.RequestScope#2709bb72]
2015-12-04 10:19:25,129 [http-nio-9443-exec-8] INFO org.apache.cxf.fediz.service.idp.service.jpa.DBInitApplicationListener - Inital DB already loaded
2015-12-04 10:19:25,131 [http-nio-9443-exec-8] INFO org.apache.cxf.fediz.service.idp.service.jpa.DBInitApplicationListener - Inital DB already loaded