I tired to lock user account using the admin console UI as described in http://isurad.blogspot.com/2014/09/how-to-lock-user-account-in-wso2.html. I made http://wso2.org/claims/identity/accountLocked = true. But still I can log in to the console using locked account.
Also tried to lock user account using the web service. Even this prints in the console,
{org.wso2.carbon.identity.mgt.services.UserIdentityManagementAdminService} - User account unconfirmed1 locked
Still I can log in to the console using locked account. What has gone wrong here?
The operation via the admin console is cached and is currently set to 15 mins. Hence the account lock should have worked but you need to wait 15 mins for this to come into effect. The web service calls should be immediate though.
Related
The features described in this doc https://docs.wso2.com/display/IS530/User+Account+Locking+and+Account+Disabling are around locking accounts after too many failed login attempts and disabling accounts after idle activity.
Let's say the user in question has the "admin" role (as usually configured in a tenant). Can they get their account locked/disabled? If so, how does one get out of this situation?
Yes, admin users can get locked out after exceeding the maximum number of login attempts as same as other users. The user will have to wait until the end of the configured account unlock time window to retry.
Account unlock timeout = Configured Account Unlock Time * (Lock Timeout Increment Factor ^ failed login attempt cycles)
An alternative approach available to unlock an account as explained in [1]. In this case, a different admin user can login and unlock the locked user account.
My service start an interactive client process with something really similar to this: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379608(v=vs.85).aspx
It works when the service Log On as Local System, and it work if it's running under an Administrator account with the SE_ASSIGNPRIMARYTOKEN_NAME and SE_INCREASE_QUOTA_NAME privileges.
My issue is when using a Standard User account OR Local Service, it fails at OpenWindowStation with error code 5 (ACCESS DENIED).
// Get a handle to the interactive window station.
hwinsta = OpenWindowStation(_T("winsta0"), // the interactive window station
FALSE, // handle is not inheritable
READ_CONTROL | WRITE_DAC); // rights to read/write the DACL
Is it possible to call OpenWindowStation from a Standard User account or my service must run under an Administrator account? I tried almost all Local Policies without success
Thanks!
Unfortunately it can't be done, it seems that only an Administrator can open the interactive station.
I wrote a Windows application that comes with two modules: service and user-mode applications. The service implements its own scheduler and may log-off a user at a predefined time. For that I was using the following call that is triggered from my user-mode module running in a logged-on user session that has to be logged off:
BOOL result = ExitWindowsEx(EWX_LOGOFF, reason);
This works fine, except of the situation when a user's account is locked. In that case that API doesn't seem to do anything at all even through I get 1 returned from it.
So I was curious, is there any other way to log off a user when their account is locked? (One condition I have in this case is that if that user had any unsaved documents then the log-off should not be forced.)
Try this:
DWORD dFlags = EWX_LOGOFF | EWX_FORCE | 0x10200;
BOOL result = ExitWindowsEx(dFlags, reason);
i created a windows service in c++ and when i try start the service i get the message error 5: access denied.
my user account is set to admin and i even tried using the default admin account on the computer and it still doesn't work.
i can install/uninstall the service through the cmd without problems but i can't start the service
the code isn't the problem here its the user account. any suggestions on how to fix this?
"Running a service" is not simply "starting a program on my desktop". It does not necessarily run as "you".
The service is detached from any desktops and it actually ignores your user account. The service will have its own account/password configuration stored in the OS and when you run it, you only order it to start up. It will startup on its own user account. If you have put your .exe/.dll files in some protected folder, and if you have not configured neither the accessrights to that files nor user-pass for the service, then there's great odds that the service tries to run at default service user account like 'LocalService' or 'NetworkService' and that it simply cannot touch the files.
If you installed the service properly, go to ControlPanel - AdministrativeTools - Services, find your service and check the (if I remember well) second tab and verify that the username presented here has access to the files that are tried to be loaded and run. If the username is wrong, correct it. If you don't care about the username, then just peek that name and set accessrights on the folder and/or files such that at least both "read directry contents" and "read" and "execute" are available for that-username-the-service-tries-to-run-as.
If I call the following API from a local service running on Windows 7:
WTS_SESSION_INFO* pWSI;
DWORD nCntWSI;
WTSEnumerateSessions(WTS_CURRENT_SERVER_HANDLE, NULL, 1, &pWSI, &nCntWSI);
and then go through all returned WTS_SESSION_INFO structs in pWSI and check WTS_CONNECTSTATE_CLASS State members, can someone explain what is the difference between WTSActive and WTSConnected?
Connected means the user has connected and has been (or soon will be) presented with a login screen but hasn't completed it and been verified yet. He might be typing his password, for example.
If the user has locked the workstation, it's been locked by a screensaver, or he has switched to another user account, it doesn't end his session. The user remains logged in and his session would remain marked active. So being connected but not active means there are no processes running under that user's account. (The one caveat being there could be a service or other process running in a separate session under that user's credentials, but that's a different matter.)