Microsoft Windows Server 2003 Enterprise Edition
Novell ZENworks 7 Desktop Management - ZfD7 Desktop
Management
Internet Explorer personal certificates do not work on the
user's second login to any Terminal Server.
The environment is a group of Terminal Servers in a workgroup
(not a domain) with the ZENworks Desktop Management 7 agent
installed. A DLU policy is configured with Volatile User
enabled. The Desktop Preferences policy has been
configured to enable Roaming Profiles.
The steps to reproduce the issue are as follows:
a) establish first thin session to Terminal Server
b) login to eDirectory, allowing DLU to create the local
Windows user and the roaming profile should be created
c) import a Personal Certificate in Internet ExplorerÂ
(test it)
d) logout, allowing the roaming profile to be copied to the
network
e) establish second thin session to Terminal Server
f) login to eDirectory, allowing DLU to create the local
Windows user, and the roaming profile to be brought down
g) test the certificate in Internet Explorer - results are
that the site cannot be accessed until the certificate is
reimported
Since the Volatile User feature is enabled, a logout results
in the user account being deleted which means each user login
to the Terminal Server will result in a new user account being
created in the local SAM. Everytime a new user account is created,
a new SID (Security IDentifier) is assigned to the user.
When a user imports a personal IE certificate, that users account
is the only account that can use the IE certificate - it is based
on the users SID. When the roaming profile is brought down,
it contains a certificate imported with a different SID.Â
Since each DLU login gives the Windows user a new SID, the IE
certificates are broken - because they will only work with the SID
of the user that imported the certificate. For this reason,
personal certificates stored in roaming profiles will not work when
DLU is configured to be volatile.
Volatile DLU is working as designed. If the
configuration is used where a users SID is new on each login,
you could try automating (and hiding) the import of the certificate
instead of depending on the retained certificate in the
profile. For example:
You could use a command line utility to import the certificates
every time a user logs in (either put it in the Run registry key,
or use a force run NAL app, even a WMSCHED scheduled action would
work). CertMgr is a Microsoft utility that you can use to import
certificates via command line. You can google for the utility and
syntax. One potential issue that you will have using this
command line utility is that you could be using a third-party
certificate in pfx format, which is not fully supported under the
CertMgr command line. These third-party certificates need high
security protection with a password and they are designed to be
imported via user interface in order to protect the private key.
CertMgr only provides limited command line support to these
third-party certificates. For this scenario, maybe you can import
the certificate via user interface and then export to .cer format,
without the private key. Therefore, you can deploy them with
CertMgr. Since the private key is only used for the server, the
public key is enough to allow the client to connect.
Even in a non-Terminal Server environment that uses volatile
DLU with roaming profiles you would see this issue with personal IE
certificates. In a domain environment, this is not a problem
because you always use your domain account - which would
always be the same SID, and therefore the IE certs would work for
multiple logins, on multiple Terminal Servers. In a non-domain
environment, each server will have a different SID for a given
user, so the stored certificate in the roaming profile won't work
for users using multiple servers, or receiving new SIDs on the same
server.