hieu

Ok... having some crazy issues. I have 2 domains, lets
call them alpha and beta. There is a trust implemented
enabling users of beta to access alpha. LCS is installed
on alpha domain. I have created user bob on alpha domain
and enabled him for SIP communications. Bob is on a
machine logged into beta domain. He identifies the LCS
server by IP address which is pingable and remote desktop-
able. He identifies login information based off of alpha
bob account. When attempting to sign in though, it takes a
moment and then it errors telling me that my sign-in,
username, or password is incorrect. Going into a machine
on the alpha domain, with the exact same information, it
goes in fine. What could be the problem?

So more generally, for people outside of the domain, if
they had an account on alpha domain, how would they log
into LCS?

bob christian

From reading, I assume that Bob has 2 accounts, one for Domain A and one for
Domain B. Are the below assumptions correct?:
Domain A - Bob Workstation A - Works
Domain B - Bob Workstation A - Does not work
Domain B - Bob Workstation B - Does not work
Domain A - Bob Workstation B - Works

Workstation indicates the domain membership of the workstation. Domain
indicates the domain selected on the user authentication box on the GINA
(Ctrl-Alt-Del screen).

Though I haven't tried using pass-through (pass-thru) authentication for
users that don't have a LCS server in their domain, it may work. Note I
haven't heard anyone using pass-through authentication for LCS users,
either. However, I have used pass-through authentication for Exchange
users, vendors not on our domain that need access to printers and file
servers, etc.

Pass-through (pass-thru) authentication is when users have a username and
password that are identical in two separate domains.
Domain A - Bob - PW: Pa$$word1234
Domain B - Bob - PW: Pa$$word1234


You may want to ensure that Bob's username and password are the same in both
domains. That might allow you to utilize this configuration without having
to stand up an additional LCS server in Domain B.

Others may have better input for you.


Bob

bob christian

From reading, I assume that Bob has 2 accounts, one for Domain A and one for
Domain B. Are the below assumptions correct?:
Domain A - Bob Workstation A - Works
Domain B - Bob Workstation A - Does not work
Domain B - Bob Workstation B - Does not work
Domain A - Bob Workstation B - Works

Workstation indicates the domain membership of the workstation. Domain
indicates the domain selected on the user authentication box on the GINA
(Ctrl-Alt-Del screen).

Though I haven't tried using pass-through (pass-thru) authentication for
users that don't have a LCS server in their domain, it may work. Note I
haven't heard anyone using pass-through authentication for LCS users,
either. However, I have used pass-through authentication for Exchange
users, vendors not on our domain that need access to printers and file
servers, etc.

Pass-through (pass-thru) authentication is when users have a username and
password that are identical in two separate domains.
Domain A - Bob - PW: Pa$$word1234
Domain B - Bob - PW: Pa$$word1234


You may want to ensure that Bob's username and password are the same in both
domains. That might allow you to utilize this configuration without having
to stand up an additional LCS server in Domain B.

Others may have better input for you.


Bob

thomas wenzl [mvp]

Hello Hieu,


it seems that you have a multi-forest scenario. Such
a scenario usually requires at least one LCS home
server in each domain, an user account for
every user in each domain and some data synched
between those two user accounts using MIIS
or scripts.

That's the supported scenario, everything else is
not supported, but you could give it a try if you
want.

Please explain your Active Directory
topology in more detail, if you think you
don't have a multi-forest topology.


That's the exepected behavior - at least if you are
testing in a multi-forest topology. Due to the existing trust
between alpha and beta, the beta credentials are passed
to the alpha domain. Since the user account in the
beta domain isn't enabled for LCS in alpha domain,
etc., authentication failed.

Have you tried to specify the alpha user account
(incl. beta domain!) as your LCS log-on credentials
instead of your beta credentials (using Windows authentication)?

see above. That's the expected behavior, since
only the account on the alpha domain is enabled
for LCS and has the required attributes.


If they are on the beta domain or standalone workstations?

Try to specify the credentials of the user on the alpha
domain (incl. domain name).

Regards
--
Thomas Wenzl [MVP for Live Communications Server]

Share what you know, learn what you don't!
(Deja/Google)

thomas wenzl [mvp]

Hello Hieu,


it seems that you have a multi-forest scenario. Such
a scenario usually requires at least one LCS home
server in each domain, an user account for
every user in each domain and some data synched
between those two user accounts using MIIS
or scripts.

That's the supported scenario, everything else is
not supported, but you could give it a try if you
want.

Please explain your Active Directory
topology in more detail, if you think you
don't have a multi-forest topology.


That's the exepected behavior - at least if you are
testing in a multi-forest topology. Due to the existing trust
between alpha and beta, the beta credentials are passed
to the alpha domain. Since the user account in the
beta domain isn't enabled for LCS in alpha domain,
etc., authentication failed.

Have you tried to specify the alpha user account
(incl. beta domain!) as your LCS log-on credentials
instead of your beta credentials (using Windows authentication)?

see above. That's the expected behavior, since
only the account on the alpha domain is enabled
for LCS and has the required attributes.


If they are on the beta domain or standalone workstations?

Try to specify the credentials of the user on the alpha
domain (incl. domain name).

Regards
--
Thomas Wenzl [MVP for Live Communications Server]

Share what you know, learn what you don't!
(Deja/Google)