locked
Automatic logon in a test domain RRS feed

  • Question

  • May the users of Domain A do an Automatic logon to an OCS 2007 Srvr installed in Domain B using Office Communicator 2007? How?

     

    Thanks for the help.

     

    Rafael

    Saturday, March 22, 2008 1:22 AM

Answers

  • Thanks for the background information. Your thoughts about the existing domain level (Windows 2000) is a fair one but as long as you are running in Windows 2000 Native Mode you should be ok. Review the Active Directory Guide for more details.

     

    If you are testing the product and have chosen this path, simply accept the credential challenge and press forward. If you are considering this to be your production solution please take the time to read up on the multiple forest solution and recognize that this will then impact every other product you choose to deploy (with an obvious Microsoft slant - Sharepoint, Exchange Server would be the 2 biggest). The multiple forest approach requires a lot more administration.

     

     

     

    Tuesday, April 1, 2008 1:53 PM

All replies

  •  

    That is possible using a resource forest model.  This involves creating a disabled user acount in domain B for each user in domain A and linking the accounts using the SIDmap tool in the OCS resource kit.
    Sunday, March 23, 2008 8:35 AM
  • This is possible.  Disregard the resource forest post, this is a single forest with multiple domains not multiple forests.  Configuring Automatic logon will not be a problem. 

    Do the users in Domain A and Domain B share the same sip domain? (ex.  userDomainA@company.com and userDomainB@company.com).  If so then make sure that the DNS servers the clients lookup have the correct zone matching their sip domain with correct SRV records to locate the OCS service (ex. company.com zone).  If on the otherhand they have use different sip domains, then make sure you provision SRVs within the respective zone for those users to locate OCS service.  For example:

     

    SIP URI (aka SignIn) userDomainA@company.com

    DNS Zone:   Users with this sip URI will lookup up "company.com" DNS zone for the SRV records

     

     

    SIP URI (aka SignIn)  userDomainB@corp.company.com

     DNS Zone:   Users with this sip URI will lookup up "corp.company.com" DNZ zone for the SRV records

    Note:  If the OCS servers reside within the Company.com zone, you may have to set the SRV record to point to a CNAME record you create for this to work.  Example below:

     

    Zone:  corp.company.com

    SRV:  _sipinternaltls

    Service:  _tcp

    Priority: 0

    Weight: 0

    Host:  ocspool.corp.company.com

     

    CNAME:

    ocspool.corp.company.com ----> ocspool.company.com

     

    Let me know if this helps....

     

    Tuesday, March 25, 2008 9:10 PM
  •  James Denavit wrote:

     

    That is possible using a resource forest model.  This involves creating a disabled user acount in domain B for each user in domain A and linking the accounts using the SIDmap tool in the OCS resource kit.

     

    Well, if that means I have to change AD topology in my production domain, maybe I don't want to do it only for a couple of weeks testing, as long the final setup for me will be "one domain only".

     

    Anyway, many thanks for you support.

     

    Rafael

    Monday, March 31, 2008 4:25 PM
  •  Rick Skalitzky wrote:

    This is possible.  Disregard the resource forest post, this is a single forest with multiple domains not multiple forests.  Configuring Automatic logon will not be a problem. 

    Do the users in Domain A and Domain B share the same sip domain? (ex.  userDomainA@company.com and userDomainB@company.com).  If so then make sure that the DNS servers the clients lookup have the correct zone matching their sip domain with correct SRV records to locate the OCS service (ex. company.com zone).  If on the otherhand they have use different sip domains, then make sure you provision SRVs within the respective zone for those users to locate OCS service.  For example:

     

    SIP URI (aka SignIn) userDomainA@company.com

    DNS Zone:   Users with this sip URI will lookup up "company.com" DNS zone for the SRV records

     

     

    SIP URI (aka SignIn)  userDomainB@corp.company.com

     DNS Zone:   Users with this sip URI will lookup up "corp.company.com" DNZ zone for the SRV records

    Note:  If the OCS servers reside within the Company.com zone, you may have to set the SRV record to point to a CNAME record you create for this to work.  Example below:

     

    Zone:  corp.company.com

    SRV:  _sipinternaltls

    Service:  _tcp

    Priority: 0

    Weight: 0

    Host:  ocspool.corp.company.com

     

    CNAME:

    ocspool.corp.company.com ----> ocspool.company.com

     

    Let me know if this helps....

     

     

    Thanks for the answer. Sorry, but It didn't work.

     

    Let me explain my setup with more detail, just in case I didn't explain it enough in the first post.

     

    Users in Domain A (the production domain) are a Windows 2000 native domain, with Windows2000Srvr on every DC or Member. They don't have a "sip domain".

    Domain B (the test domain) is in a different forest, Windows 2000 native, Windows2003Srvr on the OCS2007Srvr wich is the only DC in this domain.

     

    I have a DNS zone on my production domain pointing to the test server on the test domain:

     

    Zone: test.com

     

    SRV: _sip

    Service: _tls

    ...

    Port: 5061

    Host: 10.12.x.y

     

    Also have other records: sip.test.com and sipinternaltls.test.com pointing to the same IP

     

    With this config, setting Communicator 2007 to work in Automatic Configuration, I can logon from the production domain, but have to write the password every time , with the following credentials:

     

    Sign-in address: user@test.com

    Username: user@test.com

     

    I also added in the DNS production zone the same records (_sip, sip and sipinternaltls). The behaviour is the same (can logon but have to write the password everytime) when I try to logon with the following credentials

     

    Sign-in address: user@production.com

    Username: user@test.com

     

    After receiving your post, I made the DNS changes you recommended but it made no difference.

     

    So, if I understood what you said, it seems it doesn't work.

     

    Many thanks. Please let me know if you have further sugestions.

    Regards

     

    Rafael

    Monday, March 31, 2008 4:26 PM
  • The fact that you can enter the password confirms the setup, what you are running into is the authentication model. You are being challenged for credentials and the system supplies the currently logged on user credentials. The one thing you might be able to change is to force NTLM. I don't have a setup with multiple domains but I do know that if your client is in a domain it will respond to the Kerberos challenge if offered. Restart the services after making the change.

    Monday, March 31, 2008 7:33 PM
  • If you need more details about the resource forest model see http://technet.microsoft.com/en-us/library/bb894704.aspx.  You do not need to extend the schema in the production forest, but you do have to add a trust.

     

    Monday, March 31, 2008 10:35 PM
  •  Tom Laciano - MSFT wrote:

    The fact that you can enter the password confirms the setup, what you are running into is the authentication model. You are being challenged for credentials and the system supplies the currently logged on user credentials. The one thing you might be able to change is to force NTLM. I don't have a setup with multiple domains but I do know that if your client is in a domain it will respond to the Kerberos challenge if offered. Restart the services after making the change.

    Well, I did this, disabling Kerberos on the OCS server (which is a DC), but no changes.

     

    When trying to do an automatic logon, MOC logs the following:

    «

    Communicator was unable to authenticate to the server sip/srv1.test.com due to following error: 0x80090303.

    Resolution:

    Please check that the password is correct and that the user name and SIP URI are specified correctly. If the login continues to fail, the network administrator should verify that the user account is not disabled, that it is enabled for login to the service and that the password for the account hasn't expired or been reset.

    »

    Then it prompts for password. After typing the password, it logs this:

    «

    Communicator was unable to authenticate because an authenticating authority was not reachable.

    Resolution:

    The server may be asking for Kerberos authentication and Communicator is not able to find the Kerberos Domain Controller in order to generate credentials and authenticate. The network administrator will need to change the configuration on the server to utilize only NTLM authentication before Communicator can login from this location properly, or connectivity will need to be made available to an authenticating authority.

    »

    And then logs in.

     

    But the same sequence repeats after restarting MOC.

     

     

    Tuesday, April 1, 2008 10:49 AM
  •  James Denavit wrote:
    If you need more details about the resource forest model see http://technet.microsoft.com/en-us/library/bb894704.aspx.  You do not need to extend the schema in the production forest, but you do have to add a trust.

     

     

    This link reffers to an unavailable page. Do you have other sources?

     

    If I only have to add a trust, my test domain already trusts my production domain.

     

    Regards

    Tuesday, April 1, 2008 11:13 AM
  • 2 things

    1) When you describe this configuration the 2 forests are what is important, not the 2 domains. Many customers have multiple domains in a single forest without this problem, it is the issue of 2 forests. The forest is the security boundary and so you have a unique ID for each. This is why people are giving you information on the Resource Forest approach with OCS. The current link is this - http://technet.microsoft.com/en-us/library/bb894704.aspx

     

    2) Your description of disabling Kerberos is not what I was trying to communicate. Do not disable this for your domain or on domain controllers as this will have significant negative impact to the domain. I wanted you to disable it on the OCS server. Open the OCS MMC - Navigate to the Enterprise or Standard Edtion level, select the pool (if SE this will be the FQDN of the server). Right click, select properties, front end properties and on the authentication tab select NTLM. The setting of Both NTLM and Kerberos won't work for a domain joined system as it will choose Kerberos as it is more secure.

     

    We have been answering your very specific questions on the problem, but why did you choose this approach?

     

     

    Tuesday, April 1, 2008 12:34 PM
  •  Tom Laciano - MSFT wrote:

    2 things

    1) When you describe this configuration the 2 forests are what is important, not the 2 domains. Many customers have multiple domains in a single forest without this problem, it is the issue of 2 forests. The forest is the security boundary and so you have a unique ID for each. This is why people are giving you information on the Resource Forest approach with OCS. The current link is this - http://technet.microsoft.com/en-us/library/bb894704.aspx

     

    2) Your description of disabling Kerberos is not what I was trying to communicate. Do not disable this for your domain or on domain controllers as this will have significant negative impact to the domain. I wanted you to disable it on the OCS server. Open the OCS MMC - Navigate to the Enterprise or Standard Edtion level, select the pool (if SE this will be the FQDN of the server). Right click, select properties, front end properties and on the authentication tab select NTLM. The setting of Both NTLM and Kerberos won't work for a domain joined system as it will choose Kerberos as it is more secure.

     

    We have been answering your very specific questions on the problem, but why did you choose this approach?

     

     

    First of all, thanks for all comments and suggestions. I appreciate.

    1) I will pay attention to the Resource Forest model asap.

     

    2) After reenabling kerberos on the server, changing the Front Ends authentication protocol to NTLM and restarting both services and server (IIS Admin restart didn't work), the situation remains the same on the client side: keeps asking for password every time I start MOC or try to sign-in.

     

    Why we have chosen this approach? Because our production domain is still a native windows 2000 domain, only with windows 2000 servers and some old services software (MS Sharepoint 2001), which (we are not sure) may be incompatible with the AD model needed for Windows 2003 and OCS 2007. For this, we are trying this setup in a different forest first (we were afraid of damadging the production AD). So, as we already have a working OCS2007 server, we wanted to test it with MOC in the production domain before deploying.

     

    Regards

    Tuesday, April 1, 2008 1:40 PM
  • Thanks for the background information. Your thoughts about the existing domain level (Windows 2000) is a fair one but as long as you are running in Windows 2000 Native Mode you should be ok. Review the Active Directory Guide for more details.

     

    If you are testing the product and have chosen this path, simply accept the credential challenge and press forward. If you are considering this to be your production solution please take the time to read up on the multiple forest solution and recognize that this will then impact every other product you choose to deploy (with an obvious Microsoft slant - Sharepoint, Exchange Server would be the 2 biggest). The multiple forest approach requires a lot more administration.

     

     

     

    Tuesday, April 1, 2008 1:53 PM
  •  Tom Laciano - MSFT wrote:

    Thanks for the background information. Your thoughts about the existing domain level (Windows 2000) is a fair one but as long as you are running in Windows 2000 Native Mode you should be ok. Review the Active Directory Guide for more details.

     

    If you are testing the product and have chosen this path, simply accept the credential challenge and press forward. If you are considering this to be your production solution please take the time to read up on the multiple forest solution and recognize that this will then impact every other product you choose to deploy (with an obvious Microsoft slant - Sharepoint, Exchange Server would be the 2 biggest). The multiple forest approach requires a lot more administration.

     

     

     

    I think you are right. The only potential things I noticed in our setup lab that could change AD and harm SP2001 was Adprep /forestprep and adprep /domainprep and raising the domain from 2000 Mixed Mode to Native. But this, we have already done to the production domain, so I think I'm not afraid anymore.

    Just one aditional question if you can answer here: Will we miss any OCS2007 feature if we do not raise de domain level to Windows 2003 Mode?

     

    Again, many thanks for you patience. See you next time.

     

    Rafael

    Tuesday, April 1, 2008 2:15 PM
  • Rafael,

    I am aware of NO known limitations of features or problems if you do not raise to Windows 2003 Mode. The real reason for the mode requirement is for Universal Groups.

    Tuesday, April 1, 2008 2:22 PM
  • Thanks Tom - disabling Kerberos fixed it for me.

     

    Regards,

    Matt

     

     

    Friday, July 18, 2008 9:26 PM
  • Saturday, July 19, 2008 9:57 AM
    Moderator