when using the following command :
cluscfg setcreds [/scheduler:] [/user:\]
where is the credential cached? On the machine where this command is run? or
on the scheduler machine?
Also, when does this cache expire? It stays as long as the account password has not expired?
I checked with one of the MS HPC techs and according to him
For this case, the credentials will be cached on the scheduler or head node and it won’t expire until the password expires on the AD.
This document has a very good explanation of what happens with the credentials. http://www.microsoft.com/en-us/download/details.aspx?id=6873 under Security Considerations for Jobs and Task (page 33)
Related
We are using LDAP accounts in our self-managed Gitlab. A GitLab account could be locked due to an excessive amount of unsuccessful sign in attempts. We have found that an excessive amount of unsuccessful https authentication attempts also makes the account locked.
It makes sense. But, what's troubling us is that it seems if a user doesn't sign in for several days, the account gets blocked too. Some of our Gitlab users don't sign in on the Gitlab page. They simply use git pull and git push with https. If the account gets blocked, the https authentication fails too. It annoys them if they have to sign in from time to time.
Is is possible to disable Gitlab from locking an account if the user does not sign in for days?
This might be related to the configuration of your LDAP server. Specifically the remember-me token config.
See also GitLab LDAP Auth docs.
If you have an idea for improving GitLab, you can always open an issue with your feature suggestion and use case.
With GitLab 14.7 (January 2022), you now have an UI-based alternative:
GitLab UI identifies to administrators that a user is locked
In previous versions of GitLab, administrators could not see in the UI that a user was locked.
Now, the GitLab UI identifies locked users to administrators, which helps confirm they are locked.
See Documentation and Issue.
When pushing a website update to Azure does the app pool reset? What effects does this have to a user that is signed into the site? Would the user get signed out?
When pushing a website update to Azure does the app pool reset?
Yes. You can check this in the Kudu Debug Console, under Process Explorer. Note how the PID of your application changes.
What effects does this have to a user that is signed into the site? Would the user get signed out?
Signing in with Azure AD (i'm assuming since you don't mention an IdP) is heavily dependant on your token cache strategy:
Assuming you're only using a memory cache for ADAL/MSAL and your app pool restarts —
In this case, the STS and ASP.NET cookie are still in the browser session, your code needs to check the cache and if it looks like a fresh cache, redirect user to STS (Challenge() in ASP.NET). This will be seamless and won't require typing in credentials since the STS cookie was never gone.
If the user session state is also stored in memory (the default for ASP.NET), then you'll lose the user's session state as well (if that holds a shopping cart, you have bigger problems to worry about).
The sensible thing to do is to move to a persistent token cache and a persistent user session store as well. Redis cache is a good choice. SQL is fine too, probably a bit much.
I am using Azure Mobile Apps with deployment slots, with the service provider for login being Microsoft. I have some odd behaviour, during swapping and the users relogin.
Is the performance better/different for AD? [read that it was not for GA yet?]
I am developing in a developer slot with everything specifically configured for this environment, the test and updates are working. I upload the server to staging, now utilizing the same db and settings (except microsoft authentication). The server is again verified to be working both on client and server.
I then use swap to change the staging and production slots. The production slot has the microsoft account login settings.
Upon swap the login by users are continuing indefinitely (no timeout, i.e. several minutes running without any stop) if, the referesh token call is made, as per this link:
//retrieve user info
user = new MobileServiceUser(credential.UserName);
credential.RetrievePassword();
//refresh token
user.MobileServiceAuthenticationToken = credential.Password;
JObject refreshJson = (JObject)await ((App)Application.Current).MobileService.InvokeApiAsync(
"/.auth/refresh",
System.Net.Http.HttpMethod.Get,
null);
My initial question is therefore is it possible to insert a timeout e.g. 2 seconds on the call to force the user to re-enter their credentials?
Because it seems to work if the user logs out and then back in with normal login procedure:
user = await ((App)Application.Current).MobileService.LoginAsync(provider);
credential = new PasswordCredential(provider.ToString(), user.UserId, user.MobileServiceAuthenticationToken);
vault.Add(credential);
string newToken = refreshJson["authenticationToken"].Value<string>();
Question(s)
Is it possible to insert timeout on MobileServiceClient.invokeApiAsync calls?
Is there some setting that can be set so the swap mechanism does not introduce this issue?
Is there a way to improve the login/relogin flow, the users are complaining that the login is failing often. I cannot replicate it in other instances than during the swap. Can this be because of distance to the server?
Therefore would Traffic Manager be a solution? However, I cannot see how it should be enabled if I am using microsoft login. Since a service is bound to an application name for authentication. How should the Traffic Manager be used in this respect?
Is there some setting that can be set so the swap mechanism does not introduce this issue?
Not sure if this applies to your case, but there is a known issue where certain app settings can actually cause issues with swapping. Do you have any app settings defined that end with _EXTENSION_VERSION or that start with WEBSITE_AUTH_? If so, try removing them and see if that resolves the issues you're seeing.
Is there a way to improve the login/relogin flow, the users are complaining that the login is failing often. I cannot replicate it in other instances than during the swap. Can this be because of distance to the server?
I've never head of an issue like this. Anymore details on the failure you can provide, such as a status code? One thing you can do is enable Application Logging and you should be able to get detailed information about the refresh failures.
Therefore would Traffic Manager be a solution? However, I cannot see how it should be enabled if I am using microsoft login. Since a service is bound to an application name for authentication. How should the Traffic Manager be used in this respect?
I think the way to make this work is to use a single Microsoft account application for all mobile app backends that are being load-balanced by traffic manager. The redirect URL that gets configured needs to use the common host name that is registered with Traffic Manager.
Is it possible to insert timeout on MobileServiceClient.invokeApiAsync calls?
From the API, It seems we can not set timeout in this method, refer to https://msdn.microsoft.com/en-us/library/azure/mt691682%28v=azure.10%29.aspx?f=255&MSPPError=-2147217396 for more details.
I am currently using Auth0 for the offline authentication with downloading the token and validating the user against it. I am now looking to migrate to the Azure Active Directory - just want to double check if they have anything to support my existing process.
How long do you remain offline? Access tokens in Azure AD have a validity time of one hour and are automatically cached. Technically you could relax the expiration check if you want them to last longer, although that's usually not recommended.
I'm trying to write a script which takes a username via argument and password via stdin. I'd like the script to contact the kerberos server and verify the password. I'm going to use this to authenticate perforce users via an auth-check trigger. I'm not too wedded to any particular language although bash and perl are already installed on the (centos 5) system concerned.
Any hints/suggestions would be much appreciated.
Thanks,
Fenster
This Perforce article has some useful links to get started.
http://kb.perforce.com/article/74
I think Kerberos saves a ticket on the machine you're authenticating on, so perhaps Perforce's SSO framework would be better. Check out this project:
http://www.assembla.com/spaces/sso-p4/wiki
Be aware that effectively verifying a password requires more than just doing kinit (an AS exchange). That is open to a KDC spoofing attack: the attacker hands you a password, then redirects your KDC request to his own KDC which says the password is OK.
The usual way to guard against this is for the verifier to have a service principal of its own; it kinits the user's principal, then uses the acquired TGT to obtain a service ticket for its own principal and verifies that ticket. This ensures that it is talking to the same KDC.
Just come across pwauth on google code. It can be configured to verify system passwords using the pam interface. It looks like its been designed with apache in mind but should work for any scriptable situation. Going to try and set this up this week. Will report back when i've tried it.
NB there are risks with exposing your system accounts so the link directs you to the risks page first.