I have installed koha 20.11 and samba4 AD and Kerberos .
I have tried to connect by the terminal using the below LDAP search query and its working fine,
$ ldapsearch -H ldap://MyIp -x -D "CN=Administrator,CN=Users,DC=domain,DC=in" -w "pass#123" -b "CN=Users,DC=domain,DC=in" sAMAccountName=admin
I want to connect samba AD to koha LDAP.
but I am getting the following error.
LDAP search failed to return object : 00002020: Operation unavailable without authentication at /usr/share/test_koha/lib/C4/Auth_with_ldap.pm line 98.
samba configuration :
[global]
dns forwarder = <myIp>
netbios name = DC1
realm = <DC my domain>
server role = active directory domain controller
workgroup = <DC>
idmap_ldb:use rfc2307 = yes
server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate, dns, s3fs
#ldap server require strong auth = no
ldap server require strong auth = no
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/<DC my domain>/scripts
read only = No
koha ldap conf.:
<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
<ldapserver id="dc1">
<hostname>ldap://ldap domain</hostname>
<base>CN=Domain Computers,CN=Users,DC=koha,DC=kohaconnect,DC=in</base>
<user>CN=Administrator,CN=Users,DC=koha,DC=kohaconnect,DC=in</user>
<pass>pass#123</pass>
<replicate>1</replicate>
<update>1</update>
<auth_by_bind>1</auth_by_bind>
<update_password>1</update_password>
<principal_name>CN=%s#koha.kohaconnect.in</principal_name>
<mapping>
<userid is="sAMAccountName"></userid>
<password is=""></password>
</mapping>
</ldapserver>
NOTE : we are not using koha`s default command, i.e. koha-common and service memcached.
• You are getting this error because you have not restarted the koha-common service and the Memcached service inherent. You can do so by running the below command and checking if the configuration has correctly been done for you: -
‘ $ service koha-common restart && service memcached restart
$ export PERL5LIB=/usr/share/koha/lib/ && export KOHA_CONF=/etc/koha/sites/library/koha-conf.xml && perl /usr/share/koha/opac/cgi-bin/opac/opac-user.pl userid=user1 password=password ‘
Please ensure to adapt the path to the koha-conf.xml, as well as user and password. Also, please note that you can bind to LDAP as user at REALM or NT4DOM\username. So, try doing that.
Find the below link for reference: -
https://openschoolsolutions.org/koha-ldap-setup/
Related
After I configured the configuration below, it doesn't connect to the Active Directory. I can't login with a account of the Active Directory. What could be the problem?
I have a Ubuntu server 18.04 with Apache Guacamole v1.0.0. installed. I want to use LDAP-authentication to authenticate users. I have downloaded the guacamole-auth-ldap-1.0.0.jar and jldap-4.3.jar extensions.
ldap-hostname: 10.10.10.21, 10.10.10.22
ldap-port: 389
ldap-user-base-dn: OU=Users,DC=zoz,DC=lan
ldap-username-attribute: CN
ldap-config-base-dn: OU=Users,DC=zoz,DC=lan
ldap-encryption-method: none
I expect it should connect to the domain controller. But when I use the command "ldapsearch" it gives me the error that it can't contact the LDAP-server.
Please try this
ldap-hostname:
ldap-port:
ldap-username-attribute: sAMAccountName
ldap-encryption-method: none
ldap-search-bind-dn: binduser#domain.com
ldap-search-bind-password: password
ldap-config-base-dn: dc=domain,dc=local
ldap-user-base-dn: OU=myou,DC=domain,DC=local
ldap-user-search-filter:(objectClass=user)(!(objectCategory=computer))
ldap-max-search-results:400
Restart Tomcat and gucad
I'm accessing Cloud SQL from App Engine in the same project. I have set the password to the root user. I'm able to connect from mysql command line remotely thusly:
C:>mysql -u root -h xxx.xxx.xxx.xxx -p <- IP address of my Cloud SQL
Enter password: <--- I supply passw0rd
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 20913
Server version: 5.7.14-google-log (Google)
However, when I try from App Engine:
Code snippet:
url = "jdbc:google:mysql://myproject:us-central1:myinst/mydb?user=root;password=passw0rd";
conn = (Connection) DriverManager.getConnection(url);
The error I get is:
com.google.gae.server.Connect getConnection: ERROR. Could not get connection. Access denied for user 'root;password=passw0rd'#'cloudsqlproxy~xxx.xxx.xxx.xxx' (using password: NO)
I have tried the url with just the user only, but no luck.
Appreciate any suggestions.
Found my error. The Java URL should have been:
url = "jdbc:google:mysql://myproject:us-central1:myinst/mydb?user=root&password=passw0rd";
I replaced the ; with &.
Works now.
When running SchemaSpy get error:
Connection failed because of the following error: "no pg_hba.conf entry for host "xxx.xxx.xxx.xxx", user "xxxx", database "xxx", SSL off"
The error occurs because the database does require an SSL connection.
Is there a way to turn on the SSL flag for a connection in SchemaSpy, I opened up the jar file but couldn't find anything. I know the PostgreSQL JDBC Driver supports SSL so this should be theoretically possible.
Otherwise if any one knows any opensource/freeware tools for reverse engineering a postgresql database with an SSL connections, that would help a lot.
Thanks.
Do it like this:
java -jar schemaSpy_5.0.0 -t pgsql -host your-host-url -db your-database-name -s your-database-schema -u your-username -p your-password -connprops "ssl\=true;sslfactory\=org.postgresql.ssl.NonValidatingFactory" -o path-to-your-output-directory -dp path-to-your-jdbc-driver-jar-file
The trick: adding some additional parameters using the -connprops option: we are setting SSL to true (ssl parameter) and we are asking the client (i.e., the driver) to unconditionally accept the SSL connection (sslfactory parameter).
Per the PgJDBC documentation, use the ssl=true option in your URL's parameters, e.g.
jdbc:postgresql://myhost/mydb?ssl=true
If the host doesn't have a valid certificate or the cert doesn't match its hostname you can disable SSL validation too.
SchemaSpy accepts a JDBC URL for the connection, so this will work fine.
I am trying to configure the Sonar with windows Active directory. I am getting the below error.
ERROR [rails] Error from external users provider: Unable to retrieve details for user xxx.xxx in
The below configurations are done in sonar.property file
# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
ldap.authentication: simple
sonar.security.savePassword=true
sonar.authenticator.createUsers=true
ldap.url=ldap://xxxx.group.root.ad
# User Configuration
ldap.user.baseDn=OU=Users,OU=Customs,OU=Group,dc=group,dc=root,dc=ad
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
# Group Configuration
ldap.group.baseDn=OU=Customs,OU=Group,dc=group,dc=root,dc=ad
#ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))
ldap.group.request=((objectClass=group)(member={dn}))
anybody have an idea to fix the issue in sonar.
Regards
Arun.
I had similar issue with LDAP 2.1 on SonarQube 5.6 (LTS)
tl'dr
This format of ldap.user.request worked for me -
ldap.user.request=(uid={login})
If you are still reading ...
Here are some things that helped me resolving the issue
sonar.log :
Turn the DEBUG ON and look for the actual ldap search query thats getting build and the ldap context.
2017.03.14 00:35:04 DEBUG web[o.s.p.l.LdapSearch] Search: LdapSearch{baseDn=dc=test,dc=com, scope=subtree, request=(&(objectClass=inetOrgPerson)(uid={0})), parameters=[harvey], attributes=[mail, cn]}
2017.03.14 00:35:04 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap.test.com, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.security.principal=uid=user,ou=People,dc=test,dc=com, com.sun.jndi.ldap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
ldapsearch :
Run lapsearch command with same parameters from the logs (step #1)
$ldapsearch -x -L -D"uid=user,ou=People,dc=test,dc=com" -w"pass" -b"ou=People,dc=test,dc=com" "(uid=harvey)" mail cn
sonar.properties -
here is my working LDAP configuration
#General Configuration
sonar.security.realm=LDAP
ldap.url=ldaps://ldap.test.com
ldap.bindDn=uid=user,ou=People,dc=test,dc=com
ldap.bindPassword=pass
#User Configuration
ldap.user.baseDn=ou=People,dc=test,dc=com
ldap.user.request=(uid={login})
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
#Group Configuration
ldap.group.baseDn=ou=Group,dc=test,dc=com
ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid}))
ldap.user.request & ldap.group.request
From the step #1 you could find out whats the correct format for query filter parameter in your case and values for bindDn (-D) and baseDn _-b)
Hope this helps =)
Thanks!
I've just encountered a similar error in Sonar 5.1.1. Here's how I solved it:
The Base DN is incorrect for use with an AD server. This worked for me:
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
Anonymous authentication to an AD server apparently doesn't work with Sonar's LDAP plugin (this assumption is supported by the documentation which specifies anonymous authentication against an AD server as "untested"). You'll need to specify a Bind DN (here meaning a user) for connecting with the AD server:
ldap.bindDn=<user>#<domain>
ldap.bindPassword=secret
all.
Have been trying to get remoted JMX with JAAS authentication to work usin Camel version 2.10.3 + Java 6.
The app uses Java DSL and is "hand wired", and runs with system properties:
-Dcom.sun.management.jmxremote.authenticate=true
-Djmx.remote.x.login.config=StagingJmxAuthConfig
-Dorg.apache.camel.jmx.usePlatformMBeanServer=true
-Djava.security.auth.login.config=./src/main/resources/conf/ldap-auth.config
-Dcom.sun.management.jmxremote.ssl=false
-Dorg.apache.camel.jmx.createRmiConnector=true
-Dorg.apache.camel.jmx.rmiConnector.registryPort=9140
However, for all intents and purposes it seems that I might as well be running with authentication/authorization switched off.
Debugging into the JRE's JMX and JAAS classes (and Camel as well), note the following:
In the class org.apache.camel.management.DefaultManagementAgent:
cs = JMXConnectorServerFactory.newJMXConnectorServer(url, null, server);
This in turn later creates an instance of javax.management.remote.rmi.RMIJRMPServerImpl with an empty Map for the env constructor argument.
Now, I wonder if there's something that's just escaping me -- when a request later comes to the the connector, and the javax.management.remote.rmi.RMIServerImpl does a doNewClient(), it can't possibly trigger any JAAS activity?
Line 197-208 of RMIServerImpl - remember Camel sets "env" to null, which is translated to empty map:
JMXAuthenticator authenticator =
(JMXAuthenticator) env.get(JMXConnectorServer.AUTHENTICATOR);
if (authenticator == null) {
/*
* Create the JAAS-based authenticator only if authentication
* has been enabled
*/
if (env.get("jmx.remote.x.password.file") != null ||
env.get("jmx.remote.x.login.config") != null) {
authenticator = new JMXPluggableAuthenticator(env);
}
}
Am I correct in assuming that to get remoted, JAAS authenticated JMX to work one must hand code the JMX RMI connector setup?
Shouldn't Camel have provided an environment to get JAAS to work? Doesn't even seem to touch the JAAS config file...
UPDATE: SOLVED
Setting the following system properties on the VM did the trick:
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9410
-Dcom.sun.management.jmxremote.authenticate=true
-Djmx.remote.x.login.config=StagingJmxAuthConfig
-Dorg.apache.camel.jmx.usePlatformMBeanServer=true
-Djava.security.auth.login.config=./src/main/resources/conf/ldap-auth.config
-Dcom.sun.management.jmxremote.ssl=false
-Dorg.apache.camel.jmx.createRmiConnector=false
-Dcom.sun.management.jmxremote.login.config=StagingJmxAuthConfig
For us, using a secured LDAP, the following is the login config:
StagingJmxAuthConfig {
com.sun.security.auth.module.LdapLoginModule REQUIRED
java.naming.security.authentication="simple"
java.naming.security.principal="cn=Directory Manager"
java.naming.security.credentials="PASSWORD"
userProvider="ldap://LDAPHOST:389/BASEDN"
userFilter="(&(uid={USERNAME})(appRole=SOME_VALUE))"
authzIdentity=monitorRole
debug=true
useSSL=false;
};
Now I'm able to connect using jmxterm:
java -jar jmxterm-1.0-alpha-4-uber.jar -l service:jmx:rmi:///jndi/rmi://THEHOST:9410/jmxrmi -u LDAPUSER -p LDAPPASS
Note that the JNDI RMI name is missing the "/camel" postfix -- this is the only difference, it seems.
HOORAY!
In essence:
Use Java6 authenticated JMX remoting
Set org.apache.camel.jmx.createRmiConnector=false
Set org.apache.camel.jmx.usePlatformMBeanServer=true
The example above also shows how to connect to a search protected LDAP, which is actually isolated as the application in question uses a different LDAP for JNDI lookup for JMS.