Long story short the security people at my company does not want us to use the default 'admin' username in Apache DS. Is there a way to change it without breaking anything? Also how to create an additional admin account that is a clone of the default 'admin' user? I couldn't find any documentation for this.
You can use Apache Directory Studio to do this:
Copy (Ctrl-C) entry uid=admin
Paste (Ctrl-V) into ou=system renaming the user entry on the way
Select cn=Administrators,ou=groups,ou=system
Add a member reference to the new user entry
Check you can successfully bind using the new user
Related
I am trying to use ldap for a flask application .
The app.config['LDAP_PROVIDER_URL'] = 'ldaps://appauth.corp.domain.com:636'
(I have replaced the domain for the original name here)
In another script in need the following ldap details
conn.simple_bind_s(
'cn=%s,ou=Users,dc=corp,dc=domain,dc=com' % username,
password
)
How do I find the OU,or can i ignore OU and drop it from above. Please let me know if other parameters are correct. I don't know LDAP
The general idea is that you bind as an application account with search privileges to locate the user account, e.g. by his email address, displayName, etc., and then use that DN to rebind using the password he supplied.
I setup an ApacheDS with default password-policy enabled. For testing proposes I locked a simple User (objectClass=Person extended with some custom User-objectClass) by entering the wrong credentials a number of times. As I expected the user was locked (error msg: user was permanently locked).
The question now is: How to unlock the user again? Is there a better way then just deleting and adding again?
I tried the same with an extended user (objectClass=pwdPolicy) but no pwd* attributes were added when the user was locked.
More recently, I encountered the same problem at work. But, it seems that there is no answer on Internet. Finally,I found the answer by viewing this document:
Password Policy for LDAP Directories draft-behera-ldap-password-policy
At section 5.3.3: pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
locked account means that the password may no longer be used to
authenticate. A 000001010000Z value means that the account has been
locked permanently, and that only a password administrator can unlock
the account.
At section 5.2.12: pwdLockoutDuration
This attribute holds the number of seconds that the password cannot
be used to authenticate due to too many failed bind attempts. If
this attribute is not present, or if the value is 0 the password
cannot be used to authenticate until reset by a password
administrator.
Through above two section, we can assume that we should connect to ApacheDS server with administrator(by default: uid=admin,ou=system, password=secret ), and delete the user's userPassword attribute. By this way,the permanently locked user can be unlock.
I practiced this sulotion and it works well.
I suggest you should set value for pwdLockoutDuration attribute, in this case the user can not been permanently locked.
For more infomation:
ApacheDS password Policy
Use ApacheDS Studio and log in as admin, find the user, right-click and choose "Fetch->Fetch operational attributes". Now pwdAccountLockedTime is visible and you can delete it to unlocks the user
The answer by Mister's is perfect to unlock an account and if you want to set the pwdLockoutDuration for a single user (assuming the user has implemnted the objectClass pwdPolicy.
There is also a global config file found in:
ou=config
* ads-directoryServiceId=<default>
* ou=interceptors
* ads-interceptorId=authenticationInterceptor
* ou=passwordPolicies
Here we can set the default password policy:
As mine is just a test-server, I have completely disabled lockout via setting the ads-pwdlockout to FALSE. For more on configuring password policy read the official docs.
For reference, this is how you enable this on the server via java:
AuthenticationInterceptor authenticationInterceptor = new AuthenticationInterceptor();
PasswordPolicyConfiguration config = new PasswordPolicyConfiguration();
config.setPwdLockout(true);
authenticationInterceptor.setPwdPolicies(config);
Client methods can then be written, to enable/disable specific accounts, similar to:
public void disableUser(String dn) throws LdapException, UnsupportedEncodingException
{
Modification disablePassword = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE, "pwdAccountLockedTime","000001010000Z" );
connection.modify(dn,disablePassword);
}
public void enableUser(String dn) throws LdapException, UnsupportedEncodingException
{
Modification disablePassword = new DefaultModification(ModificationOperation.REMOVE_ATTRIBUTE, "pwdAccountLockedTime");
connection.modify(dn,disablePassword);
}
I am trying to find a solution which will allow me to change a user's password from our Central User Administration (CUA) system where the user's access and password is on the child system.
I tried to use BAPI_USER_CHANGE with destination call but it doest suit in my case.
(we locked change password function in child systems). This is my code with destination call
CALL FUNCTION 'BAPI_USER_CHANGE'
DESTINATION 'CLNT_500'
EXPORTING
username = p_bname
password = wa_password
passwordx = wa_passwordx
TABLES
return = it_return.
Any suggestions welcome.
We tried to do something similar a while ago, and we ended up doing it in two steps:
BAPI_USER_CHANGE sets an initial password for the user
SUSR_USER_CHANGE_PASSWORD_RFC sets a productive password. It needs the old password as a parameter, that's why we needed to call BAPI_USER_CHANGE first.
I have a database-project, created based on my existing database. It also added the scripts for creating users. One of those scripts is =>
CREATE USER [JOOS_NT\Indigo.Development] FOR LOGIN [JOOS_NT\Indigo.Dev.svc];
This script works fine on my database. But in my database-project this script is throwing an error when I build it. The error is:
"SQL70527: 'JOOS_NT\Indigo.Development' is not a valid name because it contains characters that are not valid."
It seems the "\" in the [JOOS_NT\Indigo.Development] is not allowed. However on the database itself I can run the query and it works fine. If I change it to [JOOS_NT/Indigo.Development] I don't get the error, but when comparing the scripts in the project to the existing database, it would drop the user ([JOOS_NT\Indigo.Development]) and replace it with ([JOOS_NT/Indigo.Development])
What am I missing?
Answering for someone who will look in the future.
On the database project, if a '\' character is included in the user name, the login should match the user name.
Because that, this don't work:
CREATE USER [JOOS_NT\Indigo.Development] FOR LOGIN [JOOS_NT\Indigo.Dev.svc];
But this will:
CREATE USER [JOOS_NT\Indigo.Development] FOR LOGIN [JOOS_NT\Indigo.Development];
Or
CREATE USER [JOOS_NT\Indigo.Dev.svc] FOR LOGIN [JOOS_NT\Indigo.Dev.svc];
I'm not sure if this is the expected behavior or a bug.
This is by design. The core issue is that in the "CREATE USER FOR LOGIN" based on a windows user login, if you are using a domain name for the user then this must match the login's domain name + login name. See this post on MSDN
given Apache Shiro's permission format domain:action:instance how would I define that a user may only change it's own account-data?
I could do the following but this leads to an enormous explosion of permissions:
useraccountdata:write:user1 permit to user1
...
useraccountdata:write:userN permit to userN
What I need instead is something of permission-rules to configure this dynamically.
Something like: useraccountdata:write:user{n} permit to user{n} automatically for all n
Is this supported somehow or am I completely on the wrong path here? If not, how would you do it?
If you create your own version of Authorizer, you could just dynamically add the permission for that user with one of the isPermitted methods.