I am developing a WCF service which can be consumed by mobile applications to authenticate users against the corporate extranet ActiveDirectory. I am using a customized version of this implementation from Microsoft. I need to implement the account lock out logic so that after n retries the account in the ActiveDirectory should get locked-out.
I tried with state-full WCF service to keep track of the failed log-ins. But the client can start over the next session and continue with the attack.
I know that the ActiveDirectory policy can be set to enforce this, but just querying the AD -like the Microsoft solution does to authenticate the user - does not lock out the user.
So, I am looking forward for a solution which will work like when log-in to Windows with incorrect password for n times the account will get locked-out as per the policy set in the AD.
I have not seen your code. So I'm guessing you have similar solution that is implemented in this example, have a look at this link
In above example, please have look at line
DirectoryEntry entry = new DirectoryEntry(_path, domainAndUsername, pwd);
this entry object would be used for authentication when you make a search call on active directory.
If you are using user/password that you want to authenticate then you need not to worry about locking it by your code. Active directory policy would be enough.
But after reading your comment I guess you have one specific user that you use to search mobile application users to check if they exist in your active directory or not. If this is the case effectively you are never authenticating against mobile users so those users never going to be blocked automatically.
I would be interested to know your answer.
There are basically two ways of doing this:
You continue the directory search method you are using, but track the number of logins for each user in a custom database, and check this database before doing the directory search.
Use the Windows login instead, and rely on AD to lockout the user. For a description of how to do this check: Active Directory (LDAP) - Check account locked out / Password expired
Edit
After seeing marc_s's comment, I am unsure if doing the directory search will lockout or not. It would actually be a serious security hole if you could try an infinate number of times. But you would need an account that is allowed to query AD before you could use it.
The code you linked to had this line
object obj = entry.NativeObject
Which was to force authentication. Have you included this line?
Related
The bounty expires in 4 days. Answers to this question are eligible for a +200 reputation bounty.
Pete is looking for an answer from a reputable source.
I am aware the user impersonation question has already been asked several times.
Unfortunately, none of the questions I read so far provided a reproducible guideline or overall concept how to do this in a secure way. Since every action needs to be logged, I can't use a hack to do this.
For that reason, I would like to kindly ask the community once again for advice and sanity check of my own ideas. Also, new approach suggestions are warmly welcome.
The questions I read so far include:
IdentityServer4 - How to Implement Impersonation
Allow supporter to sign in as another user
Impersonate with IdentityServer, with having an actor claim for the impersonated user
Identityserver3 - User Impersonation
Introduction
Basically, I have an ASP.NET Core Razor Pages app and an ASP.NET Core Web API, both protected by Duende IdentityServer.
Support Engineers need to be able to impersonate customers for service reasons ONLY after the customer consented to impersonation.
Basic work flow:
in the Razor Pages app, the customer activates "Grant Impersonation Permission" under his/her personal settings
impersonation permissions are valid for a maximum of 7 days
customers can revoke impersonation permissions at any time
Support Engineers are then able to log in as any customer that granted impersonation permission at the back office (without the customer being present, no remote-desktop style)
Approach 1:
When the customer grants permission, use the Token Exchange mechanism to exchange for a new access token with a life time of 7 days.
Store this token in a database in IdentityServer and allow only Support Engineers to get a customer's access token via a Controller using the customer's ID, name etc.
While this would work, I'm not comfortable with the idea of storing long-lived access tokens.
Approach 2:
When a Support Engineer logs in, based on his identity, show a custom consent screen where customers can be selected for impersonation and then log in as the selected customer.
The Support Engineer would then get the access token as well as the ID token.
The biggest problem is:
Are there any extension points/mechanisms in IdentityServer to be hooked-in to control the sign-in process to kind of turn the sign-in process to log in the customer instead of the Support Engineer?
Is even possible to do this in IdentityServer?
Approach 3:
In Allow supporter to sign in as another user, user mackie pointed out a high-level view of a impersonation feature.
Here are the steps:
Navigate to client application Sign in using whatever credentials
Check if any impersonation permissions exist (how these are defined is entirely up to you)
Prompt for impersonation account selection (or just continue as self)
Sign in as the selected account (with record of original actor)
Redirect to authorize endpoint
Issue tokens and redirect back to client application
How are steps 4. to 6. done in practice? Any suggestions on that?
I have a question about the problem in your Approach 2. The essence of user impersonation is actually to use "pseudo-token" to impersonate a user to verify some operations or permissions. Or maybe you just want to log all actions performed by the impersonated user?
I think maybe you can intercept on login like in this link. But I think it may be better to add some specific identification to it when the interception is successful, instead of directly using the user's information to log in. I think logging in the customer instead of the Support Engineer might not be a user impersonation anymore (just a personal opinion).
In addition, acr_values is mentioned in the link you provided. From your description, acr_values seems to have some fit:
acr_values allows passing in additional authentication related
information - identityserver special cases the following proprietary
acr_values:
idp:name_of_idp bypasses the login/home realm screen and forwards the
user directly to the selected identity provider (if allowed per client
configuration)
tenant:name_of_tenant can be used to pass a tenant name to the login
UI
For the usage of acr_values, you can refer to this link.
Other link:Impersonation workflow.
This is just my understanding and a suggestion, if I have any understanding wrong, please correct it.
I wrote an app script which provides a web UI for data entry into a team calendar. I published it using G-Suite super admin account and added it as Trusted App under Security/API Permissions. "Trust domain owned apps" is checked under "Internal App Settings".
When a G-Suite user in our organization tries to access the app, he sees
"The developer of ShiftSchedulingApp, admin#_our_organization_.org, needs your permission to access your data on Google."
Those brave enough to click "Review Permissions" are taken to the next message:
"ShiftSchedulingApp wants to access your Google Account. See, edit, share, and permanently delete all the calendars you can access using Google Calendar"
Of course nobody wants to risk losing all the calendars on their Google Account and this is where it ends.
How do I get rid of this misleading message? It's not Google account, it's their organization account on G-Suite. It's not all their calendars, it's the shared team calendar only. It's adding data, not permanently deleting calendars. It's published by their administrator in their G-Suite, not an unknown 3rd party.
I spent days trying to make this message go away but no luck. App must be executed as an accessing user and not as publishing user because their user ID determines what shifts they can fill on a calendar.
I'd appreciate any hints pointing me the right direction.
I experimented with variations of the two-app approach as suggested.
The app which provides the UI needs to read the calendar to display available shifts - so I can't get away from the user authorization prompt.
Another variation I tried was having one app do everything and run as me, and another do nothing but return Session.getActiveUser(). I tried calling the 2nd one from the 1st one on the client side via XMLHttpRequest. It would be ideal for my needs - but I hit CORS error as apps URL is script.google.com but it actually gets redirected to script.googleusercontent.com. There doesn't seem to be a way to set CORS in Google App Script.
Although I was not able to find a way to avoid prompting users for authorization when executing the app as accessing user, it turns out my reasons for doing that were based on a false premise.
I chose to publish app as accessing user because I thought that's the only way to get accessing user Id - which is true for non-G Suite accounts.
However, when app is published by a G Suite account, the app can get accessing user ids within the same G Suite domain even when it's set to execute as publishing user.
Thanks Niek and TheMaster for your help!
If you just need user ID, why do you ask for all those permissions?
Possible Solutions:
2 web-apps- One running as you and another as user accessing (with only profile) permission. The second one will be the actual web interface and POST necessary information to the first one with privileges. OR
Implement your own web-app Google-sign in1
Use the least permissive2 scope3
I'm trying to create a website to authenticate users through the use of a throwaway password where the assumption is that the user might not use the website again (basically a one time access).
I have done my research on OTP and various solutions to authentication but these don't seem to fit my requirements, most of them seem to rely on users having login credentials to the website whereas my system would allow them access without the need for registering.
The implementation of passwordless authentication by Auth0 seems to fit what you're describing. Even if you were not considering a third-party provider it may be useful to go through the documentation.
Basically, a user can login to a site without any need for a sign-up process. They can do so just by requesting that a one time code is delivered to them, for example, either by email or SMS.
This way, they can get quick access without having to setup a user and in the event that they do come back your application can recognize this because they will most likely be using the same mechanism, that is, you can use the email or mobile phone as the unique identifier.
Disclosure: I'm an Auth0 engineer.
If you do not require your users to register, why do you need authentication at all?
Why not just set a cookie with an unique identifier on the first visit? You can store data at the server side associated with that identifier. Keep track of when you last saw the user, and if they do not return within a certain period, you can delete any data you stored for that user.
My application is using Form based authentication and JBoss 5 as application server. I want to add an account lockout mechanism to the applicaton. Does JBoss form based authentication support account lockout? If yes, how do I configure it. If no, what is the best solution without changing the existing functionality much?
I have searched quite a bit on the web, but could not find answer to this.
Any suggestions would be a great help.
Thanks,
jayash
I am not aware of an "out-of-the-box" solution, but there is always the possibility to write a custom login module.
So have a look at the source of the DatabaseServerLoginModule: You could extend it to support a lockout.
Add a flag in the database which indicates that the last verificatoin was not successful
Count and store the number of subsequent login failures in the database for a given user ID
Reset the counter and the flag, if there is a successful verification
But if the counter reaches a limit, the password verification always returns false, and the flag/counter are not reset.
So you can configure the front end to have account lockout: You just declare it to use form-based authentication. But you have to add some pages to maintain the accounts which are locked (you already have this or need this anyway).
OK, so I'm quite new to the whole world of claims aware applications. I was able to get up and running very quickly using Azure ACS but it's been a bit of a different story when trying to use ADFS 2.0 as the identity provider (I want to actually use it as a federated provider, but for the time being I'm just trying to get a sample running using it as an identity provider).
I've been looking at the guides here and have tried to follow the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide guide listed there. It takes you through setting up ADFS 2.0 along with a little claims aware sample application that you can use just to view the claims that are getting sent through.
So I can get that up and running, passing through the claims defined in the guide (just the windows account name). The problem is when I try to add any more. I can go to the relying party application in the ADFS GUI and add an Issuance Transform Rule, using the Pass Through or Filter Incoming Claim rule template. However, when I run my application, unless the added claim type is Name, it won't pass the claim through to my application.
One of the ones that I wanted passed through was the email address for the user who logged in to the application. So I added a rule to pass through the email address, then updated the web.config of the sample application to uncomment this line under the claimTypeRequired section:
<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="false" />
Note that I'm setting it as non-optional. I also updated the federation metadata of the application to add in the following:
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Optional="false" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706" />
I then went into the ADFS GUI, went to the Relying Party Trusts and selected Update from Federation Metadata on my sample application. So it now lists the email as one of the accepted claims.
I then went into the Claims Provider Trusts and added the email claim rule into the Acceptance Transform Rules for the Active Directory provider trust (the only one listed).
When I run the app however, it's not passing through the email claim (or any others that I try). Can somebody tell me what I'm missing here?
I should also note, I ran a test to change my application to only accept the email claim rule, and not only did it not pass through the email, but it's still passing through the Windows Account Name and the Name claims, despite the fact that I don't even list them as accepted claims for my application.
If anybody could point out where I'm going drastically wrong here, it would be seriously appreciated.
After enabling logging as per the blog post before, here are the relevant entries from the log:
Event ID 1000, "Input claims of calling principal included in details":
So you can see, the information that I'm requesting is quite clearly missing. I have the logging output set to verbose but there's really nothing of any other interest. You'll see trace records for the NETWORK SERVICE user (with the same set of claims), but nothing striking. All the log entries are informational, there aren't any errors.
If you using ADFS as Identity Provider and want it to issue an email claim, then you have to use Send LDAP Attributes as Claims or a Custom Claim Rule which access AD as the attribute store and issues an email claim. Pass through is used on the incoming claims, assuming the user is already authenticated somewhere. In case of Windows Authentication Windows account name is issued from the Kerberos token and that's why you have to pass it through, but others you have to issue.
Does Active Directory issue E-Mail Address claims? I'm not sure how to check this, but if it doesn't, it's irrelevant that you're passing them through. In this case, you'll want to try a "Send LDAP Attributes as Claims" rule; based on what I see in my ADFS instance, try mapping the "E-Mail-Addresses" attribute to an "E-Mail Address" claim.
I had to do something similar to get UPN claims to come over, in circumstances similar to yours. I'm not sure whether it will matter that the LDAP attribute is potentially plural.