I have multiple DIT in LDAP. (dc=example,dc=com and dc=test,dc=com). Under create credential validator instance, I am not able to give more than one search base. I tried to give SEARCH BASE:
dc=example,dc=com dc=test,dc=com
dc=example,dc=com : dc=test,dc=com
dc=example,dc=com ; dc=test,dc=com
dc=example,dc=com | dc=test,dc=com
Should I try any other combinations?
Note : Connecting to multiple datastores can be accomplished.
You can't support multiple LDAP Suffix from a single PingFederate Data Source or Password Credential Validator. I would create a single Data Source and then create a single PCV for each suffix you wish to search. If you are using the HTML Form Adapter, you can then use multiple PCV when attempting to authenticate a user's identity.
Related
Im currently playing with openldap (+phpldapadmin)
Howver i dont know how to create a new adminuser for ldap.
Tried to clone the CN=admin as another name, but in that case in phpldapadmin.
I can login with that new account however i got the following error
This base cannot be created with PLA. in the tree view.
Sadly nor search is possible with that.
Is there any tip howto create multiple CN user under the DC=example,DC=org ?
I'm running salt under unprivileged user. The idea is to make some states that can be executed under different unix users, but without giving root privileges to anybody who executes the state. So the question is if it is possible to somehow tell salt to ask for password when switching the user either via runas or when specifying user like in cmd.run. Effectively I would like to achieve something like:
salt '*' cmd.run runas=myuser ask_for_pass=true 'whoami'
test1:
> enter pass for myuser:
'myuser'
or in the same in a form of state:
whoami:
cmd.run:
- user = myuser
- ask_for_pass = true
or one more example that is closer to what i'm actually trying to achieve - installing jboss for a different user (salt-minions and master are running as user "salt"):
$ salt 'host1' state.jboss runas=jboss_user ask_for_pass=true
Salt doesn't do exactly what you're wanting to do here.
Your best bet would probably to use the client_acl or external_auth master config options.
These both will allow you to give either a system user or ldap user the rights to run specific commands.
client_acl docs for authorizing system users: https://docs.saltstack.com/en/latest/ref/clientacl.html
external_auth docs for authenticating external users from PAM or LDAP: https://docs.saltstack.com/en/latest/topics/eauth/index.html
So for example, if you had set up LDAP external_auth, you could require your users to do the following on the command line:
salt -a ldap '*' state.jboss
Salt would then prompt the for a user and password.
How do I setup basic user permissions so users can't run commands like "Hubot die" or "Hubot show storage"?
I can see there is a script called hubot-auth but that seems to be for implementing it in other scripts and not controlling existing commands.
There is a small chapter about it in Automation and Monitoring with Hubot book (shameless plug). Excerpt:
Assigning Roles
Only Admin users can assign roles. You don't have to create a role before assigning. All you have
to do is tell Hubot who is who using hubot <user> has <role> role. And you no longer have to use
those cryptic IDs anymore:
Tomas hubot Jesse Pinkman has developer role
Hubot Tomas: Ok, Jesse Pinkman has the 'developer' role.
Check the assigned roles using hubot what roles does <user> have?:
Tomas hubot what roles does Jesse Pinkman have?
Hubot Tomas: Jesse Pinkman has the following roles: developer.
To remove the role from somebody, use hubot <user> does not have <role> role:
Tomas hubot Jesse Pinkman does not have developer role
Hubot Tomas: Ok, Jesse Pinkman doesn't have the 'developer' role.
You can assign multiple roles to multiple users.
Applying Roles
Now, time to break the bad news. While Hubot Auth is pretty flexible, you will have to edit your
scripts to apply those roles. Luckily, there is not much to edit. There is a simple function that
checks if user has a role - robot.Auth.hasRole(msg.envelope.user, '<role>').
This is how you use it in a script:
module.exports = (robot) ->
robot.respond /do dangerous stuff/i, (msg) ->
if robot.auth.hasRole(msg.envelope.user, 'developer')
doDangerousStuff(msg)
else
msg.reply "Sorry, you don't have 'developer' role"
doDangerousStuff = (msg) ->
msg.send "Doing dangerous stuff"
As stated in the original answer, you have to be a Hubot admin in order to assign roles. To define the Hubot admins, you have to set the HUBOT_AUTH_ADMIN environment variable to a comma-delimited string of IDs of the admins. If you're using Slack, you can use their API to figure the IDs of the users that should be admins. For Slack these IDs will look something like U123ABC1D.
I can see that hubot die is defined in the ping.coffee script. Maybe you can have a check there on authorized users when the command is run?
Something like this?
if msg.message.user.name in [authorized_user1, authorized_user2,..]
# Do more stuff
The same can be done for the other show storage script too. I am not really sure if this is the best way to go about it though as you will have to modify all the scripts that you do not want to be executed.
A cleaner approach would be to set the list of users as a env variable at startup(kind of like what hubot-auth does) and then check it inside each script instead of hard coding user names.
Hope that helps.
How to create data base link in oracle 11 g to Access Tables.
You seem to have copied the example in the documentation without really understanding it.
The USING 'local' part of the statement is creating a link to 'the local database', where local is the service name of a database. (The example is a bit confusing, to be fair).
When the link is used it tries to interpret local as a service name, appending the current database's domain, as the docs say:
USING 'connect string'
Specify the service name of a remote database. If you specify only the
database name, then Oracle Database implicitly appends the database
domain to the connect string to create a complete service name.
Therefore, if the database domain of the remote database is different
from that of the current database, then you must specify the complete
service name.
If you're trying to create a link back into the same database - which would be a bit odd but I've seen it done in place of grant access across schemas, and that seems to be what the example is hinting at - then you can replace 'local' in the USING clause with the service name of your current database (e.g. USING 'orcl', or whatever).
You can also use a TNS alias; if your tnsnames.ora has an entry for SOME_DB which points to the SID or service name of another database, you can have USING'some_db'`. You should be able to use any connect string I think; certainly Easy Connect is allowed. There's more in the net services admin guide.
I am trying to do some development to the LogisticsPostalAddress form that is used on forms where an address is modified/added. When trying to add an address (e.g. to an existing Customer) I get the error.
You are not authorized to access table ‘Shipping carrier’ (ShipCarrierAddress). Contact your system administrator.
I have scoured the user permissions and cannot find a way to give permission to this table. I would think that adding an address is a basic function, so can not figure out why I can't.
Thanks,
Kevin
What role is your user assign to? Are you sure users in that role should be able to add addresses to the customer? If yes, here is how you can add permissions to the ShipCarrierAddress table:
With admin user, open development envionrment (Ctrl + Shift + W from
running Ax, or run "ax32.exe -development" from command prompt)
In the AOT, go to Security > Roles. Find the role your user is assigned to.
Exapand the Role > Permissions > Table, add new table and set table name to ShipCarrierAddress and EffectiveAccess (in your case
you want to insert, thus set to Create)
Save the role, and compile the role (not sure if compile is mandatory)
Start a new Ax instance with the user with limited permissions and verify you have access.
I turned out it was an issue with the installation of the lab.