another question...could somebody help me. This is what I want to do:
login page https://enter.mydomain.com
- if an internal employee needs to login from the LAN/WAN (at the office or VPN) -> authentication = AD account + password
- if an external partner or employee needs to login from the internet -> authentication = AD account email attrib + password + tokencode
I know how to setup the authentication servers, but have a problem with the 2-way or 3-way authentication
How can I setup something like this?
Authentication is tied to realms, and realms are determined based on either the logon URL or a choice made on the login page. Are you willing to have different URLs for the "inside" and "outside" access?
The authentication for employee is straightforward. The authentication for partner is obviously a little more complex. From what you wrote it looks like you will need to define an additional authentication server but it is a little hard to tell. Can you breakdown that one a bit more?
The way I read it is that you are asking for the partner to enter in a combination of all three values (email, passwd, token) - that can be done a couple of ways depending on your backend server(s). As an example I use tokens from Quest (Defender) and your scenario is very easy. My AD server is setup w/IAS to allow for radius auth and the Quest validation would handle a combined pass+token scenario.
But I can't tell how your server(s) are looking for the data flow.
So if you can provide a little more detail I am sure we can get you up and running.
When an employee is working from home he needs id+passw+token = OK
Now I want to give them access via the same URL (make it easier for them) at the office, but then I do not need the token as they are then connecting via there office pc.
I don't think there is any way to keep the same URL, and get different authentication. It might be possible to do something by using the token authentication as the secondary authentication and take advantage of the fact that you can configure the realm so that the user can still log on if the secondary authentication failed. Then, you could build a custom login page which determined if the user were on the internet or on your intranet, and created a default token value if you were on the intranet. Then you might be able to make a decision in role mapping based on whether the secondary authentication succeeded. Pretty complex stuff.
An alternative, if you have another web server which you could use to do a redirect, is to create a new URL for the internal interface (say, employees-internal.mydomain.com) and map it to a realm which only has id+passwd authentication. Then, use your internal DNS to point employees.mydomain.com to the other web server, which would do nothing but do a redirect to employees-internal.mydomain.com.
If you can be sure your internal IP addresses will never match external addresses (which is unlikely to be honest) you could use an Authentication policy to condition the realms such that you can only access the internal realm internally and the external realm externally. Alternatively set up a host check that is only true if you are on the Internal network and an NOT version and use these to condition the realms. Then you can apply both realms to the same URL but only one will be allowed. If only one realm is allowed then the box will use it by default and not display the realm list drop down. We're using something like this to migrate to a new secondary authentication solution by deploying a file to migrated users.
The key is your conditioning needs to be always true internally and always false externally. The tough bit may be finding such a condition.
Your idea intrigues me. Let me make sure I understand it.
What you are saying is that URL https://employees.mydomain.com is set up to map users to two realms, say "Internal" and "External". Realm "Internal" does id+passwd authentication, and realm "External" does id+passwd+token authentication.
Realms "Internal" and "External" both have source IP restrictions. Realm "Internal" allows only internal subnets; realm "External" allows anything else. At login time, the source IP restrictions are evaluated and only the appropriate realm is available to the user, so no realm selection needs to be done on the login page.
Is my understanding correct?
Oh, that is awesome!
I just ran a small test, and it worked beautifully. I'm thinking of all sorts of ways I might be able to use this.
cK, dcvers has hit the nail on the head. Use the same DNS name inside and outside, and map it to two realms in the sign-in policies. Define one of the realms to do id+passwd authentication, and the other to do id+passwd+token authentication. Define a source IP restriction for the realm with id+passwd authentication to allow your internal addresses, and a source IP restriction for the realm with id+passwd+token authentication to deny your internal addresses.
As dcvers notes, this will work only if there is no overlap between your internal addresses and addresses on the Internet. If you use RFC1918 addresses for your internal network, this should be perfect.
your test ran well, my test is still somewhere going wrong.
For my "internal" realm I allow the internal subnet = I'm only getting the "internal" realm being userid+password
In the settings of my "external" realm I denied the same internal subnet but when logging on to https://employees.mydomain.com from the internet I'm getting "access is not allowed, please contact your system administrator" and no possibility to enter userid,passw or token
What am I doing wrong???
Do your sign-in policies for the https://employees.mydomain.com URL allow both the Internal and External realms? What do you see in your logs?