I want to have a mixed mode SharePoint 2010 install where intranet users are authenticated via Windows Authentication, and extranet users are authenticated via forms authentication.
There is an existing solution here, http://www.orbitone.com/en/blog/archive/2010/06/23/sharepoint-2010-mixed-authentication-automatic-login.aspx, but I have one unusual difference. In most cases, the Windows authentication goes against an AD server and the forms authentication goes against an ASP.Net membership database. In my case, they're both going against AD servers. The users who use forms authentication are stored on an extranet AD server, and the users who use Windows authentication are stored on an intranet AD server. The extranet AD server has pass through authenciation set up with the intranet AD server, so SharePoint is always directly connected to the extranet AD server.
Is there a better approach to automatic mixed mode authentication in this case?
You are already doing things correctly. When you have internal users on an external farm, SharePoint will look for an available AD server and send the user in question to AD for verification. With the one way trust, AD knows to check the trusted domain for the user in question if it does not exist in its own domain. The whole point of the trust to to avoid calls through the network to your internal domain directly. So technically the users are being authenticated to the domains as you described. If its not working, I would bet your trust is not correctly configured.
Related
Is there an advantage in using a trusted connection vs a sql login for web application? Is there any pros/cons from one to another?
I usually use Windows Authentication, which is more secure, with a service account. If you are doing an internal application within your own domain and you want to authenticate your users to the database server, you will need to set up delegation on that service account along with the IIS and SQL services. If it is outward facing or you aren't concerned with authenticating users to the database, you simply need to give the relevant permissions to the service account login in SQL. In either case, assuming your webserver is IIS, you would change the web application to run under the service account. This will encrypt and store the credentials on the webserver.
The main reason windows authentication is more secure is it makes use of the Active Directory infrastructure to authenticate users using encrypted messages between the servers. With SQL Authentication the credentials are passed across the network. If you do use SQL Authentication, you should make sure to encrypt the connection string portion of your web config, as you would embed the credentials including the password.
we already have users in enterprise AD and we want kerberos ticket to be generated for these users from local kerberos server instead of the kerberos service in the AD itself.
the intent of this we want to make enterprise AD transparent to the exixtence of kerberos mechanism
the approach that we are thinking is--
say we have 3 boxes:
Enterprise AD
local AD with embedded kerberos
Role based access control box
Flow that we are thinking--
RBAC box will receive user request for authentication and authorization
in place of forwarding request to enterprise AD , RBAC box forwards request to our local AD with embedded kerberos.
now, local AD with embedded kerberos queries enterprise AD for user authentication.
on success of authentication, local AD with kerberos generates ticket and sends response back to RBAC box which either allows/denies the services to user.
we don't know if this could be done, if possible please guide us or suggest approach for achieving the same.
Thanks
If enterprise AD and local ADs are organized as forrest, then it might be possible to realize this scenario using the "cross-realm authentication": https://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx
Here's what I'm trying to accomplish: I have a website built on a CMS that can authenticate over LDAP. I would like for users to be able to use their AD usernames and passwords to authenticate to the website.
Basically I'm trying to understand if there is a good way to make Active Directory available externally through an LDAP connection. What options are there for this sort of thing?
Researching online I've found some suggestions to set up AD LDS on our DMZ and have it replicate with our internal Domain Controller. It seems like that would work, but I don't have a very deep understanding of AD LDS, so I'm not sure.
Is there some standard way of doing this? Or is it generally considered best practice to just set up a separate user database for external use?
If you already have all your "externally hosted website" users in your AD domain, you should be able to do LDAP authentication against any DC.
If you do not want your "externally hosted website" users in your domain, then setup a LDS instance. (But I would not put it in the DMZ. Just open a point-to-point path through the firewall to the LDS instance for port 636.)
-jim
I'm trying to determine if SSO is what I want to use in my scenario. All of our users are in an AD. I have some web-based services that authenticate via the AD (currently they ask the user for a login when they visit the sites). Key points:
All users have a windows laptops joined to the AD.
Sometimes they access these websites on the LAN (AD server accessible), sometimes via the internet (AD server inaccessible).
Some users may want to access these websites through a non-AD computer (e.g. tablet, phone, home computer)
Users use a range of different browsers.
The websites are mostly running through apache on linux servers
Does AD-based SSO work:
if the client machine cannot contact the AD server directly? e.g. the laptop has logged in using cached credentials?
if the user is using a browser other than IE?
Is it possible to have fallback auth mechanisms in place? e.g. if SSO is not possible, then fall back to http auth or cookie auth?
Cheers,
Victor
Yes, if cached credentials are used, when browser requests a Kerberos service ticket, the cached credentials are used by Windows to get a TGT for the user and then the service ticket is requested. This is transparent to the user, so they get same experience as if they were in office, connected to the LAN, and not using cached credentials.
Some other browsers support the Negotiate protocol, not just IE. I am aware that Firefox does, and I think Safari does also.
You might get more flexibility through ADFS which is a Windows component that allows you to use claims based authentication.
The intra/extranet sceanrios are simpler, the interop story is quite good. (Since your web sites are non Microsoft ones).
Tons of documentation in TechNet
After some theoretical help on the best approach for allowing a SaaS product to authenticate users against a tenant's internal Active Directory (or other LDAP) server.
The application is hosted, but a requirement exists that tenants can delegate authentication to their existing user management provider such as AD or OpenLDAP etc. Tools such as Microsoft Online's hosted exchange support corporate AD sync.
Assuming the client doesn't want to forward port 389 to their domain controller, what is the best approach for this?
After doing some research and talking to a few system admins who would be managing this, we've settled on an two options, which should satisfy most people. I'll describe them here for those who were also interested in the outcome.
Authentication Service installed in the origanisation's DMZ
If users wish to utilise authentication with an on-premises active directory server they will be required to install an agent in their DMZ and open port 443 to it. Our service will be configured to hit this service to perform authentication.
This service will sit in the DMZ and receive authentication requests from the SaaS application. The service will attempt to bind to active directory with these credentials and return a status to indicate success or failure.
In this instance the application's forms based authentication will not change, and the user will not be aware of the authentication behind the scenes.
OpenId
Similar to the first approach, a service will be installed in the client's DMZ, and port 443 will be opened. This will be an OpenId provider.
The SaaS application will be an OpenId consumer (already is for Facebook, Twitter, Google etc login).
When a user wishes to log in, the OpenId provider will be presented, asking them to enter their user name and password. This login screen would be served from the client's DMZ. The user would never enter their username or password into the SaaS application.
In this instance, the existing forms based authentication is replaced with the OpenId authentication from the service in the client's DNZ.
A third option that we're investigating is Active Directory Federated Services, but this is proprietary to Active Directory. The other two solutions support any LDAP based authentication across the internet.
Perhaps this might help…
This vendor, Stormpath, offers a service providing: user authentication, user account management, with hookups to your customers’ on-premise directories.
What about an LDAPS connection to the customer's user directory? They can firewall this off so that only your servers have access if they're concerned about it being public. Since it's SSL it's secure end to end. All you need from them is the certificate from their issuing CA (if it's not a public one). I struggled to get this working for an internal web project in the DMZ and there's a real lack of any guides online. So I wrote one up when I'd got it working:
http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/
Your best bet is to implement a SAML authentication for your SaaS application, and then sign up with identity providers like Okta or OneLogin. Once that's done then you can also connect it with ADFS to provide Single Sign On for your web application through Active Directory.
I'm just doing this research myself and this is what I've came across of, will have more updates once implementation is done. Hope this gives you enough keywords to do another google search
My understanding is that there are three possible solutions:
Installing something on the domain controller to capture all user changes (additions, deletions, password changes) and send updates to the remote server. Unfortunately there's no way for the website to know the initial user passwords - only new ones once they are changed.
Provide access for the web server to connect to your domain controller via LDAP/WIF/ADFS. This would probably mean opening incoming ports in the company's firewall to allow a specific IP.
Otherwise, bypass usernames/passwords and use email-based authentication instead. Users would just have to authenticate via email once every 3-6 months for each device.
I have to begin implementing this for an upcoming project and I'm seriously leaning towards option #3 for simplicity.