I know that it is possible to enforce password reset after a period of time using password policy (maxPasswordAge) but, what if an admin needs to force a password reset for all users or for one specific user in case, for example, of a security threat? Is there a way to do that?
Thanks,
Easy, just restart the server with an altered age
passwordPolicy : {
validatorPattern : /^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.{8,})/,
doNotAllowUsername : true,
maxPasswordAge : 90,
maxPasswordHistory : 5,
resetTokenValidityDuration : 24 * 60 * 60
},
Related
For example: Suppose user "testuser#xyz.com" is login from one browser and performing some works. at the same time someone else login with same user "testuser#xyz.com" from another browser/machine in that scenario, i want to implement following ways
if the first logged-in user is not performing any action(inactive condition) from last 3-4 mins then first user will logged-out and second user will logged-in successfully.
If the first logged-in user is performing some task (active condition) then first user should get notification that, someone trying to logged-in from another browser/machine are you agree to allow ? if first user will allow then only second user will able to login(and first user should logout) otherwise not.
Any help is much appreciated.
This is not exact solution to your problem, but definitely it will give you the clue.
In your /grails-app/conf/spring/resources.groovy
//To enforce/restrict one session per user Starts
sessionRegistry(SessionRegistryImpl)
concurrentSessionFilter(ConcurrentSessionFilter, sessionRegistry)
registerSessionAuthenticationStrategy(RegisterSessionAuthenticationStrategy, ref('sessionRegistry')) {}
concurrentSessionControlAuthenticationStrategy(ConcurrentSessionControlAuthenticationStrategy, ref('sessionRegistry')) {
exceptionIfMaximumExceeded = true //False
maximumSessions = 1
}
sessionFixationProtectionStrategy(SessionFixationProtectionStrategy) {
migrateSessionAttributes = false//true
alwaysCreateSession = true//false
}
sessionAuthenticationStrategy(CompositeSessionAuthenticationStrategy, [concurrentSessionControlAuthenticationStrategy, sessionFixationProtectionStrategy, registerSessionAuthenticationStrategy])
//To enforce/restrict one session per user Ends
Source : searchcode.com
I tried this using jwt-auth, but the thing is token gets expired. I want to remember the user with token that never gets expired. Is their any possible way to do it in Laravel 5.2.
Should I send email and password for each request to api instead of saving session and token.
I will implement this way:
If the user selects Remember me, set the ttl to a longer time ,say 1 year OR month. To do this we need to publish
php artisan vendor:publish --provider="Tymon\JWTAuth\Providers\JWTAuthServiceProvider"
Then we can override the default ttl value which is 60 mins to our desired value.
$jwt = \Illuminate\Support\Facades\Config::get('jwt');
$jwt['ttl'] = 60*24*30; // 30 days
\Illuminate\Support\Facades\Config::set('jwt',$jwt);
Hope this helps!
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"
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 an application with 3 different logins (3 different dashboard). Not to write duplicate code I created an adapter and a plugin to login.
Now how can I manage 3 different sessions. If I run in to login Login 1 must also be signed on dashboard 2 dashboard 3, but only on dashboard 1.
How can I handle this? multi session for multi login.
This has nothing to do with authentication (or login: know what the identity of the user is) but authorization (or access: has the user the right to access this page).
You should not manage authorization with different logins, different sessions and so on. Just use a single identity for a user and use authorization for access. Take an example with ACL or RBAC, both inside Zend\Permission.
With these permission systems, you can say: this user X is allowed to access dashboard 1 and 3. The user Y is allowed to access 1 and 2. The user Z is only allowed to visit dashboard 1.
You should use Zend\Permissions\Acl. Check section "Multiple Inheritance among Roles".
http://framework.zend.com/manual/2.0/en/modules/zend.permissions.acl.intro.html
use Zend\Permissions\Acl\Acl;
use Zend\Permissions\Acl\Role\GenericRole as Role;
use Zend\Permissions\Acl\Resource\GenericResource as Resource;
$acl = new Acl();
$acl->addRole(new Role('guest'))
->addRole(new Role('member'))
->addRole(new Role('admin'));
$parents = array('guest', 'member', 'admin');
$acl->addRole(new Role('someUser'), $parents);
$acl->addResource(new Resource('someResource'));
$acl->deny('guest', 'someResource');
$acl->allow('member', 'someResource');
echo $acl->isAllowed('someUser', 'someResource') ? 'allowed' : 'denied';
But in case you don't want to use ACL. then why don't you add into your login table a permission column an integer(1,2,3...up to 7 I think) on login add this integer to a session and on each dashboard you check for permission number if not allowed access then you redirect to login or home page.