I was wondering if it was possible to still allow web applications to authenticate (ASP.Net authentication with windows forms pointing to AD) while disabling the account from logging into the physical on campus terminal computers.
Thank you.
-Devin
I'd suggest futzing with the userWorkstations attribute. Set their account to some non-existant or benign workstation. I haven't tested this myself, so you might find you need to specify some IIS servers (or else the account will be locked out of that as well).
Hope this helps.
http://blogs.technet.com/b/heyscriptingguy/archive/2006/02/17/how-can-i-specify-the-computers-a-user-can-use-to-log-on-to-the-domain.aspx
Related
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
Written an app that grabs info of a specific computer using WMI remotely. Currently, I have to auth on each computer using one of the machine's local accounts. What I would like and what I'm trying to do is to be able to auth using a domain account (one of the accounts on the AD domain controller machine).
Right now, I can auth to domain machines only with local accounts with the exception of the domain controller. I can log on the AD DC using domain accounts by using NTLM protocol. The piece that isn't working is thus logging on to domain machines other than the DC using domain accounts.
Is this a code-issue or is it an AD setting issue, like I need to instruct the domain machines to always check with the DC when a user auths or something?
I'm using System.Managemnt.ManagementScope class in C# to handle all this curerently. Any help would be much appreciated.
I'm quite the newbie when it comes to AD and domains.
EDIT: Solved it.
The Active Directory account in use needs to be given the permission called "Trusted for Delegation" in order to work on computers other than Domain Controllers. This right is extremely powerful, effectively allowing your account to present itself as any other account on the domain.
The alternative is to pass explicit permissions to the process. Bear in mind, though, that when connecting to another computer via WMI, the process created on the remote computer will not be able to authenticate to other computers on the domain; this is considered 3rd party delegation. There is a workaround to this limitation created by Frank White (on SO).
I am writing a Silverlight client and a WCF Service library solution in an Intranet environment.
As I understand it, if I set up Windows Authentication then calls to the service methods will only succeed if the caller is Authenticated in Windows and I do not need to write code to provide user credentials. I have several questions around this.
Am I correct?
I have been asked to make my application time out (as is often done with Internet applications) making the user log in again. However, I have enabled 'Integrated Windows Authentication' in advanced IE options and 'Automatic logon only in Intranet Zone' in the Security section. Effectively, now the user does not login to my application but to IE and Silverlight passes these credentials automatically to the WCF Service. I can change to 'Prompt for username and password' but then the credentials are only lost when IE is closed which I cannot do on a timeout. Even if I could I would have to close all IE opened Windows that were participating in the Intranet zone as the authentication seems to be shared amongst them.
Is it possible to impersonate another user? I have seen code to do this from a Windows application but the intellisense when using Silverlight does not seem provide the same functionality?
As far as I know you use IIS Windows Authentification. WCF services can be confugured independently and they have security based on Windows identity too, but they are a bit more difficult than traditional approach.
Your questions:
1.To disable anonymous users and allow only those users who are authentificated in Windows, you can write the following code:
<authorization>
<deny users="?"/>
</authorization>
After that user credentials will be required and passed automatically. And you don't need to send them from client's application.
If anonymous authentification is disabled by IIS, everything will work without extra code.
2.It's OK, IE and Chrome, unlike Firefox, don't require credentials every time when a user opens a web page. If you want to refresh a state of the application after timeout, you can do it without requesting credentials, for example using something of the sort of MessageBox.
3.Impersonation works only on a server side. But it's possibly to write necessary code in a WCF service and call it from a Silverlight client.
How can I make my desktop application into an OpenID relying party?
Have a look at this question, it looks to me that OAuth can do this for you.
Since OpenID has a specified protocol, it will either work all the time (assuming providers are conforming) or not at all. Additionally, since the OpenID protocol (at least the authentication bits, see the specification) consists of simple HTTP requests, you could implement the protocol in a desktop application assuming you know how to make such requests.
It is generally considered a bad idea though, since there are better technologies (OAuth) and it disrupts the user experience (being different from OpenID in a browser — see OpenID For Desktop Applications: How? When?).
Further reading: OpenID for Desktop Clients
Don't do it.
Even an attempt to do so shows a fundamental lack of understanding in the security model that OpenID offers. You have to ask yourself what the password that you would otherwise use for your desktop app is protecting. Is it protecting assets on the local machine itself? If so, OpenID is useless because it would be a simple matter to spoof the network such that I could hack my way into the desktop app without owning the OpenID. You're wide open to user identify spoofing. Are you trying to protect network assets? OpenID fails again, since it doesn't authorize your desktop app to access those network assets, suggesting that some other authentication is going on behind OpenID so once again you're not adding any value.
OAuth is the protocol suited to allow your desktop app to access and protect network resources. If you're protecting local assets on the desktop computer, local encryption is the only way to go.
It seems to me that you should present a small web browser window for the authentication to be completed. The interaction would not be going through your code.
I would not suggest using web scrapers to do this. In doing so, you place your code in between the user's server and the user, which is a breach of the covenant that the user's password is not seen by the relying party.
OAuth is the right technology to use for a desktop application, but it doesn't use the existing password ecosystem that OpenID has, which was not a part of the OP's question.
We are planning to create two sharepoint web applications using SharePoint 2010 Enterprise Edition.
All Users that have access to web app 1, should also be able to access web app 2.
This authentication shall be powered by server 2003 active directory.
--> do I need to use claims based authentication?
If so --> can I use Windows Based Authentication with NTLM for that?
The only thing I really want is that users navigating from web app 1 to web app 2 (and vice versa) do not have to authenticate twice.
I do NOT want to configure Kerberos if it is not absolutely necessare though...
Can you give me any hints?
Thanks!
EDIT:
ok - I'll try to be more precise:
In our SharePoint 2010 environment, we've got two web applications running
http(s)://humanresources.domain.com
http(s)://sales.domain.com
Both are running on the same IIS and have host headers configured (with wildcard domain certificate for HTTPS).
Both apps provide a link to the other web application (sales -> humanresources and humanresources -> sales)
Now whenever someone logged in to sales navigates to humaresources, I do not want that that person needs to login again. Therefore I thought I would need claims based authentication???...
Please enlight my brain! :D
EDIT 2:
Thank you for your answers!
#Panagiotis Kanavos - yes we have Users accessing the site from outside our environment: 1) Users which have an AD accound and are working on their laptops outside of our building (e.g.: they have been all day at a customer and are working at home for the remaining hours) 2) We plan to have users without an AD Accound --> Forms Based Authentication: (e.g.: customers accessing our TFS 2010 project protals to get an overview of the project). As far as I know, if you want FBA and WIN-Auth you need to configure Claims Based Authentication...
However configuring a Web Application with Claims Based Authentication did not work. I chose "Enable Windows Authentication" together with "Integrated Windows authentication -> NTLM" as we do not have Kerberos configured (and I'd love to leave it like that ;-)).
However the Users could not login to that application sometimes, and five minutes afterwards it worked. Additionally, when I added permissions to an AD user, SharePoint seemed to save the Token instead of the Group-/Account Id:
e.g.: Instead of MyDomain\user1 it saved something like "0|=MyDomain\user1" and for groups it even only saved weird character strings "022-12.3"
Could it be the case, that my 2003 windows AD does not support that?
IF you are using Active Directory and running both sites within your domain you should not be challenged when users go to either site. It just becomes an implementation issue about who has access to what, either via AD Groups or SharePoint groups.
Claims based authentication is a bit of a different animal. You need to have a security token which contains a number of "claims" about the user, for example UserA is a member of HR and UserB is a member of Sales. Based on these claims you can then have your site/application respond correspondingly. Claims based auth is relatively new for SharePoint and Microsoft and is a bit of steeper learning curve. It may make more sense if you have a mixed mode environment, with both AD and Forms Based Users getting access. However with your described heterogeneous environment it doesn't seem like it's needed.
More info on SharePoint 2010 Authentication is available here.
John
The easiest solution is to create an AD group with the users of both sites and add the group as a user to the Members Sharepoint group of each site. This way users will not have to login at all since Sharepoint will detect the identity of the logged-in user automatically.
Why are you asking about login, claims, and why are you using certificates? None of this is necessary in an intranet scenario where the farm and users are in the same domain or if the farm's domain trusts the user's domain. Do you have users accessing the site from outside your domain?