Is it possible, safe and practical to use Windows Integrated Security on an Extranet?
E.g. there is an IIS website on the intranet that can be used over the LAN with integrated authentication. When the user disconnects from the LAN he wants to be able to use the browser on his domain-joined-notebook to connect to the same website over the internet (no VPN) without having to logon separately.
Yes, it is definitely possible to use integrated security. But, it also depends on the framework you are using for authentication. In ASP.NET you can use built in authentication module. You to set the authentication mode to "Windows" and .Net will manage it for you. You can also have different roles for managing different types of users in your web app. You web app must be available outside your LAN(i.e. your firewall should not block incoming HTTP requests)
Vamyip
The question of whether it's "safe" is a question of what additional security threats you're exposing the user to in the Internet scenario, that they weren't exposed to in the Intranet scenario. Additionally, are you exposing the server to additional security threats - and assuming that the question isn't "whether to allow access to the server from the Internet" but rather "which authentication methods should we allow for this server-now-exposed-to-the-Internet", this secondary question boils down to "is it better to use Windows integrated authentication protocols or require the use of Basic, Digest or digital certificates"?
Security threats to user/client: are the user's credentials reasonably protected from attackers who "sniff them from the wire"? Windows-integrated authentication uses either NTLM or Kerberos; in extranet scenarios, the user/client can't generally rely on Kerberos, since that would require transparent access to a KDC (i.e. an Active Directory domain controller) from the Internet as well. While this can be done, it's unusual to see a security-conscious organization allow that. So we're talking about NTLM - which hashes the user's password with a "nonce" (random set of characters) that are sent from the server, so that the user's password doesn't appear in plaintext over the wire. Compare NTLM to Basic and it's a clear win; compare NTLM to Digest authentication, and it's somewhat equivalent; compare NTLM to client certificate authentication, and certs always win for security (but lose on the deployment/bootstrapping challenges). Generally you'll find your security or server admins will want to use an SSL certificate for the IIS listener that's exposed to the Internet, so that user's credentials are even more protected against "sniffers". SSL is hardly perfect and doesn't protect against more sophisticated attackers in the middle (or someone who has a trojan/bot on the client device), but it costs very little for an extra layer of peace of mind. SSL + NTLM is a reasonable choice made by many.
Security threats to server: server is exposed to unauthorized attackers trying to gain access to authenticated resources. If the server allows any AD-authenticated authentication protocols then it's equally susceptible (or not) to attacks that try to brute force a user's password, and some sort of IDS solution that raises alarm bells for repeated bad password attempts is advisable (but quite a challenge to get the signal/noise ratio down to manageable levels). The server is also exposed to the possibility that any exploitable holes (primarily in IIS, or anything else exposed through the firewall) can be used to gain privileged access to the server by an outside attacker. Better be prepared for frequent patching. Other less likely but scary-sounding security threats are possible, but that's the big ones to tackle first.