Installing Lync 2013 in the resource forest
Sometimes deploying Microsoft Lync 2013 requires a resource domain. A resource domain is a place where only the Lync 2013 server itself lives directly. Users live in another domain — user-defined. How to make friends with each other, will be discussed below. Who cares, welcome under cat. It will be interesting (and all sorts of pictures).
As usual, the first question before any design decision "Why is all this necessary?". This decision is no exception. Why make a fuss if and so everything is set-up and working?
The first reason is psychological: installing MS Lync 2013 requires making certain changes (extensions) to the Active Directory schema. When you have one forest with one domain per 100 machines, this is one thing, but when you have a healthy infrastructure with a bunch of domains and critical services, expanding the scheme as potentially dangerous can become a stumbling block when communicating with the Customer. Works - do not touch here is the best manifested itself. And any of your persuasion about the fact that everything will pass normally will not have effects.
The second reason usually occurs on a pilot project. Not always the Customer is ready to change his infrastructure with pleasure in order to familiarize himself with the product and to understand whether it is suitable for him or not. Here there is a reunion with reason number one: why do I need all sorts of new objects in the system, if it is not yet clear whether the product will be implemented? Since I myself have worked as a system administrator for a long time, then on my own experience I can declare with full responsibility - they don’t like admins to invade their patrimony. And their dislike is fully shared by their leaders.
')
There may be other reasons. For example, security guards have their own opinion on communications systems and do not want to depend on administrators in this matter. Or something else.
And one thing remains - to raise a separate infrastructure for MS Lync, where he can do whatever he wants and this will not have any effect on the existing infrastructure.
In my example, I will do everything in a test environment, which is shown schematically below:
In my lab two forests are raised with one domain in each. Domain contoso.internal implies the existing infrastructure of the customer, where everything has long been established. The lync.internal domain implies a resource domain where the Lync server will be deployed. Between domains, one-way trust is raised, in which the lync.internal domain trusts the contoso.internal domain. The reverse is not true. One-sided trust is due to security concerns. But in most cases, you can safely raise a bilateral trust, which is significantly easier to troubleshoot.
To implement the above scheme in a virtual environment, the following structure of subnets was deployed:
Domain contoso.internal is deployed in the network 192.168.1.0/24, domain lync.internal is deployed in the network 192.168.2.0/24. At the same time, the contoso domain is raised based on Windows 2008, and the lync domain is based on Windows 2003 due to the specifics of the Customer (so that the reader has no questions about the screenshots). As a gateway, a software router based on Vyatta was raised.
Since The article is devoted to solving a strictly defined problem. I will not consider the following points:
However, before installing Lync, I will focus on configuring the PKI service. It will be convenient for further work.
The prologue is over. Getting started.
We need to have a network environment deployed and configured. Be sure to check the routing and traffic flow. Disable the firewall on all machines. Yet it is a lab, not a combat implementation.
We should have two forests with a domain in each. Be sure to raise the level of the domain and forest in the resource forest until 2003, otherwise Lync will not be established.
We need to have client machines deployed (for example, on Windows 7) with installed Lync clients (for example, from MS Office 2013).
MS Lync 2013 requires a certificate service. Of course, you can generate certificates somewhere and import into the system. But we are not raising the resource domain in order to have any restrictions.
So, before we deploy Lync itself, we need a running certificate service. Let's install it and before it starts issuing certificates, we will slightly change its settings.
Go to the properties of our CA and go to the Extensions tab. There we will see the following:
From all this disgrace, we need to leave only the top line leading to the local storage of the CRL. Feel free to remove the rest. Next, add a line to publish a sheet of revoked certificates via the http protocol in the simplest form. It will be convenient for users of the user domain. In my example, I added the line http (no need to expose and conjure with https. This is completely unnecessary) with the following content http: //crl.lync.internal/root.crl .
All certificates issued by this CA will indicate that you can check the list of revoked certificates in the above path. This article does not cover installing and configuring IIS (or any other web server) to support this method of publishing and the file copying mechanism. The reader is invited to do this on their own.
After that, you can safely install Lync 2013 in the usual way. Do not forget that in Lync there will be two SIP domains: lync.internal and contoso.internal. Therefore, when deploying Lync, be sure to specify an additional SIP domain.
If for any reason you have already deployed Lync, then in the Topology Builder add the second domain and perform the necessary procedures for changing the configuration (publishing and obtaining new certificates).
Building trust is a fairly simple procedure. First, in each domain in the DNS service, you must allow the transfer of your zone to another server. You can allow for the labs to transfer to everyone or immediately indicate that transfer only to a strictly specified DNS.
After that, in the contoso.internal domain, create a Secondary zone for Lync.internal, and in lync.internal create a Secondary zone for Contoso.internal. Make sure that this is replicable.
After that, you can move on to raising one-sided trust between domains.
For the Lync.internal domain, the trust to Contoso.internal will be Outgoing trust, for the Contoso.internal domain, the trust to Lync.internal will be vice versa incoming trust.
After creating a trust, it is MANDATORY to check with the Validate button in the trust properties that it is intact. A lot of problems with working in such a scheme are tied to the improper functioning of trusts.
For the Lync clients to work correctly from the user domain contoso.internal to the DNS of this domain, you must add two type A records:
Both entries must point to the Lync server IP in the lync.internal domain:
For each domain, create OU Lync Users for convenience. In this OU in the contoso.internal domain, create an account in the usual way. In my example, these are the two LyncTest and LyncTest2 accounts.
In the lync.internal domain in a similar OU, create similar users. Passwords do not matter. After creation, set the status of these accounts to Disable.
Launch the Lync 2013 Control panel and add the created and disabled accounts to the Lync system one by one:
When adding a record, give it the following properties.
Those. specify its sip address address from the domain contoso.internal.
Repeat this procedure for each account you add.
In the Contoso.internal domain, open the AD U & C snap-in and convert the display mode to advanced:
For each account that will be used in Lync, do the following: go to the account properties, open the attribute editor tab and upload the value of the ObjectSID parameter to the USB diskette :
Do not forget that each value must match the account in the lync domain. Internal.
By the way, so that the Lync client does not ask you to enter the user name in the client when you first start it is very convenient to register the sip address in the ProxyAddress attribute field. The address should be of the form sip: name @ domain. Those. in our case, it will be for the LyncTest2 sip user: lynctest2@contoso.internal:
After that go to the domain Lync.internal. Since we have a 2003 server here, then ADSIedit is necessary for editing attributes. It is included in the Support Tools kit, which is located on the distribution CD. If you do not have this tool, expand these utilities.
We start ADSIedit and find our substitute accounts in the lync.internal domain:
We find the msRTCSIP-OriginatorSid attribute in them and prescribe the previously saved values from ObjectSid for each account, respectively.
At the same time, we unload the root certificate of our CA and save it to removable media. It is useful to us.
In the contoso.internal domain, we go to the working machine as a user prepared for working with Lync (in our example, either LyncTest or LyncTest2).
Launch the Lync 2013 client and ...
We get a certificate error:
This is where the CA certificate unloaded earlier will come in handy. In one way or another, we distribute it to machines that will work with Lync (for example, through group policies or even manually) so that this certificate will be in the Trusted Root Certification Authorities container.
And after updating the policy, we start the Lync 2013 client again. The client will prompt for a password. Just click OK. After a while, a connection will occur.
Everything.
Don't forget the CRL. The certificate revocation list must be available to Lync clients. Otherwise, after 10 days, clients will not be able to verify the revoked certificates upon entry, and the login procedure will take 5-7 or even more minutes. It infuriates users.
Of course, by configuring group policies, you can increase the validity of the already received CRL to infinity. But that's another story. Good luck.
Why all this may be required?
As usual, the first question before any design decision "Why is all this necessary?". This decision is no exception. Why make a fuss if and so everything is set-up and working?
The first reason is psychological: installing MS Lync 2013 requires making certain changes (extensions) to the Active Directory schema. When you have one forest with one domain per 100 machines, this is one thing, but when you have a healthy infrastructure with a bunch of domains and critical services, expanding the scheme as potentially dangerous can become a stumbling block when communicating with the Customer. Works - do not touch here is the best manifested itself. And any of your persuasion about the fact that everything will pass normally will not have effects.
The second reason usually occurs on a pilot project. Not always the Customer is ready to change his infrastructure with pleasure in order to familiarize himself with the product and to understand whether it is suitable for him or not. Here there is a reunion with reason number one: why do I need all sorts of new objects in the system, if it is not yet clear whether the product will be implemented? Since I myself have worked as a system administrator for a long time, then on my own experience I can declare with full responsibility - they don’t like admins to invade their patrimony. And their dislike is fully shared by their leaders.
')
There may be other reasons. For example, security guards have their own opinion on communications systems and do not want to depend on administrators in this matter. Or something else.
And one thing remains - to raise a separate infrastructure for MS Lync, where he can do whatever he wants and this will not have any effect on the existing infrastructure.
What it looks like
In my example, I will do everything in a test environment, which is shown schematically below:
In my lab two forests are raised with one domain in each. Domain contoso.internal implies the existing infrastructure of the customer, where everything has long been established. The lync.internal domain implies a resource domain where the Lync server will be deployed. Between domains, one-way trust is raised, in which the lync.internal domain trusts the contoso.internal domain. The reverse is not true. One-sided trust is due to security concerns. But in most cases, you can safely raise a bilateral trust, which is significantly easier to troubleshoot.
To implement the above scheme in a virtual environment, the following structure of subnets was deployed:
Domain contoso.internal is deployed in the network 192.168.1.0/24, domain lync.internal is deployed in the network 192.168.2.0/24. At the same time, the contoso domain is raised based on Windows 2008, and the lync domain is based on Windows 2003 due to the specifics of the Customer (so that the reader has no questions about the screenshots). As a gateway, a software router based on Vyatta was raised.
What will not be considered in this article
Since The article is devoted to solving a strictly defined problem. I will not consider the following points:
- setting up a virtual environment and virtual machines;
- Deploying domain forests
- Install Lync and its clients on target PCs
- automate user synchronization between domains.
However, before installing Lync, I will focus on configuring the PKI service. It will be convenient for further work.
The prologue is over. Getting started.
What we need for a successful start
We need to have a network environment deployed and configured. Be sure to check the routing and traffic flow. Disable the firewall on all machines. Yet it is a lab, not a combat implementation.
We should have two forests with a domain in each. Be sure to raise the level of the domain and forest in the resource forest until 2003, otherwise Lync will not be established.
We need to have client machines deployed (for example, on Windows 7) with installed Lync clients (for example, from MS Office 2013).
Configuring the PKI service
MS Lync 2013 requires a certificate service. Of course, you can generate certificates somewhere and import into the system. But we are not raising the resource domain in order to have any restrictions.
So, before we deploy Lync itself, we need a running certificate service. Let's install it and before it starts issuing certificates, we will slightly change its settings.
Go to the properties of our CA and go to the Extensions tab. There we will see the following:
From all this disgrace, we need to leave only the top line leading to the local storage of the CRL. Feel free to remove the rest. Next, add a line to publish a sheet of revoked certificates via the http protocol in the simplest form. It will be convenient for users of the user domain. In my example, I added the line http (no need to expose and conjure with https. This is completely unnecessary) with the following content http: //crl.lync.internal/root.crl .
All certificates issued by this CA will indicate that you can check the list of revoked certificates in the above path. This article does not cover installing and configuring IIS (or any other web server) to support this method of publishing and the file copying mechanism. The reader is invited to do this on their own.
After that, you can safely install Lync 2013 in the usual way. Do not forget that in Lync there will be two SIP domains: lync.internal and contoso.internal. Therefore, when deploying Lync, be sure to specify an additional SIP domain.
If for any reason you have already deployed Lync, then in the Topology Builder add the second domain and perform the necessary procedures for changing the configuration (publishing and obtaining new certificates).
Building trust between domains
Building trust is a fairly simple procedure. First, in each domain in the DNS service, you must allow the transfer of your zone to another server. You can allow for the labs to transfer to everyone or immediately indicate that transfer only to a strictly specified DNS.
After that, in the contoso.internal domain, create a Secondary zone for Lync.internal, and in lync.internal create a Secondary zone for Contoso.internal. Make sure that this is replicable.
After that, you can move on to raising one-sided trust between domains.
For the Lync.internal domain, the trust to Contoso.internal will be Outgoing trust, for the Contoso.internal domain, the trust to Lync.internal will be vice versa incoming trust.
After creating a trust, it is MANDATORY to check with the Validate button in the trust properties that it is intact. A lot of problems with working in such a scheme are tied to the improper functioning of trusts.
DNS setup
For the Lync clients to work correctly from the user domain contoso.internal to the DNS of this domain, you must add two type A records:
- Meet.contoso.internal
- Sip.contoso.internal
Both entries must point to the Lync server IP in the lync.internal domain:
Custom settings
For each domain, create OU Lync Users for convenience. In this OU in the contoso.internal domain, create an account in the usual way. In my example, these are the two LyncTest and LyncTest2 accounts.
In the lync.internal domain in a similar OU, create similar users. Passwords do not matter. After creation, set the status of these accounts to Disable.
Launch the Lync 2013 Control panel and add the created and disabled accounts to the Lync system one by one:
When adding a record, give it the following properties.
Those. specify its sip address address from the domain contoso.internal.
Repeat this procedure for each account you add.
SID Setup
In the Contoso.internal domain, open the AD U & C snap-in and convert the display mode to advanced:
For each account that will be used in Lync, do the following: go to the account properties, open the attribute editor tab and upload the value of the ObjectSID parameter to the USB diskette :
Do not forget that each value must match the account in the lync domain. Internal.
By the way, so that the Lync client does not ask you to enter the user name in the client when you first start it is very convenient to register the sip address in the ProxyAddress attribute field. The address should be of the form sip: name @ domain. Those. in our case, it will be for the LyncTest2 sip user: lynctest2@contoso.internal:
After that go to the domain Lync.internal. Since we have a 2003 server here, then ADSIedit is necessary for editing attributes. It is included in the Support Tools kit, which is located on the distribution CD. If you do not have this tool, expand these utilities.
We start ADSIedit and find our substitute accounts in the lync.internal domain:
We find the msRTCSIP-OriginatorSid attribute in them and prescribe the previously saved values from ObjectSid for each account, respectively.
At the same time, we unload the root certificate of our CA and save it to removable media. It is useful to us.
Client launch
In the contoso.internal domain, we go to the working machine as a user prepared for working with Lync (in our example, either LyncTest or LyncTest2).
Launch the Lync 2013 client and ...
We get a certificate error:
This is where the CA certificate unloaded earlier will come in handy. In one way or another, we distribute it to machines that will work with Lync (for example, through group policies or even manually) so that this certificate will be in the Trusted Root Certification Authorities container.
And after updating the policy, we start the Lync 2013 client again. The client will prompt for a password. Just click OK. After a while, a connection will occur.
Everything.
Don't forget the CRL. The certificate revocation list must be available to Lync clients. Otherwise, after 10 days, clients will not be able to verify the revoked certificates upon entry, and the login procedure will take 5-7 or even more minutes. It infuriates users.
Of course, by configuring group policies, you can increase the validity of the already received CRL to infinity. But that's another story. Good luck.
Source: https://habr.com/ru/post/241883/
All Articles