First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.
Related
I have somewhat of an odd question (for me, at least).
We have some private information a department would like to place on our SharePoint farm. The problem is, this is very sensitive information, and law demands that we have a 'two-stage' login process to secure the data.
Currently, it is housed using a system that:
A) you have to login to our network (windows logon screen)
B) you have to login to the application.
Our SharePoint farm has integrated authentication enabled. Meaning, once you login to your computer in the morning, you never have to login to sharepoint as it already knows your credentials.
This is a problem for us. Can we enable some sort of custom Sharepoint login?
Will this require a new web app for the site? A new site collection only perhaps?
Thanks,
~~Kolten
What you are looking for is called forms based authentication. Sharepoint 2010 uses claims based authentication and one of the providers you can configure is forms based. Meaning they provide a user name and password.
Here is a tutorial with the steps to do, it is a relatively straight forward process. just follow all the steps.
http://blogs.technet.com/b/mahesm/archive/2010/04/07/configure-forms-based-authentication-fba-with-sharepoint-2010.aspx
If you move you site out of Intranet zone, then IE will automatically ask for credential everytime.
See this:
http://support.microsoft.com/kb/258063
When running Sharepoint (WSS 3.0) with Windows Authentication (NTLM), external users must supply their usernames in the form of DOMAIN\username. This makes sense, because you could have multiple domains, trusts between them, etc. However in my case, I only have one domain, and I want my users to be able to logon with their pure username only. Is there any way to configure Sharepoint with a default logon-Domain to get this to work?
Changing the authentication to basic or forms is not an option for me.
That's a windows/IIS issue rather than something specific to sharepoint.
You can find a more detailed explanation at http://forums.iis.net/t/1151401.aspx but basically it's impossible due to the the design of integrated authentication - the client has to know the domain before the server is contacted.
The closest you get to a default domain is local logins on the server - potentially a solution if users are truly external.
Realize that some browsers can be configured to automatically provide NTLM credentials. For example, IE can do this. I believe by default it will for sites in the Local Intranet and maybe even for Trusted sites (if not, you can change it so it will).
There is software out there for pushing these settings (policies) out to users if their computer is a part of your domain.
We're currently investigating what kind of authentication we want to use for a sharepoint portal site : Forms Authentication or Windows Authentication. The latter has my preference.
What suprised me (I'm a sharepoint noob), is the fact that MS didn't provide a component/web-part that handles account management when using Windows Authentication.
Do you now how to do this? Without resorting to buying an additional product. Shouldn't it be very easy to access the Active Directory by code (C#)?
Windows Authentication
I echo Justin's thoughts regarding AD management. Adding users to your domain also doesn't necessarily have anything to do with adding them to SharePoint. However perhaps there is an IIS add-on that does this if you wish to pursue it.
If you don't already know, SharePoint can automatically import user profiles from your Active Directory domain. This makes them available for assigning permissions within the sites.
Some additional info from Justin's comment about changing the AD structure to administer security: With SharePoint 2007 you no longer need to rely on Active Directory to manage groups of users. It's possible to also use SharePoint groups (which can contain AD users or AD groups). This works really well when you need to create a group for a purpose that isn't applicable outside SharePoint and you don't want to bug the infrastructure team. The downside is that without education, end users probably won't manage this well and it can become a mess.
Forms Authentication
It's true there is very little provided by Microsoft for managing this. However the Community Kit for SharePoint provides this functionality. From memory I had to tweak their code a bit but I was generally happy with it.
If you are considering this option also read this MSDN article.
It's much easier to just use the regular AD management tools provided with Windows rather than trying to manage your users' permissions through a web interface (for groups and such).
...of course you'll need access to make changes to your AD structure to administer the security.
Another alternative you may want to consider is using Forms Authentication using the Active Directory provider. It'll allow you to use the Forms Auth user admin tools and still authenticate against an Active Directory environment.
IF this is for users who are not a part of your actual domain (i.e. extranet users), I suggest you take a look at ADAM, Active Directory in Application Mode. It behaves the same as regular AD, can be administered through the windows.
Also, take a look at the following codeplex project, ADSelfService, it allows users to edit their own AD profiles. Perhaps you can extend the code yourself to allow admins to edit all profiles.
AdSelfService Project
We want to implement SSO functionality in our organization, but we're not really sure what our options are, and what the benefits / disadvantages for the different solutions might be.
-We have multiple old ASP(Active Server Pages) sites which should use SSO
-We have multiple ASP.net web-Applications which should use SSO
-We want Sharepoint to use the SSO
-CRM (Biztalk?) integration (Additional information about the user, such as Address, company, etc )
Since we're primarly .net, c#, Microsoft oriented, my first idea was to use Active Directory.
I've also noticed that there is something called ADAM (Active Directory Application Mode), and ADFS (Active Directory Federation Services), but I can't really say I understand when/where these should be used.
Here is a brief overview of the different web-applications
-"My Personal Page" : User log's into an application where they can modify their personal information along with their company-information and their employees. (Asp.Net)
-E-learning application (ASP)
-CMS system for web-publishing (ASP.Net)
-Sharepoint sites
I haven't really been able to find any articles that can tell me "AD is a great choice! , you can use it everywhere", so If anyone has got any experience /feedback to give me on this, it would be really helpful.
Also: How should rights/roles be managed ? Should all access/rights/roles for each application be stored in AD, or should this be stored in the applications themselves.
IE : AD stores the roles:
"Cms" <-allowed to login to the cms system
"Cms.Article.AddAllowed" <-allowed to add article
"Cms.Article.DeleteAllowed" <-allowed to delete article
Or should this information be split up, so that AD holds information about which applications the user is allowed to log into, while the application itself holds information about what the user is allowed to do within the application when logged in
AD rights:
"Cms" <-Allowed to login to the cms system
Cms rights:
"Article.AddAllowed" <-allowed to add article
"Article.DeleteAllowed" <-allowed to delete article
So, when the user logs in, they are first authenticated against AD, and if that goes ok, the rights for the Cms application is fetched from a rights-table in the cms system ?
What are my options ? What other solutions other than AD do I have ?
Thank you for any feedback, its much appreciated !
We have done something similar in my organization. Here is the overall flow:
User requests web page
User is redirect to login screen along with SAML request
User authenticates against Active Directory
User is passed back to request web page with SAML response
User group/rights information is retrieved from database
If user requests page from another website same process occurs however if the user still has a session or selected the "remember me" feature then user does not have authenticate and gets logged in directly.
We use Sharepoint, but have not setup SSO yet. I believe Sharepoint gets the rights of the user from its own backend database/system. We also have a homegrown system to update user's groups/rights. I know Sharepoint can use web services so you could possible update Sharepoint when using a centralized user management system (of course you'd have to build that). The main thing is finding out where Sharepoint gets its information about the user and how you can tie your existing system to it...
I wouldn't rely on Active Directory to store group/rights information. It a pain to deal with compared to a database and is not flexible. It's fine for authentication and password management you just have to tie the user on Active Directory to your database system.
As far as I know, Active Directory is only practical for users within your domain. You would need an administrator to manage all those users and to add new users.
I've been working on a project myself where I wanted users to sign in, just to know their identity. I did not even care about their access rights but just wanted an identity on every visitor, something more reliable than an IP address, cookie, session key or whatever else. So I first asked my administrators if I could use Active Directory for this project. Sure, I could. But the webhost wasn't connected to our company domain so I would end up with only one user. Yeah, my administrator is a bit sarcastic sometimes.
So I started to explore SSO options. OpenID like this site is a good option and you could even implement your own OpenID server and require all visitors to sign on there first. It's a very powerful technique and you have less worries about managing users in your project. (Because the OpenID provider takes care of this.)
However, I ended up using CardSpace instead. :-) With CardSpace, every user can create their own user-token and store it on their own system. To log on, the website just asks for the card and the user just clicks on it. Those cards can be migrated to other systems but tend to be tied to a single computer and user, most of the time. (Although users can share a card!)
Rights and Roles are a different matter than Authentication. People always think they're connected while in reality, these are two different things. First, use OpenID or CardSpace or another authentication technique to verify the identity of the user. It doesn't matter how they're identified, you just need an identifier.
Next, you need rights and roles. Roles are basically just user-groups and you can connect an identity to a group. Or to multiple groups. And rights would be linked to roles, not users. But how you're going to divide these roles just depends on the applications. Just remember that someone who is an administrator in your version control system should not be an administrator in your customer database. Roles tend to be application-defined, thus every application could manage their own rights and roles and just needs a way to link these to an identity.
I myself just needed identities so I knew whom to blame when something ended up messed up. Then again, when there's only 5 users, things tend to become quite simple.
I'm starting on a project to allow an existing web application to use active directory for authentication but leaving authorization within the application. I want to start off simple so I was thinking a user would type their AD username/password into my existing login form, I would then do an ldap bind against the AD server to authenticate the user.
Once the user is authenticated, I would pull that user from my database which has all the authorization information as to what functions the user can see.
My question is what is the best AD element to store in my table to make the association? In the past I've used username but after looking at some of the elements that AD returns I was wondering if I should use the security ID or GUID or something else?
I've been burned when a username changes like an employee gets married or divorced... so I know that is brittle.
I was targeting windows 2003 AD and above if that makes a difference; this is for a product where some clients have large AD forest and some are small networks.
Storing the SID is the most reliable approach; this is the unique ID that all Microsoft AD things use, security groups, permissions, etc.
If you're building on .Net you should seriously consider .Net 3.5, there's a new namespace System.DirectoryServices.AccountManagement that greatly simplifies code here and gives you nice neat objects to go against.
Unless users share computers, why not use Windows integrated logon? Much easier on the users, easier on yourself as developer, and more secure (one less place a password can be sniffed).
Need I mention that allowing user identities to change is poor corporate security policy? Makes traceability harder, permits some novel attack vectors, and gives you this headache.
As Nick mentions, the SID is a stable identifier, but not something you should ask a user to enter for him/herself!