Search results for 'app:weblogs' matching tags 'troubleshooting', 'tip', and 'Security'

Disabling a User in AD Does Not Disable the User In Lync

Anonymous — Mon, 21 Mar 2011 05:00:00 GMT

It's quite common for companies to disable user accounts in Active Directory, rather than delete them, when a user leaves the company. This allows other IT staff and managers to access that user's data and email after they are gone.

However, disabling a user account in Active Directory does not immediately disable the user from using Lync. This is due to the way that Lync performs authentication and, depending on several factors, could result in a disabled user accessing Lync for up to nearly 6 months! Obviously, this is important to understand since you don't want disabled users to access internal resources or make Enterprise Voice calls.

The purpose of this article is to explain how and why this happens and how to successfully disable a Lync user's account immediately without having to delete the user account from AD.

Lync Server 2010 uses several methods of authentication: Kerberos, NTLM, and certificate based. Kerberos is the default authentication method and successful authentication results in the client receiving a Kerberos ticket that's good for 10 hours. Kerberos is used when users are accessing Lync Server while on the domain. NTLM is used for authentication from other locations, such as the Internet for remote access using Lync Edge servers.

If the user authenticates using one of these two methods and selects the Save my password check box (shown above), the Lync server will generate an X.509 certificate for the user. Lync will publish the certificate to Lync RTC database and distribute it, along with the private key, to the personal certificate store to the user on the local computer. The certificate expires 180 days from the publication date and is used for further authentication for that user from that computer. An example OCS signed certificate from the user's Personal certificate store is shown below:

Certificate authentication is convenient and speeds up the sign-in process significantly, but it means that Lync doesn't check the AD user account to see if it's disabled. If a disabled user signs into Lync using certificate authentication, they will still have access to all Lync features including IM, web conferencing and Enterprise Voice until the certificate expires.

The certificate(s) used by a Lync user can be viewed from the Lync Management Shell using the Get-CsClientCertificate cmdlet. For example,

Get-CsClientCertificate sip:username@domain.com

will display all the certificates the certificates stored in the rtc database for that user. If the user has run Lync from three different computers, there will be three certificates listed for the user, as shown below:

Remote users with a valid client certificate can continue to sign in and access Lync until their certificate expires, regardless of whether their account is disabled or not.

You can revoke a certificate using the Revoke-CsClientCertificate cmdlet in the Lync Management Shell, but this will not affect users who are currently signed into Lync. For domain computers, the user will be able to use Lync until their Kerberos ticket expires (up to 10 hours). Remote users using certificate authentication will remain signed in until they sign out, the Lync server is restarted, or their certificate expires (up to 180 days).

To prevent a user (enabled or disabled) from using Lync, you must disable their Lync account using the Lync Control Panel or the Lync Management Shell, as shown below:

To disable the Lync user account using the Management Shell, run the following cmdlet:
Disable-CsUser sip:user@domain.com
Note that it may still take a few minutes for a signed-in user to become disconnected, however they will be unable to access any Lync features, such as new IM, web conferencing, or Enterprise Voice calls immediately. If they happen to be in an IM session or web conference when their Lync account is disabled, they can continue until they disconnect. Likewise, if they are in a voice call when their Lync account is disabled, the call will continue until the call ends. The Lync client for the disabled user will display the following:

Thanks to Tom Pacyk for sharing this with me while he was at Microsoft Certified Master: Lync Server training.

Installing Lync 2010 Without Domain Admin Rights

Anonymous — Wed, 16 Feb 2011 06:00:00 GMT

I recently installed Lync Server 2010 at a customer where I did not have Domain Admin rights. This presents a challenge, since setting up Lync Server requires various updates to Active Directory. The online documentation isn't very clear on on this, so that's the purpose of this article.

Before you get started installing Lync, you will need to update the schema and prepare both the forest and the domains. The schema updates require Schema Admin rights, and the forest and domain preps require Enterprise Admin rights or Domain Admin rights in each domain.

In order to hand over the Lync Server installation to a non-Domain Admin, you will need to do a few more things. First, add the Lync setup administrator account to the CS Administrator and RTCUniversalServerAdmins groups in AD. These groups were created in the domainprep steps performed earlier.

Next, you will need to grant setup permissions to allow the Lync setup administrator to update AD as needed by the Lync Server Topology Builder tool. This is done using the Grant-CsSetupPermission cmdlet.

Logon to the server where Lync is going to be installed as a member of the Domain Admins group.
Open the Lync Server Management Shell as an administrator and run the following cmdlet:

Grant-CsSetupPermission -ComputerOU <DN of the OU where the Lync server exists>

For example:

Grant-CsSetupPermission -ComputerOU “OU=Lync Servers,OU=Servers,DC=US,DC=companyabc,DC=local”

If this step is not run, it will fail to enable the topology in the Topology Builder and you will see the following error:

Error: An error occurred: “System.UnauthorizedAccessException” “Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED))”

Finally, grant permissions to allow the Lync setup administrator to update objects in the Lync servers OU with necessary group memberships. This is done using the Grant-CsOUPermission cmdlet.

Logon to the server where Lync is going to be installed as a member of the Domain Admins group.
Open the Lync Server Management Shell as an administrator and run the following cmdlet:

Grant-CsOUPermission -OU <DN of the OU where the Lync server exists> -ObjectType "user"

For example:

Grant-CsSetupPermission -OU “OU=Lync Servers,OU=Servers,DC=US,DC=companyabc,DC=local” -ObjectType "user"

If this step is not run, you will see the following errors when publishing the Lync topology with Topology Builder:

Error: An error occurred when add "lyncpool" to "RTCComponentUniversalServices".
Error: An error occurred when add "lyncpool" to "RTCHSUniversalServices".
Error: An error occurred when add "lyncpool" to "RTCHSUniversalServices".
Error: An error occurred when add "lyncpool" to "RTCComponentUniversalServices".
Error: An error occurred when add "lyncpool" to "RTCUniversalConfigReplicator".
Error: An error occurred when add "lyncpool" to "RTCComponentUniversalServices".
Error: An error occurred when add "lyncpool" to "RTCComponentUniversalServices".

You can now turn the setup over to the Lync setup administrator to complete the installation.

Adding users to local security groups using Group Policy

Anonymous — Thu, 03 Feb 2011 06:00:00 GMT

You may find that you need to add users to one or more local groups, such as Power Users or Administrators, on their computer. While you can do this fairly easily on a case by case basis, it's a lot more difficult to do in a large distributed environment. This can be accomplished much easier using the Restricted Groups GPO setting in Group Policy.

The Restricted Group setting allows you to configure membership in groups within Active Directory or in the local security accounts manager (SAM) of domain-joined computers.

In this example, we will add all domain users to the local computers' Power Users group for all computers in the domain.

Open the Group Policy Management Console
Edit the Default Domain Policy
Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups
Right-click Restricted Groups and select Add Group...
The trick to adding a local group is to just type in the group name. Do not browse to find the Power Users group, because this will resolve to the domain's Power Users group. Type Power Users, as shown below, and click OK.

Another window will pop-up to let you configure the properties of the Power Users Restricted Group. For Members of this group, click Add.
Click the Browse button and browse for the group in Active Directory that you want to add to the local Power Users group. In this example, use Domain Users and click OK, as shown below.

Close the GPO Editor and the Group Policy Management Console

Wait a sufficient amount of time to allow the GPO to replicate throughout all the domain controllers in the domain, then restart the computers where the policy applies. This is required because the GPO affects the Computer Policy which applies when the computer starts up.

When the policy is processed, the computer will attempt to resolve the Power Users name that you typed to a local group first, then a domain group if no local match is found.

You can do the same process above for any other OU to scope the GPO to a specific set of computers. If you want to add users to the local Administrators group, simply type that name instead of Power Users.

How to fix MSExchangeTransport Event ID 12014 on Edge and Hub Transport servers

Anonymous — Wed, 29 Sep 2010 05:00:00 GMT

By default, Exchange 2007 and 2010 attempt to use Transport Layer Security (TLS) for all SMTP traffic. TLS uses a certificate on the receiving server to encrypt SMTP traffic between SMTP servers, similar to the way a certificate on the CAS server is used to secure OWA traffic. If TLS cannot be negotiated, SMTP will usually fallback to non-encrypted SMTP.

In order for a server to send SMTP email via TLS:

The receiving server must have an Exchange certificate in the computer's local Personal store.
The SMTP service must be assigned to use this certificate.
The FQDN used in the Receive Connector must match either the Common Name or one of the Subject Alternative Names (if they exist) on the SMTP certificate.

If any one of these requirements is not met, you will see the following error in the application log of the Edge Transport server:

Log Name:      Application
Source:        MSExchangeTransport
Date:          9/28/2010 9:35:58 AM
Event ID:      12014
Task Category: TransportService
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mailgate
Description:
Microsoft Exchange could not find a certificate that contains the domain name mail1.expta.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default internal receive connector MAILGATE with a FQDN parameter of mail.expta.com. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

When you see this error on Edge Transport servers you have to examine the error description to determine where the mismatch occurs. In the example above, the connector in error is the "Default internal receive connector MAILGATE", which is the receive connector that exists on the Edge server itself. If the connector in error is on the "EdgeSync - Inbound to domain" connector, the mismatch is on the Hub Transport server's receive connector.

You can fix this by reconfiguring the offending connector to use the Common Name or Subject Alternative Name used on the Exchange certificate. You can find this value by viewing the certificate from the Certificates MMC, as shown below:

To reconfigure the Edge Server's Receive Connector:

On the Edge server, open the Exchange Management Console.
Navigate to Microsoft Exchange > EdgeTransport.
Click the Receive Connectors tab to view the existing connectors.
Double-click the Default internal receive connector SERVER connector to view its properties.
In the Specify the FQDN this connector will provide in response to HELO or EHLO field, enter the certificate's Common Name (for example, ex1.expta.com) as shown below, and click OK.

To reconfigure the Hub Transport's Receive Connector:

On the CAS, open the Exchange Management Console.
Navigate to Microsoft Exchange > Microsoft Exchange On-Premises > Organization Configuration > Hub Transport.
Click the Send Connectors tab to view the existing Send Connectors.
Double-click the EdgeSync - Inbound to domain connector to view its properties.
In the Specify the FQDN this connector will provide in response to HELO or EHLO field enter the certificate's Common Name (for example, ex1.expta.com) as shown above, and click OK.

How to Create Certificates with a Longer Validity Period

Anonymous — Fri, 27 Aug 2010 05:00:00 GMT

So, you have your own Windows Certificate of Authority (CA) server and you want to create some new certificates that are valid longer than the default certificate templates. You duplicate the User Certificate, and set the validity period to 5 years. You issue a new user certificate using the new template and discover that the certificate expires two years from today. What's up with that?

The validity period of any certificate generated by a Windows CA is the lesser of these three values:

The remaining lifetime of the root CA server
The value specified in the certificate template
The value specified in the CA server registry (default is 2 years)

So even if you set the certificate template validity period to 10 years, certificates issued using this template will be valid for a maximum of two years with the CA's default settings.

Increasing the CA Lifetime
Most root CAs are typically valid for 5 years. To increase the lifetime of the root CA, create or edit a text file in %SYSTEMROOT% called CAPolicy.inf with the following text:

[Version]
Signature=”$Windows NT$”

[certsrv_server]
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10

Adjust the values above as needed, save the file, and restart the CertSrv service. Then renew the CA Certificate using the same public and private key pair.

Warning: If you generate a new public and private key pair you will need to reissue all your old certificates, so don't do it unless that is your intent.

Setting the Maximum Validity Period in the Registry
The default certificate validity period configured in the CA's registry is 2 years. To view the current registry value, run the following commands from a CMD prompt on the CA:

certutil -getreg ca\ValidityPeriod
certutil -getreg ca\ValidityPeriodUnits

To configure the registry value to 5 years, run the following command from a CMD prompt on the CA:

certutil -setreg ca\ValidityPeriodUnits 5

Adjust the value above, as needed. Then restart the CertSvc service to affect the changes.