I am using OpenLDAP provided in osixia/openldap docker image (https://github.com/osixia/docker-openldap) but it is storing all passwords hashed.
Normally it will be desirable but I am planning to hash passwords on front end (with salting and MD5) so no person in the organization never gets to see the users passwords, but when I try saving them they are hash again, I have not find a way to prevent this behavior.
I try deleting (using user cn=admin,cn=config) an entry that comes with the image called cn={4}ppolicy,cn=schema,cn=config which I think may be the culprit but ldapdelete returns Server is unwilling to perform (53).
Any help is deeply appreciated.
If you store the password in plain text you can retrieve them in plain text.
You just need to check in the ACL that the user you use to read them have the correct rights to do it.
The password policy entry you are talking about is just a schema definition which allows you to define a password policy but does not enforce anything. (The 53 error is because you can't remove a schema from a running OpenLDAP to prevent removing a schema which could be used by an entry)
According to what I can see in github about the docker image you use, the ACL used is :
olcAccess: to attrs=userPassword,shadowLastChange
by self write
by dn="cn=admin,{{ LDAP_BASE_DN }}" write
by anonymous auth
by * none
Which means that only the user himself or the admin account can read the password field userPassword
It is this ACL that you need to modify to suit your needs. The ACL should be located here :
dn: olcDatabase={1}{{ LDAP_BACKEND }},cn=config
Related
I have a proxy application that would create for every user365 the onlinemeeting,
So I have read this:
documentation update in march
and it seems that for each user in azure, I have to run a powershell command to allow my application to generate a meeting.
in the example there is this policy with 3 parameter (in the doc explain two parameter) so I'm so confuse:
New-CsApplicationAccessPolicy -Identity Test-policy -AppIds "ddb80e06-92f3-4978-bc22-a0eee85e6a9e", "ccb80e06-92f3-4978-bc22-a0eee85e6a9e", "bbb80e06-92f3-4978-bc22-a0eee85e6a9e" -Description "description here"
It seems that a policy needs to be created first....
And then the policy has to be associated with each user... one at a time....
Isn't there something global for all users?
Let me explain better: once the application type permissions are activated on
OnlineMeetings.Read.All OnlineMeetings.ReadWrite.All
why do I need to do anything else?
In other API (like create calendar event for example here) the policy rule is not necessary... but is necessary only the permission API
I have solve:
There are a -Global parameter that When you use this cmdlet without specifying a user identity, the policy applies to all users in your tenant, except any that have an explicit policy assignment. To skip a warning when you do this operation, specify this parameter.
Grant-CsApplicationAccessPolicy -PolicyName "ASimplePolicy" -Global
Or more specifically:
Given I am signed in as the 'admin' user, and I want to to impersonate a user 'testSiteUser'
Given the 'testSiteUser' node (rep:User) does not have a protected String[] property called rep:impersonators set with a value containing admin
How do to update the protected property rep:impersonators such that it contains admin?
Once the user node has this set, I'm confident that setting a cookie sling.sudo should allow user impersonation.
What I have tried so far..
curl -F:name=testSiteUser -Fpwd=testSiteUser
-FpwdConfirm=exampleSiteUser
-F'rep:impersonators'=admin
-F'rep:impersonators'#TypeHint='String[]'
-u admin:admin
http://localhost:8080/system/userManager/user.create.html
Which responds with 500
javax.jcr.nodetype.ConstraintViolationException: Attempt to set an
protected property rep:impersonators
According to the JCR Spec
16.3.12 Interaction with Protected Properties
Many features of JCR expose repository metadata as protected properties defined by mixin node types. For example, locking status is exposed by the properties jcr:lockOwner and jcr:lockIsDeep defined by mix:lockable. Changes to protected properties can only be made indirectly through a feature-specific API (for example, Node.lock), not through a generic write method like Node.setProperty. Such changes are not governed by the jcr:modifyProperties privilege, but rather by the particular feature-specific privilege, for example, jcr:lockManagement (see ยง16.2.3 Standard Privileges).
Perhaps the only way is to write my own Java code as shown below, but I'm pretty sure there should be a REST API to do this...
Authorizable authorizable = userManager.getAuthorizable(user.getId());
Principal admin = userManager.getAuthorizable("admin").getPrincipal();
jackrabbitUser = (User) authorizable;
Impersonation impersonation =jackrabbitUser.getImpersonation();
impersonation.grantImpersonation(admin);
Basically rep:impersonators is a read only property that is managed "indirectly through a feature-specific API" What is the API and procedure to do user impersonations using Apache Sling or Jackrabbit Oak?
I understood your question, that you want to add an impersonator via a REST-call.
As you already found, all security related properties are protected. So they can only be manipulated via API-calls - and not directly written to.
But AEM already has a lot specialized REST-API's for its own user interface. To find them you should first perform the desired action on the normal AEM UI. Then check with the browser network inspector, which http-request was made by the browser.
In your case go to the classic user manager (http://localhost:4502/useradmin).
There you find the curl:
curl 'http://localhost:4502/home/users/J/JfiFIrTqxwUamu2BvWj-' \
-u admin:admin \
-F_charset_=utf-8 \
-FmemberAction=sudoers \
-FmemberEntry=alex
In the example I added for user alex2 the impersonator alex. So alex can impersonate to alex2.
For the user alex you need the repository-path, which is encrypted meanwhile for security reasons. But this path is easy to find with the querybuilder. As example the following query:
http://localhost:4502/bin/querybuilder.json?path=%2fhome%2fusers&property=rep%3aauthorizableId&property.value=alex2&type=rep%3aUser
or via the querybuilder UI http://localhost:4502/libs/cq/search/content/querydebug.html
path=/home/users
type=rep:User
property=rep:authorizableId
property.value=alex2
I am working on integrating a new Jenkins instance with AD. I have installed the required plugins. When I try to add a domain, it asks for info such as domain name, domain controller, etc.
I am not fully clear on the BindDN field. If I leave it blank and test the domain, it throws this warning
Leaving blank Bind DN means that any operation performed will use anonymous binding. Keep in mind that this is not recommended as some servers do not allow it by default.
I then provided a user account in BindDN which exists in the domain. Now on testing the domain, it is throwing this error log:
DC_Name:389
java.net.UnknownHostException: DC_Name
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
Pls share some inputs to complete the integration with AD.
There is information provided in the Jenkins wiki page for the AD plugin, as well as some ldap tools to help diagnose.
<DOMAIN_NAME> -> Domain Name: support-cloudbees.com
<searchbase> -> Organization Unit we want to look into.
In the example, it is OU=Support, DC=support-cloudbees, DC=com
<binddn> -> Bind DN.
In the example, CN=felix, OU=Support, DC=support-cloudbees, DC=com
<passwd> -> Bind Password
<userid> -> User we want to look for. We can look for the managerDN itself or for a different user on the tree.
In the example, this can be set-up for example to CN=felix, OU=Support, DC=support-cloudbees, DC=com.
As described here,
The Bind DN is comprised of the user and the location of the user in
the LDAP directory tree. Each element of the Distinguished Name is
pointed out: The first part is the user CN=user1. The second part is
the container CN=Users. The third part is the domain DC=example and
DC=com
Did you correctly specify "the location of the user in the LDAP tree" ? The error appears to be with a DC value.
Ours is in the form:
cn=<Acct Name>, ou=<some_value>, ou=<some_value>, dc=<some_value>, dc=<some_value>
YMMV. Try use the ldap tools mentioned to validate.
We ran the Fortify scan and had some Access Control: Database issues. The code is getting the textbox value and setting it to a string variable. In this case, it's passing the value from the TextBox to the stored procedure in a database. Any ideas on how I can get around this Access Control: Database issue?
Without proper access control, the method ExecuteNonQuery() in DataBase.cs
can execute a SQL statement on line 320 that contains an attacker-controlled primary
key, thereby allowing the attacker to access unauthorized records.
Source: Tool.ascx.cs:591 System.Web.UI.WebControls.TextBox.get_Text()
rptItem.FindControl("lblClmInvalidEntry").Visible = false;
ToolDataAccess.UpdateToolData(strSDN, strSSNum, strRANC, strAdvRecDate, strAdvSubDate, strClmRecDate, strClmAuth, strClmSubDate, strAdvAuth, txtNoteEntry.Text);
Sink: DataBase.cs:278
System.Data.SqlClient.SqlParameterCollection.Add()
// Add parameters
foreach (SqlParameter parameter in parameters)
cmd.Parameters.Add(parameter);
The point of "Access Control: Database" is where it isn't being specific enough in the query and so could potentially allow a user to see information that they're not supposed to.
An easy example of this vulnerability would be a payroll database where there is a textbox that says the ID of the employee and gives their salary, this could potentially allow the user to change the ID and see the salary of other employees.
Another example where this is often intended functionality is in a website URL where the product ID is used in a parameter, meaning a user could go through every product you have on your site. But as this only allows users to see information they're supposed to be able to, it's not particularly a security issue.
For instance:
"SELECT account_balance FROM accounts WHERE account_number = " + $input_from_attacker + ";"
// even if we safely build the query above, preventing change to the query structure,
// the attacker can still send someone else's account number, and read Grandma's balance!
As this is pretty context based, it's difficult to determine statically so there are lots of examples where Fortify may catch this but it's actually intended functionality. That's not to say the tool is broken, it's just one of the limitations of static analysis and depending on what your program is supposed to be doing it may or may not be intended.
If this is intended to work like this, then I would suggest auditing it as not an issue or suppressing the issue.
If you can see that this is definitely an issue and users can see information that they shouldn't be able to, then the stored procedure needs to be more specific so that users can only see information they should be able to. However SCA will likely still pick this up in a latter scan so you would still then need to audit it as fixed and no longer an issue.
To restore a database using the procedure SP_RESTOREDATABASE or AdsBackup utility, you need to provide the ADSSYS password as a parameter. We have secured our database using encryption and access is resctrited to specific users. But anyone using Data Architect can retrieve the ADSSYS password while the restore is taking place in the ACTIVE QUERIES tab under the Remote Server Info/Advantage Management Utility. The password appears as clear text. If query logging was enabled, I suppose it would be available in the log as well.
Is there a way to prevent a query from being shown in the log or the active queries window?
You should use a parameterized query. In that case, the parameter values will not be visible:
execute procedure sp_restoredatabase( :backuploc, :password, :restoreloc, null );
Then supply the values for the parameters backuploc, password, and restoreloc.
Note too that v11.0 restricts the visibility of that information in general. It requires a DB:Admin connection to a dictionary in order to view any statements executed on that dictionary.