I am now trying to configure for the LDAP authentication in /admin/auth_config.php?auth=ldap.
I would like to know what the Bind settings does? Is it necessary to fill in the DN and Password under Bind settings for LDAP to work?
And I have encountered an error code auth_ldap_noconnect when trying to sync the users through LDAP from the cron script. What could be the causes for this error?
The Bind settings are necessary - without them Moodle can't connect to your LDAP server. They determine how Moodle will access the LDAP server.
CN = your Common Name
OU = your Organizational Unit
DC = your Domain Component
Those are all part of the LDAP data Interchange Format (LDIF) and they determine how the LDAP tree is filtered. See http://en.wikipedia.org/wiki/LDAP_Data_Interchange_Format.
So in Moodle you probably need a Distinguished name like:
cn=YourServiceAccountName,ou=YourSchool,ou=Service Accounts,DC=yourdc,DC=co,DC=uk
And you'll probably also have to list the Contexts where your students are found:
ou=yourschool,DC=yourdc,DC=co,DC=uk;
User attribute might = samaccountname (for MS Active Directory)
Related
New to WSO2 so be gentle. I'm building an instance of Ellucian's Ethos wso2 identity server (version 5.10.0) and when I point it to Active Directory the Tomcat server does start and I can login as the admin user I created in Active Directory for Ethos, but when I run "wso2server.bat -Dsetup" I see errors like the following in the wso2carbon.log file and I want to know if I should be worried.
ERROR {org.wso2.carbon.identity.scim.common.internal.SCIMCommonComponent} - Error occurred while setting SCIM attributes for the Admin org.wso2.carbon.user.core.UserStoreException: Error in adding SCIM metadata to the admin in tenant domain: carbon.super
[LDAP: error code 16 - 00000057: LdapErr: DSID-0C090D77, comment: Error in attribute conversion operation, data 0, v2580 ]; remaining name 'CN=ouruser,OU=OurContainer'
ERROR {org.wso2.carbon.identity.scim2.common.utils.AdminAttributeUtil} - Error occurred while updating the admin user's attributes in Tenant ID : -1234, Error : One or more attributes you are trying to add/update are not supported by underlying LDAP for user : ouruser org.wso2.carbon.user.core.UserStoreException: One or more attributes you are trying to add/update are not supported by underlying LDAP for user : ouruser
I intend for AD to be treated as a read-only LDAP database so I have "eis.admin.create.user" set to false in the eis_config.properties file and the Ethos admin user I created in AD does not have AD admin privileges. AD is only being used for authentication and for pulling attributes and releasing them to service providers. Could it be trying to write attributes to the Ethos admin user I created in AD?
Or is it an attribute mapping issue (mapping AD attributes back into Ethos?). I noticed in the eis_config.properties file the following mappings section
eis.add.claim.logonname=sAMAccountName
eis.add.claim.upn=userPrincipalName
eis.add.claim.objectguid=objectGUID
eis.add.claim.udcid=udcid
eis.add.claim.personid=employeeNumber
eis.add.claim.challenge.question.uris=
eis.add.claim.challenge.question.1=
eis.add.claim.challenge.question.2=
eis.add.claim.resource.type=pager
And i know for a fact that attributes like "udcid" are specific to Ellucian products and are not an LDAP attribute in AD so I set it to "cn". And for the attribute mappings above that are blank I mapped them to real AD attributes to see if I could get rid of the errors but they remain.
Any thoughts?
Have you tried eis.add.claim.employeeType=memberOf in your eis_config.properties file?
And are the AD values correct for:
eis.admin.role.name=,
eis.admin.username=,
eis.userstore.ConnectionURL=,
eis.userstore.ConnectionName=,
eis.userstore.ConnectionPassword=,
eis.userstore.UserSearchBase=,
eis.userstore.UserNameAttribute=,
eis.userstore.GroupSearchBase=,
eis.userstore.SharedGroupSearchBase=,
eis.userstore.defaultRealmName=,
along with the user-mgt.xml settings?
I installed Openldap in server and after that added the user into the ldap,below screen show show the added user through Apache Active Directory
Now in keycloak i added user federation as a openLdap and its connecting to ldap without any issue,but when i am trying to sync the user i am getting message
Success! Sync of users finished successfully. 0 imported users, 0
updated users
So no user import from ldap to keycloak ,below is the related ldap connection information in keycloak .
Thanks to #EricLavault and one of company colleague at last Keycloak able to import the user successfully. Below changes i have done to fix the issue.
Change the User Object Classes=*
Created a new entry ou=People then created user under it
In Keycloak used Users DN = ou=user,ou=people,dc=suredev20
After this its start throwing below exception
ERROR [org.keycloak.storage.ldap.LDAPStorageProviderFactory] (default
task-1931) Failed during import user from LDAP:
org.keycloak.models.ModelException: User returned from LDAP has null
username! Check configuration of your LDAP mappings. Mapped username
LDAP attribute: uid, user DN:
cn=subodh123,ou=user,ou=People,dc=suredev20, attributes from LDAP:
{sn=[joshi123], cn=[subodh123], createTimestamp=[20191118180647Z],
modifyTimestamp=[20191118180647Z]}
Which is fixed by using Username LDAP attribute = cn as ldap username Attribute description in openldap case bydefault cn
User entries are not stored correctly in your directory. In fact you shouldn't use cn=root as a container as it's supposed to represent the directory manager and should be used for binding and other operations but not for structuring your directory.
Instead, you should use the default user container (at least for OpenLDAP and Apache DS) that is ou=people,dc=suredev20, ie. you need to move cn=subodh
from cn=subodh,ou=user,cn=root,dc=suredev
to cn=subodh,ou=people,dc=suredev20
Also, in Keycloack you need to set users dn accordingly : ou=people,dc=suredev20
(you can try with ou=user,cn=root,dc=suredev without moving subodh entry but not recommended).
I currently try to configure Discourse to only allow users in a specific ldap group to log in. Discourse has a plugin called discourse-ldap auth ( https://github.com/jonmbake/discourse-ldap-auth ). This plugin uses the omniauth ldap module: https://github.com/omniauth/omniauth-ldap
My discourse plugin configuration (the configuration is actually used by the discourse plugin for the omniauth ldap module):
ldap enabled: true
ldap hostname: the hostname of my ldap server
ldap port: 389
ldap method: plain
ldap base: the base of my ldap server
ldap uid: userPrincipalName
ldap bind dn: Nothing
ldap password: Nothing
ldap filter: (&(userPrincipalName=%{username})(memberOf=cn=[the name of the required group],ou=....,[base]))
When using this configuration, nobody can log in to the forum. When I use the bind dn and password, everybody can log in.
I also tried this filter without success (copied from my ldap servers filter):
(&(&(&(userPrincipalName=%{username})(memberOf=[dn of the group]))))
What do I have to configure, to only allow users in that specific group to log in?
I didn't found any errors or indicators in the log. Please help!
Thanks fou your help and attention!
You do need the "ldap dn" and "ldap password". Those are the credentials used to authenticate to LDAP so you can lookup people's accounts. Usually, that is a service account only used by your application.
The filter should probably look something like this:
(&(sAMAccountName=%{username})(memberOf:1.2.840.113556.1.4.1941:=[dn of the group]))
Users will usually log in with the sAMAccountName, which is usually called just the "username". Whenever you see an account in the DOMAIN\username format, that username is the sAMAccountName.
The userPrincipalName is usually in the format of username#domain.com. It is sometimes the same as the email address, but it doesn't have to be.
The crazy number I put in that query tells Active Directory to search recursively through groups. So that would allow you to put groups into your authentication group, and members of that new group would be given access to your application too. Without that, only direct members of that group will have access.
Is it possible to connect to an OpenLDAP server as the active directory with this form
" username#domain "
I have tested this form, it connects with active directory but with openLdap i have to put the full DN.
Does anyone has any idea how to modify my openLDAP to connect as AD if it's possible
Thanks.
If you wants to authenticate Openldap and AD users using same DN you need to add proxy to AD server from openldap server.
You need to use back_ldap module to make AD database as subordinate of Openldap database.
You can add custom attribute in openldap/ad for uniqueness of user mostly we find email attribute as common on both sides.
If you want to use alternative bind names like the userPrincipalName (username#realm) with openLDAP, you need the rewrite/remap overlay slapo-rwm coming with version 2.4.
A very simple example would be:
# Typed and not tested!
rwm-rewriteEngine on
rwm-rewriteContext addName
rwm-rewriteRule "(.*)" "userPrincipalName=$1" ":"
rwm-rewriteMap ldap upn2dn "ldap://host/dc=my,dc=org?dn?sub"
rwm-rewriteContext bindDN
rwm-rewriteRule ".*" "${upn2dn($0)}" ":#I"
EDIT
In reply to the question in your comment: LDAP as a protocol has no concept of uniqueness, it's a product feature. With OpenLDAP for example, you can use the unique overlay to enforce uniqueness for certain attribute types in suitable backends. With phpLDAPAdmin you can configure the attribute types that shall be tested for uniqueness by that client.
Problem: Why realm is required for some users in beeline connection,even its ensured with ldap authentciation.?
While connecting with beeline,with configured ldap authentication some users connected with without realm and some users connect with realm authentication.This is because of while creating users in active directory ,display name differ with logon name.
During authentication,it can only validate by logon name only,but some users validate also by display name.Actually its only validate by on logon name but here it seems validate by display name.
Please refer the attached images and provide the ideas if you overcome this.
Thanks,
Mathes