In Gforge, when a new user tries to log in; the user is automatically registered by fetching data from LDAP. It works fine for other users but one particular user is not able to log in and gets the error LDAP Authentication failed: Invalid Credentials . I don't understand what could be the issue? Could you please help?
This is the search function I am using.
ldap_bind($ldap, $dn, $pw)
$dn = ldap_get_dn($ldap, $entry);
$entry = ldap_first_entry($ldap,$res);
$res=ldap_search($ldap, $sys_ldap_base,$sys_ldap_id_attribute . '=' . $id,
array());
If it works for some users but not for one specific user, then it's something to do with the LDAP configuration, or with the characters in that user's ID or pwd.
Is the failing user in a different org/OU? Do they have accent characters in their username or password? These things can cause compatibility issues between GForge and the LDAP server.
Does this user have a much longer user name than other users? There is a GForge config setting called "usernameregex" that governs the complexity and length of allowed user names. Even though LDAP logins result in automatic account creation, the validation of the user's unix name might fail due to the regex in place. The error noted above could certainly be the catch-all message when this happens.
The default setting is "^[a-z0-9_.-]{3,15}$". You can change the upper length limit by changing the 15 to something else. The unix_name field in the GForge database is TEXT, so it can be extremely long (1GB?).
In GForge 6.3.x and earlier, you can find that setting in /etc/gforge/gforge.conf. Change the value and then update the system using:
cd /opt/gforge/bin && php create_config_cache.php
In GForge 6.4 and later, you can use the gf-config utility to set the value. It will take effect right away:
/opt/gforge/bin/gf-config set "usernameregex" "new regex value"
Related
When attempting an ldapmodify to set the unicode password (with the correct encoding) over SSL(636), the operation fails and Active Directory returns the following error code:
0000052D: SvcErr: DSID-031A1248, problem 5003 (WILL_NOT_PERFORM), data
0
I found countless threads and answers on resolving WILL_NOT_PERFORM but I am hoping someone knows the meaning of the exact codes above.
Every other solution points to password complexity, min pw age before the modify, SSL requirement, encoding requirement, and some others.
We have set the min pw age to 0, ensured we met the pw complexity requirements, encoded in UTF16LE=>base64, submitted the operation over SSL with 256 bit encryption and trusted/verified certificates, and we still receive this message.
The ldapadds/modifies are being performed by an automated tool which has successfully worked on other AD 2008 R2 instances so we know the password reqs, encodings, and SSL requirements are satisfied by the tool. We also tested with manual ldapmodify via LDIF and receive the same message.
Can anyone shed some light on any other possible permission, bug, UAC related setting, or way to decrypt the exact error code above?
Any help would be greatly appreciated! :)
I could only guess about your environment setup, but try to perform these steps:
Check if this password really could be setup through AD interface on server
Ensure you wrap you password with double quotes before encoding (i.e. it should be "password", not password
Check if you use unicodePwd attribute to set the password
So my ldapmodify entry to set password to StrongPassword! looks like:
dn: CN=User,CN=Users,DC=corp,DC=example,DC=org
changetype: modify
replace: unicodePwd
unicodePwd:: IgBTAHQAcgBvAG4AZwBQAGEAcwBzAHcAbwByAGQAIQAiAA==
Note unicodePwd has two colons
I wanted to give Bareos (Open Source Data Protection) a go to see how it works and performs. However I cannot even get past the basic installation and get it working...
I followed the following installation tutorial (several times now): https://www.svennd.be/installing-bareos-on-centos-7/
But I am getting every time the following error: Sorry, can not authenticate. Wrong username and/or password.
I don't understand what I am doing wrong. I even tried using the previous version of Bareos 16.2, but that didn't make a difference and I experience the same issue. I am 200% sure the password and username are correct.
I also consulted the logs:
17-Mar 13:00 bareos-dir JobId 0: Fatal error: Authorization key rejected by Console USERNAME.
Please see http://doc.bareos.org/master/html/bareos-manual-main-reference.html#AuthorizationErrors for help.
17-Mar 13:00 bareos-dir: ERROR in authenticate.c:283 Unable to authenticate console "USERNAME" at client:127.0.0.1:9101
I checked that page (also several times) and even made sure the (user)names/passwords were correct. But still I get the message "Sorry, can not authenticate. Wrong username and/or password." when I try to login on "bareos-webui".
Probably I am doing something wrong, but I cannot disover what.
I have the following files available. Maybe I need to make certain changes to those as well?
/etc/bareos/bareos-dir.d/director/bareos-dir.conf
/etc/bareos/bareos-fd.d/director/bareos-dir.conf
/etc/bareos/bareos-sd.d/director/bareos-dir.conf
/etc/bareos/bconsole.conf
/etc/bareos/bareos-sd.d/storage/bareos-sd.conf
/etc/bareos/bareos-dir.d/client/bareos-fd.conf
/etc/bareos/bareos-dir.d/job/backup-bareos-fd.conf
When I compared some files, they have different passwords in them?
For example: /etc/bareos/bareos-fd.d/director/bareos-dir.conf
Director {
Name = bareos-dir
Password = "J36zN1mQVF5lLA/FP0kASo+X9wTo8D988nsVqZjx"
Description = "Allow the configured Director to access this file daemon."
}
And /etc/bareos/bareos-sd.d/director/bareos-dir.conf
Director {
Name = bareos-dir
Password = "PAU/ov3RvnFp0I59brd4d8u9m8ejRpkVE7P/4Qz3"
Description = "Director, who is permitted to contact this storage daemon."
}
And (one more example): /etc/bareos/bconsole.conf
# Bareos User Agent (or Console) Configuration File
Director {
Name = bareos-dir
address = localhost
Password = "Fs5JnyO1ypBhcR0D9CNkx3gynPMa+jmp7sj9Ghst"
Description = "Bareos Console credentials for local Director"
}
They all have different passwords here? As I understand it, from the online docs, they should all be the same, right?
Maybe that's the issue? Hopefully someone can explain things a bit better or advice me what to do in order to get this working... Maybe it's something simple that I may overlooked?
FYI: I whitelisted all IP's and ports I use on this server.
//small edit
I re-read the documents once again and it says: "The default configuration files are automatically defined for correct authorization with random passwords. If you add to or modify these files, you will need to take care to keep them consistent."
So if I didn't change a thing, it should have worked in the first place, right? So I think something else is wrong here?
Well I finally found the issue...
Apparently my username or password was to difficult for Bareos to accept.
Don't know exactly which one it was, but either username or password caused issues.
I used as a username something like:
BCKPserver
And the password I used was similar to:
!!!!RNDpassW222####
For some reason Bareos saved the password (in the console) and was displayed correctly in the configuration files, HOWEVER it didn't allow me to login on the bareos-webui!
Solved. Hopefully this will help someone else.
I am currently working on a project that uses OpenAM 12.0.2 with OpenDJ 2.6
We had a requirement to make the username editable. So, we ended up creating a custom ldap attribute called loginId and updating OpenAM config to use this attribute instead of uid.
When I import less than 4000 users, login works fine. When I import 4000+ users login doesn't work for any user, even 1 of the first 4000 users in the directory.
I can manually ldapsearch for the users and they exist in the directory, but I can't login with any of them.
We get an "Authorization failed!!" error, which is different to the usual username/password doesn't match error.
If anyone could shed any light on this, I would appreciate it.
Thanks
Edit
Here is the attribute definition I am now using.
attributeTypes: ( 1.3.6.1.4.1.37238.2.9 NAME 'loginId' DESC 'username (that can be updated)' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'project schema')
I have rebuilt the indices and still having the same problem :(
That is probably because your instance of OpenDJ is configured to reject unindexed search request and you haven't defined and built an index for the loginID attribute.
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 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