I have setup Apache Drill version 1.15 in distributed mode on 3 nodes with ZK on the same 3 nodes.
Now, I am trying to configure Plain Authentication in Drill using PAM.
I already have 2 existing users in the 3 nodes with same password and they are present in /etc/passwd and /etc/shadow.
I have followed the steps mentioned here, to configure authentication setup on the Drill cluster.
But, on entering correct username and password, it throws Invalid Username/Password error.
My drill-override.conf looks like:
drill.exec: {
cluster-id: "[cluster_name]",
zk.connect: "[host1]:2181,[host2]:2181,[host3]:2181"
security.user.auth: {
enabled: true,
packages += "org.apache.drill.exec.rpc.user.security",
impl: "pam",
pam_profiles: [ "sudo", "[profile1]", "[profile2]" ]
}
}
I have set, user1 as an admin and user2 as normal user.
Is it that Drill, doesnt work with existing Users in the linux system and wants users to be created explicitly (which i really doubt), or anything else that I am missing?
pam_profiles is array of PAM profiles, not users.
Example of pam_profiles configs: pam_profiles: [ "sudo", "login" ]. See details in doc.
You can add other PAM profiles from your /etc/pam.d.
Related
OpenAM version -12 , Agent version 3.5 and 3.3 , tomcat version 7
I have tried to follow the link https://forums.alfresco.com/forum/installation-upgrades-configuration-integration/authentication-ldap-sso/sso-openam-06052012 to set up my J2EE Agent. Let me paste the steps after asking the question(see at the end)
but I am getting the error as asked below
Not able to configure J2ee agent on adding my customized data store for users
I have tried to use 3.5 version installed and uninstalled multiple times and tried previous version.
There is a nice discussion on this topic at http://database.developer-works.com/article/16009911/%22Cannot+obtain+Application+SSO+token%22+error
but it did not help me much.
I am using LDAP so I have used LDAP realm and subjects are showing up ok. Also I am observing that the policy tab has changed quite a bit from how it is described in the Blogs.
Now with the roadblock I am not sure how to proceed as the error is not giving me any clue what to do. I even added the file named AMConfig.properties in the classpath with username and password of the agent and tried the username and password of the OpenAM admin too as suggested in the discussion mentioned. but that too did not help.
The issue is the Tomcat now is not starting and giving error that AMConfig.properties properties are needed
I know the OpenAM Realm setup is good as I am able to login via this realm to another application (Liferay) where I just have to give the URL for use OpenAM integration. but after uninstallation of the agent the tomcat starts without any error and i am able to login to the application
-------------------Step copied from 1st link(modified)--------------------------
1. Configure your OpenAM agent (tried both 3.5 and 3.3 version on tomcat 7)
a. Log into OpenAM as the admin user and navigate to "Access Control -> (Your Realm) - where in my case LDAP Realm (other application using it without issue)
b. Select Policies -> New Policy
c. Enter Share as the policy name and then create 2 new URL Policy agent rules
d. 1st Resource Name = http://:/share/*
e. 2nd Resource Name = http://alfresco.domain.com:8080/share/*?*
f. Add a subjects - already part of LDAP Realm
g. Now select Agents -> J2EE - > (your J2EE agent)
h. Select the Application tab
i. Login Processing -> Login Form URI - add /share/page/dologin
j. Logout Processing -> Application Logout URL - add Map Key = share - Corresponding Map Value = /share/page/dologout
k. Not Enforced URI Processing - Add 2 entries - /share and /share/
l. Profile Attributes Processing - Select HTTP_HEADER and add Map Key = uid - Corresponding Map Value = SsoUserHeader (This is what I called my header in the alfresco-global.properties file - see below)
Auth chain
authentication.chain=external1:external,alfrescoNtlm1:alfrescoNtlm
alfresco.authentication.allowGuestLogin=true
SSO settings
external.authentication.enabled=true
external.authentication.defaultAdministratorUserNames=admin
external.authentication.proxyUserName=
external.authentication.proxyHeader=SsoUserHeader
NOTE- It does not seem possible to configure SSO where the Guest login has been disabled. There are webscripts used on the Alfresco repository that need guest login.
That concludes the setup for Alfresco and OpenAM
For Share you need to have the following section uncommented in your share-config-custom.xml
alfresco/web-extension/alfresco-system.p12
pkcs12
alfresco-system
alfrescoCookie
Alfresco Connector
Connects to an Alfresco instance using cookie-based authentication
org.alfresco.web.site.servlet.SlingshotAlfrescoConnector
alfrescoHeader
Alfresco Connector
Connects to an Alfresco instance using header and cookie-based authentication
org.alfresco.web.site.servlet.SlingshotAlfrescoConnector
SsoUserHeader
alfresco
Alfresco - user access
Access to Alfresco Repository WebScripts that require user authentication
alfrescoHeader
http://alfreso.domain.com:8080/alfresco/wcs
user
true
Notice I am not using the SSL cert and in my alfrescoHeader connector I have used SsoUserHeader (as setup in OpenAM) and the endpoint uses the alfrescoHeader connector
Now you need to add the OpenAM filter to the Share web.xml file
Add the following filter just before the Share SSO authentication support filter
Agent
com.sun.identity.agents.filter.AmAgentFilter
Add the following filter mapping to the filter-mapping section
Agent
REQUEST
INCLUDE
FORWARD
ERROR
----- End ----------
The error message is a bit misleading: the Cannot obtain application SSO token in general means that the agent was unable to authenticate itself. When you install the agent, the agent asks for a profile name and a password file, those values need to correspond to the agent profile configured within OpenAM.
To test if you can authenticate as the user, you could simply try to authenticate as the agent by making the following request:
curl -d "username=profilename&password=password&uri=realm=/%26module=Application" http://aldaris.sch.bme.hu:8080/openam/identity/authenticate
In the above command the realm value needs to be the same as the value for the "com.sun.identity.agents.config.organization.name" property defined in OpenSSOAgentBootstrap.properties (under the agent's install directory).
Having bad username/password combination is only one of the possible root causes for this exception though. It is also possible that during startup the agent was unable to connect to OpenAM to authenticate itself. In those cases the problem could be:
network error, firewall issues preventing the agent from contacting OpenAM
SSL trust issues: agent's JVM does not trust the certificate of OpenAM's container (only problem if you've installed the agent by providing OpenAM's HTTPS URL and the certificate is self-signed or just simply not trusted by the JVM)
I am using drupal 7.27 version in which I need to connect to moodle site and its database. So I used drupal module moodle_connection to connect it withmoodle site. As it does not offer any end feature functionality. I installed another module called moodle_views but unfortunately there is no data received from the moodle. When I debug I found that connection does not establish between both the sites.
I am calling moodle_connector_connect() function in custom module to connect to Moodle. But no success. And in the moodle connector settings I put the following information:
Database Type : mysql
Database Server : localhost
Database TCP Port : 3306
Database Name : drupal_moodle ('Name of the moodle database')
Database Prefix : mdl_
Database User : root
Database Password : (I don't have password for my database user so I kept blank)
Moodle URL : drupal_moodle (Moodle site url)
Please help me to get out of this.
Regards
Neha
Reading over the bug reports in the Drupal module moodle_connector, I noticed some issues related to setting values for the moodle database connection variables, and some issues with handling error conditions.
Combine this with your mention of blank password, suggests the following line might be a problem.
Reading moodle_connector.module, around line 51 I notice some lazy checking for unset parameters.
// Return false if settings are incomplete.
if (!$type || !$server || !$port || !$username || !$password || !$database) {
return FALSE;
}
It looks like the check for !$password will cause the function moodle_connector_connect() to exit and not connect to the moodle database if any of the values are unset or empty.
As a workaround, and a step in right direction security-wise, could you create a new MySQL user, specifically grant it the necessary privileges to allow Drupal to read the Moodle DB and set a password.
I would also strongly advise that you read over the MySQL 'post installation' section of the manual which advises setting a password on the root user accounts. Having no root password is convenient during initial installation, but is a security problem. Any ordinary user on the machine, or a nearby machine which can connect to port 3306, could gain full access to the database.
http://dev.mysql.com/doc/refman/5.1/en/postinstallation.html
How could you setup rules on Firebase which would allow a user to become a paid user of your app? For example, if I have the following data structure:
{
users: [
{
isPaid: false
},
{
isPaid: true
}
]
}
How could you setup firebase rules to not allow the user to update it themselves (by fudging a request), but still allow it to be updated automatically when they "pay" for your app?
I've thought about randomly generating a number and asking the user to enter that number or something like that, but I don't think that would work... Has anyone done something like this?
You'll need to have a server process that securely writes the paid flag using a Firebase secret (that can be found on Forge for your Firebase). Set the ".write" rule for /users/isPaid as false - the server code can bypass this rule since it knows the secret. You should call firebaseRef.auth(secret) from your server code first.
I have installed the openldap version 2.4.23 on windows xp and using the apache DS as a client.I can authenticate users on a client server I set up for testing.
My next step is to turn on a password policy. This is where things have gotten a bit hazy for me and I'm hoping someone can help me out.
i added a password policy also by using the followin command
ldapadd -x -c -f -D "cn=Manager,dc=maxcrc,dc=com" -w secret
but after addition of password policies how do i make them in effect.
The openldap documentation says the password policy module should be configured with the DN of the default policy.
i added the following lines in slapd.conf file
# invokes password policies for this DIT only
overlay ppolicy
# Default ppolicy
ppolicy_default "cn=passwordDefault,ou=policies,dc=maxcrc,dc=com"
but somehow it is not getting loaded , i have already spent more a lot of time on this, but i am not getting the proper guide for the same.
Can anyone shed some light on this in plain, layman's terms?
Thanks in advance.
My ldif file is as follows.
dn: cn=passwordDefault,ou=policies,dc=localdomain,dc=com
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: passwordDefault
sn: passwordDefault
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdMinAge: 1
pwdMaxAge: 90
pwdMinLength: 6
pwdInHistory: 4
pwdMaxFailure: 3
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 604800
pwdGraceAuthNLimit: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
after adding this policy and restarting the server i tried changing the password of existing as well as newly added users.
The server allows me to change the password to a string with length less than 6
whereas i have mentioned pwdMinLength: 6 in ldif.
as well as i tried changing the password more than once , but it allows me to change the password to recently used password, whereas the pwdInHistory: 4 in ldif.
The password policy doesn't work if you use the rootDN to execute the updates. You must use an existing admin account, or the user's own account.
It is not clear how you are setting the password when testing, but I would check if you are passing the password in the correct format, meaning that the server needs to receive the password in cleartext. Some clients would hash the value before sending the value to the OpenLDAP server, in which case it would be impossible for the OpenLDAP server to determine the length of password. The communication can and should be encrypted, but it shouldn't be pre-hashed. Hashing can be handled by the server:
pwdCheckQuality
If the value is 1 and the supplied password is in cleartext then a user supplied function (defined using the pwdCheckModule - if defined - will be called to check the password quality. If this function is not available then the password will be accepted (assuming it passes all the other tests defined by the various pwdPolicy attributes).
reference: http://www.zytrax.com/books/ldap/ch6/ppolicy.html
the rootdn bypass password policy, so do not use rootdn in your
ldappasswd command.
https://www.openldap.org/lists/openldap-technical/201102/msg00262.html
You can basically put any password (not empty thou) if setting passwords using ldappasswd and binding with rootdn.
It's a bit tricky situation since you cannot change the password with "passwd" command either for the user. In this case the password policy would kick in.
If you know the rootdn password, you can bypass everything.
I am using sfDoctrineGuard 5.x and I have configured my module credentials in security.yml like this:
all:
is_secure: true
credentials: [ admin ]
and my app/backend/config/security.yml:
default:
is_secure: true
I have tested using:
$this->getUser()->hasPermission('vendor'): returned true
$this->getUser()->hasPermission('admin'): returned false
so I guess the users are inheriting credentials right. But still users with other credentials can access the module!
I have 3 types of group admin, client and vendor and similar permissions: admin, client and vendor!
And users having 'client' or 'vendor' credentials can access the module ignoring the credentials defined in the security.yml after login !
What could be the problem? Can anyone give me some direction?
oh, I am using sfForkedApplyPlugin for registration and profile editing process, which I don't think causing the issue, as I am testing with predefined fixture data.
I figured out the problem just now!
It was the *is_super_admin* field in *sf_guard_user* table which was set to 1 for all my dummy users in fixture.yml :) !
That's why every users were getting access to all modules bypassing the credentials!