I didnt know where this should go so posted it to iis.security also.

I have a site which is windows authentication based on a domain that has
active directory as its backend on IIS 6 / Win2k3 servers. My site is
published to the internet through ISA Server 2004 SP1. I want the user to
use their internal company login to get to the secured site, but right now
it requires them to enter it in domain\username format, how can i elimiate
the need to have the domain name before the username and assume the internal
domain as the one they will authenticate against? (there is only one domain)
thanks!

Use UPN, and have the users type in:
usern***@YourCompany.com  ??

Users don't have to remember domains, but they can remember the company
they work for...


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//


Smokey Grindel wrote:
Show quoteHide quote

I don't want to have to use anything but their username...

Show quoteHide quote

My question goes along this route.

If the "intranet" site is within the same domain that the username and
computer is on, why does it even prompt them for authentication?  Is there no
way to just automatically use the current computer login credentials?

I have this issue with my SharePoint services site and other miscellaneous
sites.

Is it possible to use anonymous logon but NTFS permissions to get around the
security prompt?

Show quoteHide quote

If you are just interested in getting rid of the login prompt then you
are probably overlooking the system's misconfigurations and simply
trying to get something to work insecurely. If that is the objective,
then use anonymous authentication (i.e. no security).

The relevent security-related questions are:
1. Why should the client automatically broadcast current computer login
credentials to any server. Suppose that server is rogue -- the client
just compromised your user credentials by giving it to the server
2. Why should the server automatically trust credentials given by the
client - who should the server validate against?

If you are getting a login prompt, then it simply means you have not
configured the client/server correctly enough to feel that the
transaction is trusted.

Remember, just because you think the action is trusted does not mean
the computer agrees. Humans are remarkably bad at enforcing security
protocol and good at making leaps of faith; computers are remarkably
bad at determining trust but good at enforcing security protocol.

Not the right way to reason about security or auto-login.

When you configure the server to require authentication, it will prompt
for authentication ALL the time. The question is whether the client
automatically responds with user credentials that meet the server's
demands.

The fact that the intranet site is in the same domain as the username
and computer is irrelevant from a security perspective. All the server
knows is that a client is asking for a secured document, and the server
knows a domain controller to validate user credentials. So, the server
says to the client "halt, prove to me who you are and I will authorize
and give you the document". At which point the client has to provide
some credentials (which may be from the same domain as the server --
irrelevant), and the server takes those credentials and asks the domain
controller if it is valid. If valid, the server returns the document.
If invalid, the server continues saying "halt, prove to me who you are
and I will give you the document".

No where in the entire security protocol does "domain" matter. The
concept of "domain" is only a human organizational concept useful for
authorization (i.e. who can do what). It has no relevance for
authentication (i.e. who you are).

Of course, depending on the authentication protocol, the transmission
of the user credentials and protocol sequenc differs, and some
protocols are not safe to automatically send user credentials (such as
Basic authentication).

The systems are secure the way they are. If you want to optimize away
the user login prompts, then those are secondary tasks.

This request does not make sense. The security prompt indicates a real
security misconfiguration on the server. How does one fabricate an
arbitrary NT user token out of an anonymous logon to pass NTFS
permissions? If this works, then what stops me from impersonating as
you or the administrator on the server.


If you can describe your customized situation as well as network
configuration further, then maybe someone can help. I can only say that
when I set up Sharepoint sites, by default it works without requiring
login prompts from my computers using my local login of a domain
account.



//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//


Shawn Melton wrote:
Show quoteHide quote

I have my SharePoint site configured as disabling Anonymous access and then
Integrated Windows authentication.

If I allow anonymous access and take off Integrated authentication, then the
user access I specify in each SharePoint site would work like NTFS
permissions?

One catch, I do have field personnel that can connect to my subnet where my
SharePoint is at, but their computer is not on the domain.  So they login to
their computer as a workgroup account.  How would this affect them?

Show quoteHide quote

I don't understand what you are asking.

If you allow only anonymous authentication, how would it work like NTFS
permissions? Anonymous authentication means only the configured
anonymous user is used to access resources on the server no matter the
remote user.

Field personnel's work-group account is the same as unknown user so
they'd get prompted with Integrated Authentication and as configured
anonymous user if Anonymous authentication. But your field personnel
computers can be in the domain, take cached copies of the domain with
them (automatically by Windows), and have auto-login with Integrated
Authentication work just fine even when the field personnel is
disconnected from the domain.

So, I'm confused by your auto-login/prompt issues. They shouldn't exist
given propr configuration.


//David





Shawn Melton wrote:
Show quoteHide quote

UNC Share causing Internal Server Error 500
Win2K3, IIS6, and IE6 - Can't get IWA/NTLM to work
MS IIS Setting: HTTP Failed To Connect if Using Machine Name
Virus in IFRAME injected into our ASP pages (downloader trojan on client)
notepad will not save .config file in iis7
RPC over HTTPS for Exchange
IIS Security and files upload/create
"Certificate does not have a private key"
Multiple SSL - Same Server - Same Port/IP
Multiple SSL sites served from a single content path