home *** CD-ROM | disk | FTP | other *** search
- DOCUMENT:Q103055 04-NOV-1993 [W_NT]
- TITLE :Network DDE Fails with Floating Profile from Other Computer
- PRODUCT :Windows NT
- PROD/VER:3.10
- OPER/SYS:WINDOWS
- KEYWORDS:buglist3.10
-
- ----------------------------------------------------------------------
- The information in this article applies to:
-
- - Microsoft Windows NT operating system, version 3.1
- - Microsoft Windows NT Advanced Server, version 3.1
- ----------------------------------------------------------------------
-
- WARNING: Using Registry Editor incorrectly can cause
- serious, system-wide problems that may require you to
- reinstall Windows NT to correct them. Microsoft cannot
- guarantee that any problems resulting from the use of
- Registry Editor can be solved. Use this tool at your own
- risk.
-
-
- SYMPTOMS
- ========
-
- Users who have floating or mandatory user profiles cannot receive Chat
- conversations on computers other than the one on which their original
- profile was created. Similarly, they will not be able to successfully
- create Clipbook Viewer pages or play Hearts. If a profile is created
- on the computer they will use, these applications will function on
- their own computer, but not on other computers. If their initial
- profile is created on an administrator's computer, these applications
- will not work on any computer.
-
- CAUSE
- =====
-
- When Network DDE validates a conversation, it first checks to see if
- the DDE share is listed as a trusted share for the user logged on to
- the computer sharing the conversation. It does this by opening the
- following Registry subkey
-
- HKEY_CURRENT_USER\Software\Microsoft\NetDDE
- \DDE Trusted Shares\DDEDBi<xxxxxxx>
-
- where <xxxxxxx> is a serial number found in the SharesDBInstance value
- of the following subkey:
-
- HKEY_LOCAL_MACHINE\Software\Microsoft\NetDDE\DDE Shares
-
- This serial number is statistically unique on each computer and serves
- to tie the Trusted Shares list to the computer on which the shares are
- trusted. These keys are created during setup. For floating and
- mandatory profiles, the DDEDBi<xxxxxxx> subkey will contain only the
- entry for the computer on which the profile was created. When Network
- DDE attempts to open the DDEDBi<xxxxxxx> subkey on other computers,
- the attempt fails since other computers do not have the same serial
- numbers. This behavior disallows Network DDE conversations from being
- established.
-
- NOTE: You must be a member of the Users, Power Users, Server
- Operators, or Administrators group in order to create Clipbook pages.
-
- WORKAROUND
- ==========
-
- To work around this problem, create floating profiles on the
- workstation that the user is likely to work on. You can also enable
- Network DDE applications to work on a particular computer by
- manipulating values in the Registry. You need to copy the DDE trusted
- shares information from the target computer's default profile into the
- user's online profile. You must have administrative privileges on the
- target computer in order to perform these actions:
-
- 1. Start Registry Editor (REGEDT32.EXE) on the remote workstation or
- the target computer.
-
- 2. If you logged on to the remote workstation, choose Select Computer
- from the Registry menu to look at the Registry database on the
- target computer.
-
- 3. In the target computer's Registry database, move to the following
- subkey and make a note of the subkey name that is in the form of
- DDEDBi<xxxxxxxx>:
-
- HKEY_USERS\.DEFAULT\Software\Microsoft\NetDDE
- \DDE Trusted Shares
-
- 4. Select the DDEDBi<xxxxxxxx> subkey and choose Save Key from the
- Registry menu, saving the file to a UNC path with the following
- format:
-
- \\<computer name>\<share name>\<path>
-
- 5. Select HKEY_USERS on Local Machine and choose Load Hive from the
- Registry menu. Load the floating or mandatory profile from the
- shared directory indicated in the user's account under Profile
- Information (this is the location that the profile is downloaded
- from when the user logs on). Use any name for the key when
- prompted (TEST for example).
-
- 6. Under the loaded user profile (TEST), select the following subkey:
-
- Software\Microsoft\NetDDE\DDE Trusted Shares
-
- 7. From the Edit menu, choose Add Key and enter the name you noted in
- step 3.
-
- 8. Select the new DDEDBi<xxxxxxx> subkey and choose Restore from the
- Registry menu. When prompted, enter the same path to the saved key
- that you used in step 4.
-
- 9. Use the Security Permissions command to change the new
- DDEDBi<xxxxxxxx> subkey to have the same permission as the other
- DDEDBi<xxxxxxxx> subkey that is next to it. Be sure to change all
- subkeys by choosing Replace Permission On Existing Subkeys in
- the Permissions dialog box.
-
- 10. Select the root key of this hive (TEST) and choose Unload Hive
- from the Registry menu.
-
- BACKGROUND
- ==========
-
- Clipbook, Chat, and Hearts rely upon Network DDE to operate. Network
- DDE is a protocol for sending DDE messages across a network. Similar
- to the way in which directories may be shared across the network, a
- DDE conversation can be "shared" on the network. The Network DDE DSDM
- service maintains a database of shared conversations on each computer.
- When you share a page in Clipbook, a Network DDE share is created in
- this database. Similarly, in order for Chat to operate, Setup creates
- a Network DDE share for Chat.
-
- When a Network DDE share is accessed over a network, the shared
- conversation is referenced, and appropriate security checks are made
- to make sure the requester can be granted access. For some shared
- conversations, an application must be running on the computer sharing
- the conversation--for example, any time a linked item needs to be
- updated, or when a Chat conversation is started with someone. In
- either case, the application that placed the information in Clipbook
- (Microsoft Excel for example) or Chat must be running in order to
- service the request. All applications on a computer are running in the
- "security context" of the user who is interactively logged on to the
- computer. Therefore, when a remote request is serviced by a running
- application on a computer sharing a Network DDE conversation, the
- application handling the request is running in the security context of
- the person logged on to the sharing computer, not in the remote user's
- security context.
-
- With this design, there is the potential for security violations.
- Conceivably, a user could share a Network DDE conversation and
- remotely connect to it while someone else was logged on, thus enabling
- the user to access the sharing computer as if he or she were the other
- logged on user. To avoid this situation, in order for a shared
- conversation to be used, the logged on user at the time of use must
- have this shared conversation in its list of trusted shares.
-
- When Windows NT is installed, the following Registry value
-
- HKEY_LOCAL_MACHINE\Software\Microsoft\NetDDE
- \DDE Shares\SharesDBInstance
-
- is set to a random number in order to uniquely identify the computer.
- The Chat$, CLPBK$, and Hearts$ keys are also created under the
- following subkey:
-
- HKEY_USERS\Default\Software\Microsoft\NetDDE
- \DDE Trusted Shares\DDEDBi<xxxxxxxx>
-
- The <xxxxxxxx> value in this key name is obtained from the random
- number entered in the SharesDBInstance value, as mentioned above. When
- a new user logs on or a floating or mandatory profile is created on a
- computer, these keys and values are copied into the user's profile.
- This means that the user's profile has all the Network DDE keys the
- user will need for the computer that he or she first logs on to or
- that the profile is created on. However, the user does not have
- similar entries for other computers that the user may log on to. When
- Network DDE is asked to add a trusted share for a user, a new
- DDEDBi<xxxxxxxx> key should be created. Instead, Network DDE attempts
- to open this key and the attempt fails because the key does not exist.
-
- The Trusted Shares list and the list of Network DDE shares are kept in
- the Registry and in general should not be directly modified. However,
- to work around this problem, it is easiest to manually patch the
- Registry as described in the "Workaround" section above.
-
- Additional reference words: 3.10
- KBCategory:
- KBSubCategory: NETSRV NTAP
-
- =============================================================================
-
- THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
- PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS
- ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
- OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO
- EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
- ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
- CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
- MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
- POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION
- OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
- SO THE FOREGOING LIMITATION MAY NOT APPLY.
-
- Copyright Microsoft Corporation 1993.