single sign on - why not trust AD?

For intranet development.. is there anything terribly wrong with
authenticating users against AD groups to determine what pages, menus,
features they should be allowed to see and use?
Would there be any valid reason for asking users to re-enter there AD
user and PW for every intranet Application to confirm they are in the
AD Rather than just testing the security of the windows user with the
below code? Any benefit to carring around a cookie or Session with
something that is then used to confirm they were authenticated at some
point in the session? What the value of this beyond allowing one user
to authenticate in an intranet site while windows is authenticated as
another user? And is there no risk to session or cookie that could be
easily read and replicated to fool the site?
What the best and/or most common practice for intranet website
security?
If (Page.User.IsInRole("XXX ADMIN")) Then
Thanks.not for intranet. as long as its a local lan (no internet access), then
you can use iis/ntlm for authentication.
-- bruce (sqlwork.com)
jc wrote:
> For intranet development.. is there anything terribly wrong with
> authenticating users against AD groups to determine what pages, menus,
> features they should be allowed to see and use?
> Would there be any valid reason for asking users to re-enter there AD
> user and PW for every intranet Application to confirm they are in the
> AD Rather than just testing the security of the windows user with the
> below code? Any benefit to carring around a cookie or Session with
> something that is then used to confirm they were authenticated at some
> point in the session? What the value of this beyond allowing one user
> to authenticate in an intranet site while windows is authenticated as
> another user? And is there no risk to session or cookie that could be
> easily read and replicated to fool the site?
> What the best and/or most common practice for intranet website
> security?
>
> If (Page.User.IsInRole("XXX ADMIN")) Then
>
> Thanks.