Re: Single Sign On?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"AJ" <andyjones99@xxxxxxxxxxxxx> wrote in message
news:59bd8ad1-85f3-4421-8509-994bc8bbfba0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 26 May, 12:12, Meinolf Weber <meiweb(nospam)@gmx.de> wrote:
Hello AJ,

The trust will be the only way to use single sign on, as far as i know.
Otherwise
the user credentials can not be checked in your domain.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and
confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!!http://www.blakjak.demon.co.uk/mul_crss.htm



Hello

We have a customer who logs into their own local domain for file
resources and they use our domain for other resources such as
sharepoint. The customer access is via the internet (No VPN) and they
authenticate using basic authentication and SSL via ISA. The customer
only wants to have to enter login credentials once (their local domain
creds) as opposed to getting challenged for credentials of our domain
when accessing our resources.

Any idea how this can be implemented or if a solution that provides
this exists. I dont want to have to create a forest trust with their
domain becuase there is no level of trust with their network.

Any help appreciated

Thanks

AJ- Hide quoted text -

- Show quoted text -

Hi Meinolf
<<
Thanks for your reply. The customer users our domain accounts to
access their sharepoint site and Exchange server which is in our
forest. I guess I could configure a one way trust where they trust our
domain and then they could actually log into their local machines
(which are a member of their local AD domain) using their accounts
that they use to access their Exchange/SharePoint site which are
actually accounts in our domain. They could then grant permissions to
these accounts against their local domain resources as required. Does
that make sense? :)


That's possible -- the key is which is least disturbing for them,
or most meets the security, admin, and other needs of the
various admins (yours and theirs).

IF you trust THEIR domain then you will trust their DCs to
authenticate them and they will use their "own domain" account.

IF they trust YOUR domain then theirs will trust your DCs to
authenticate them and they will use their account on "YOUR
domain."

Both are choices. The trust goes from the Resource (your
stuff or their computers) TOWARDS the ACCOUNT
domain -- that simple.




.

Relevant Pages

  • Re: Single Sign On?
    ... resources and they use our domain for other resources such as ... The customer access is via the internet and they ... domain becuase there is no level of trust with their network. ... The customer users our domain accounts to ...
    (microsoft.public.win2000.active_directory)
  • Re: Single Sign On?
    ... resources and they use our domain for other resources such as ... The customer access is via the internet and they ... domain becuase there is no level of trust with their network. ... The customer users our domain accounts to ...
    (microsoft.public.win2000.active_directory)
  • Re: Single Sign On?
    ... on multiple ports. ... The customer access is via the internet and they ... domain becuase there is no level of trust with their network. ... The customer users our domain accounts to ...
    (microsoft.public.win2000.active_directory)
  • Re: Single Sign On?
    ... The trust will be the only way to use single sign on, ... Otherwise the user credentials can not be checked in your domain. ... We have a customer who logs into their own local domain for file ... resources and they use our domain for other resources such as ...
    (microsoft.public.win2000.active_directory)
  • Re: Stop mapped drives from locking AD accounts lock when passwords are changed?
    ... Whoever "possesses" the needed resource needs to grant permissions to the ... Once a Trust is set up *Everybody* uses it. ... have their accounts granted permissions to resources,...and some do ... resources on the other domain. ...
    (microsoft.public.windows.server.active_directory)