Here you are the Scenario that I see in all my implementation:
- you have organization that its internal domain name is Contoso.local
- then you install an Exchange Server whether 2003 or 2007 and you create E-mail Policy for your public external domain which is for example @contoso.com,
- you want to implement OCS where users will log in to communicator client with a unique login address whether from internally or externally using username@contoso.com
OK …to accomplish this there are some tricky actions you need to do but let us first understand how things usually work so that we would better understand what exactly we need to change.
Certificates
· OCS 2007 generally depends on Certificates like the air to us, so rule number one always check the certificate. Certificates are what the OCS uses to assure a secure communication between different OCS servers and also with the clients.
· The Idea behind a certificate is simply that you create a certificate for a computer with an identity of the FQDN of the server which is in our case here is ocsserver.contoso.local
· Upon communication between 2 OCS Servers or between OCS servers and client , the first thing that happens is that they both exchange certificates together , the certificate assures the name of the server and must be issued from a trusted CA issuer .
DNS
· OCS 2007 also uses the DNS SRV records whether internally or externally to identify the OCS Server name , this is only required for the Automatic login for the OCS users , if you want to bypass this then you will manually define the OCS Server pool internally and externally for all clients using Group policy and you will just need the A records for the server name .
Ok now we understood the basics for the OCS, let us see what happens normally internally when communicator client trying to login, if you understood this part then you will be able to identify alone how to reconfigure this for another domain.
1. Communicator client opens and you write an email for the login which is username@contoso.local
2. Communicator goes to DNS to ask for the domain contoso.local and request from the DNS if there are any SRV records for this domain.
3. If yes then the communicator retrieve the OCS server name which is serving this domain
4. It lookup with the DNS for an A record for that OCS FQDN server
5. When it finds it , the communicator tries to communicate with the server MTLS secure communication over 5061 port, this is secure channel where the server has to present a certificate to the client matching the FQDN which was presented by the DNS
6. When this is confirmed then authentication completes and communicator logs in.
This way is the same whether you want to login from inside or from outside your network through edge.
Now finally let us see what we need to change here in order to make the users able to login with username@contoso.com internally and externally
· From the Active directory domains and trusts let us first create a new domain name prefix called contoso.com , this will provide us with the ability to change the active directory login name from user@contoso.local to user@contoso.com . don’t worry this will not affect the user by anyway .
· Secondly we need to create identification for this new domain contoso.com inside our DNS servers internally and externally. So we create a new Zone inside the DNS servers with Contoso.com and make an A record for the OCS FQDN server in it OCSServer.contoso.local and you might also need to create A record for the OCS FQDN server with the format of OCSserver.comtoso.com . both A records will point to the same IP
· Then the SRV record inside this zone and pointing to the OCS server
· From the OCS Server, on the Global configuration you have to add contoso.com to the SIP domains served by the OCS.
· Last thing now to do to make this work would be the certificate , because we need the certificates to be presented with the domain ID of contoso.com not contoso.local
The certificate must match the FQDN returned by any DNS SRV query. Therefore, the certificate must contain multiple entries. We call these SANs (Subject Alternate Name) and the certificate must include the FQDN of the pool and one entry for each supported SIP domain.
Subject Name: OCSSRV.contoso.local
Subject Alternate Name: Sip.contoso.local,sip.contoso.com,ocsserver.contoso.local,ocsserver.contoso.com
· Now return to OCS deployment and choose configure certificate wizard,Choose to assign existing certificate and choose the new certificate you created
· Assign the certificate in the IIS and restart IIS and OCS Front end service
· For the external access, do the DNS part and the Certificate part again but pointing to the access edge server.
Now you can sign In with user@contoso.com J from anywhere
Appendix: How to configure a CA to accept a SAN attribute from a certificate request
By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behavior, run the following commands at a command prompt on the server that runs the Certification Authority service.
Certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc