Thursday, December 29, 2005
Anonymous Connections - win2000/win2003
What can an Anonymous Connection Accomplish?
I am sure I have your attention now! The question that must be on the tip of your tongue must be, “What can someone do if they gain anonymous access to my computer?” Of course the answer is “it depends!” It depends because it is based on not only what they acquire from your computer, but what they can do with it.
The basic information that someone can glean from your computer from an anonymous connection includes:
List of users from your computer, including Active Directory
List of groups from your computer, including Active Directory
SIDs for user accounts
User accounts for SIDs
List of shares from your computer
Account policies from your computer
NetBIOS name from your computer
Domain name that your computer is associated with
List of domains that your domain trusts
How to Make an Anonymous Connection
An anonymous connection is not something that you can make by accident. The syntax is not so simple that just anyone can make the connection. The point here is that if you have anonymous connections being made to your servers, someone is deliberately trying to gather information and you need to take immediate action.
The method that is mostly used to create an anonymous connection is to use the net use command. The net use command allows you to make a connection to a specific share on a server. The syntax would look something like this:
Net use \\10.10.10.10\ipc$ /u:”” “”
Here, you can replace the 10.10.10.10 IP address with the IP address of the server that you are accessing, or the NetBIOS name of the computer. In some instances, you can even get a list of all the computers that you could possibly connect to by running the following command:
Net view /domain:domainname
Once you have the computer names or IP addresses of the computers, you can attempt to make anonymous connections using the command above, or any “hacker” tool that exploits the anonymous access.
How Windows 2000 protected against anonymous connections
Microsoft has been aware of the anonymous access problem for quite some time. For Windows 2000, they implemented a Group Policy Object setting which allowed you to control how and if a user could create an anonymous connection to your computer. The setting is located in the Computer Configuration portion of any GPO. If you go below the Computer Configuration to the Windows Settings | Security Settings | Local Policies | Security Options, you will see the first GPO policy is related to anonymous connections, as shown in the figure.
Figure 1: GPO policy relating to anonymous connections
This policy can be configured to three different levels: 0, 1, and 2. These levels are displayed in the policy editor a bit differently, which is explained below. The Registry value that is being modified is HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous. Here is an explanation of the settings and what they protect against.
Level 0: “None. Rely on default permission”
This does not restrict any anonymous connections. This is a very insecure setting, but it is also the default on a Windows 2000 computer or domain.
Level 1: “Do not allow enumeration of SAM accounts or shares”
This is designed to not allow any anonymous access list the SAM or shares. However, there is a small problem here that this does not protect against all methods of accessing the SAM or shares from an anonymous connection. This setting is in essence no more secure than the Level 0 setting.
Level 2: “No access without explicit anonymous permissions”
This will deny all access for anonymous connections gaining access to the SAM or shares. This setting is not suggested, due to the impact it has on down level clients and applications that rely on anonymous connections.
A note about the level 2 access in Windows 2000 is that it is not designed for a mixed-mode domain. If this policy is set to 2 for a mixed mode domain, you will see problems with the following areas:
Windows 9x and Windows NT computers will not be able to establish a netlogon secure channel.
Windows NT trusted domains will not be able to establish a netlogon secure channel.
Users of Windows NT computers will not be able to change their passwords.
The browser service will fail on all computers where this level is set to 2.
How Windows 2003 protects against anonymous connections
When Server 2003 arrived, there were some distinct changes with regard to the control of anonymous connections. The old Windows 2000 anonymous GPO policy was still there (in a round about way), but it was accompanied with many more policy settings. The settings are welcomed, especially with the poor control over anonymous connections that Windows 2000 provided. The main problem is that the descriptions, documentation, and features of each setting were not very clear.
Figure 2 shows the anonymous control settings in a Group Policy Object from a Windows Server 2003 environment. The following is a list of each setting that directly controls anonymous connections, as well as a description as to what the policy controls.
Figure 2: Windows Server 2003 has better control over anonymous connections
Network access: Allow anonymous SID/Name translation – This policy controls an anonymous user’s capability of obtaining the SID of a user by knowing the name, or vice versa. With tools such as user2sid and sid2user, allowing this access can quickly give away the built-in administrators name.
Network access: Let everyone's permissions apply to anonymous users – This policy controls the access that anonymous users have once connected. In previous versions of Windows, anonymous users were provided with the SID for the Everyone group on the authentication token, allowing them to access everything that the Everyone group had access to. In Server 2003, the default configuration is to remove the Everyone group SID from the token generated for an anonymous user. This provides added protection for anonymous users attempting to access resources. Once this policy is set, anonymous users will only be able to access resources for which the anonymous user has been explicitly given permission.
Network access: Do not allow anonymous enumeration of SAM accounts – This policy is designed to negate anonymous connections from enumerating the list of user accounts from the local SAM (member servers and desktops) and Active Directory domain controllers.
Network access: Do not allow anonymous enumeration of SAM accounts and shares – This policy takes the previous policy one step further, by not only negating enumeration of user accounts from the SAM, but also shares on the targeted computer. The shares that are negated include standard, hidden, and hidden administrative shares.
There are other settings that control anonymous connections to specific shares, named pipes, etc. These are typically not as powerful as the settings described above in negating anonymous connectivity to a Windows computer.
I am sure I have your attention now! The question that must be on the tip of your tongue must be, “What can someone do if they gain anonymous access to my computer?” Of course the answer is “it depends!” It depends because it is based on not only what they acquire from your computer, but what they can do with it.
The basic information that someone can glean from your computer from an anonymous connection includes:
List of users from your computer, including Active Directory
List of groups from your computer, including Active Directory
SIDs for user accounts
User accounts for SIDs
List of shares from your computer
Account policies from your computer
NetBIOS name from your computer
Domain name that your computer is associated with
List of domains that your domain trusts
How to Make an Anonymous Connection
An anonymous connection is not something that you can make by accident. The syntax is not so simple that just anyone can make the connection. The point here is that if you have anonymous connections being made to your servers, someone is deliberately trying to gather information and you need to take immediate action.
The method that is mostly used to create an anonymous connection is to use the net use command. The net use command allows you to make a connection to a specific share on a server. The syntax would look something like this:
Net use \\10.10.10.10\ipc$ /u:”” “”
Here, you can replace the 10.10.10.10 IP address with the IP address of the server that you are accessing, or the NetBIOS name of the computer. In some instances, you can even get a list of all the computers that you could possibly connect to by running the following command:
Net view /domain:domainname
Once you have the computer names or IP addresses of the computers, you can attempt to make anonymous connections using the command above, or any “hacker” tool that exploits the anonymous access.
How Windows 2000 protected against anonymous connections
Microsoft has been aware of the anonymous access problem for quite some time. For Windows 2000, they implemented a Group Policy Object setting which allowed you to control how and if a user could create an anonymous connection to your computer. The setting is located in the Computer Configuration portion of any GPO. If you go below the Computer Configuration to the Windows Settings | Security Settings | Local Policies | Security Options, you will see the first GPO policy is related to anonymous connections, as shown in the figure.
Figure 1: GPO policy relating to anonymous connections
This policy can be configured to three different levels: 0, 1, and 2. These levels are displayed in the policy editor a bit differently, which is explained below. The Registry value that is being modified is HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous. Here is an explanation of the settings and what they protect against.
Level 0: “None. Rely on default permission”
This does not restrict any anonymous connections. This is a very insecure setting, but it is also the default on a Windows 2000 computer or domain.
Level 1: “Do not allow enumeration of SAM accounts or shares”
This is designed to not allow any anonymous access list the SAM or shares. However, there is a small problem here that this does not protect against all methods of accessing the SAM or shares from an anonymous connection. This setting is in essence no more secure than the Level 0 setting.
Level 2: “No access without explicit anonymous permissions”
This will deny all access for anonymous connections gaining access to the SAM or shares. This setting is not suggested, due to the impact it has on down level clients and applications that rely on anonymous connections.
A note about the level 2 access in Windows 2000 is that it is not designed for a mixed-mode domain. If this policy is set to 2 for a mixed mode domain, you will see problems with the following areas:
Windows 9x and Windows NT computers will not be able to establish a netlogon secure channel.
Windows NT trusted domains will not be able to establish a netlogon secure channel.
Users of Windows NT computers will not be able to change their passwords.
The browser service will fail on all computers where this level is set to 2.
How Windows 2003 protects against anonymous connections
When Server 2003 arrived, there were some distinct changes with regard to the control of anonymous connections. The old Windows 2000 anonymous GPO policy was still there (in a round about way), but it was accompanied with many more policy settings. The settings are welcomed, especially with the poor control over anonymous connections that Windows 2000 provided. The main problem is that the descriptions, documentation, and features of each setting were not very clear.
Figure 2 shows the anonymous control settings in a Group Policy Object from a Windows Server 2003 environment. The following is a list of each setting that directly controls anonymous connections, as well as a description as to what the policy controls.
Figure 2: Windows Server 2003 has better control over anonymous connections
Network access: Allow anonymous SID/Name translation – This policy controls an anonymous user’s capability of obtaining the SID of a user by knowing the name, or vice versa. With tools such as user2sid and sid2user, allowing this access can quickly give away the built-in administrators name.
Network access: Let everyone's permissions apply to anonymous users – This policy controls the access that anonymous users have once connected. In previous versions of Windows, anonymous users were provided with the SID for the Everyone group on the authentication token, allowing them to access everything that the Everyone group had access to. In Server 2003, the default configuration is to remove the Everyone group SID from the token generated for an anonymous user. This provides added protection for anonymous users attempting to access resources. Once this policy is set, anonymous users will only be able to access resources for which the anonymous user has been explicitly given permission.
Network access: Do not allow anonymous enumeration of SAM accounts – This policy is designed to negate anonymous connections from enumerating the list of user accounts from the local SAM (member servers and desktops) and Active Directory domain controllers.
Network access: Do not allow anonymous enumeration of SAM accounts and shares – This policy takes the previous policy one step further, by not only negating enumeration of user accounts from the SAM, but also shares on the targeted computer. The shares that are negated include standard, hidden, and hidden administrative shares.
There are other settings that control anonymous connections to specific shares, named pipes, etc. These are typically not as powerful as the settings described above in negating anonymous connectivity to a Windows computer.
Thursday, December 22, 2005
Active Directory Troubleshooting Part 1
http://www.windowsnetworking.com/pages/article_p.asp?id=464
Monitoring and Troubleshooting Active Directory Replication
Replication may be defined as a duplicate copy of similar data on the same or a different platform or system. When using a directory service such as Active Directory, the directory database is carried by all domain controllers so that when you want to contact a domain controller for use, there is always a local copy local for use so that requests do not have to be sent over the wide area network (WAN). Replication for Active Directory operates within the directory service component of the security subsystem. This component is called Ntdsa.dll and is accessed through the Lightweight Directory Access Protocol (LDAP). Ntdsa.dll runs as a part of the local security authority (LSA), which runs as Lsass.exe. Updates are transported over Internet Protocol (IP) by the remote procedure call (RPC) protocol. The Simple Mail Transfer Protocol (SMTP) is also available for use as well, although it’s more common to see RPC over IP used.
When considering Active Directory, replication takes place and a copy of the Active Directory database is stored and updated on all other participating domain controllers on your network and in a perfect world, each copy of the database is the same and all domain controllers are synchronized. If this happens, then all your domain controllers are synchronized with an exact duplicate copy of the Active Directory database. When you install Active Directory, for the most part even if all the default settings are chosen, the replication process from domain controller to domain controller is automatic and practically transparent. For the most part, domain controllers handle the replication processes without advanced configuration and most times, without a problem.
In figure 1, you can see a common network (2 sites connected via a WAN link) with a domain controller in each location. Again, the benefit of having a domain controller local to your PC’s at each network segment is to have requests made of the domain controller kept local to the PC’s in need of its services to speed up requests (by keeping them local) or in case of disaster recovery, which could happen if the WAN link drops, the local PCs can still find a local domain controller to use. Keeping traffic off the wide area network (WAN) and containing it to the local area network (LAN) is the best design practice you can implement.
Figure 1: A Common Wide Area Network (WAN)
As a systems administrator, you should still consider that Active Directory performance still needs to be monitored and analyzed. The health and maximized performance of Active Directory depends on a smooth replication process. If you are having problems with replication, you will know not only from blatant logging in your Event Viewer, but from poor performance as well. Many times, you cannot stop every problem from occurring, but hopefully after reading this article, you will be better equipped to handle issues and keep your network as optimized as possible to handle the traffic traversing it.
Consider a common problem such as a failed network link. In figure 2, you see that the main wide area network link has been broken.
Figure 2: A Failed Network Link
ISP’s and telecom service providers occasionally have problems and service can be interrupted. This of course stops the communication between domain controllers, therefore also severing the replication process. This can prevent the synchronization of information between domain controllers and possibly cause corruption and/or other problems.
A good way to make sure that this doesn’t happen is to set up a backup link (such as ISDN as seen in figure 2). ISDN (Integrated Services Digital Networks) is a digital WAN technology used to facilitate connections between sites. More commonly used today for disaster recovery, ISDN still has a place in today’s marketplace. Although still used, you don’t have to limit yourself to any technology when it comes to backup links, you can use a fractional or full T1, a DSL line, or any other technology that allows you to have redundancy in your links. The goal is to have redundant links to keep your domain controllers in constant communication with each other so that the Active Directory database stays synchronized and healthy. A common symptom of replication problems is that information is not updated on some or all domain controllers. For example, a systems administrator creates a user account on one domain controller, but the changes are not propagated to other domain controllers. In most environments, this is a potentially serious problem because it affects network security and can prevent authorized users from accessing the resources they require. You can take several steps to troubleshoot Active Directory replication; each of these is discussed in the following sections.
Verifying Network Connectivity
In order for replication to work properly in distributed environments, you must have network connectivity. Although ideally all domain controllers would be connected by high-speed and redundant LAN or WAN links, this is rarely the case for larger deployments and for most companies that utilize slow WAN links that aren’t recoverable from a disaster. Always make sure your network topology is documented and tested to ensure that it’s connected. There are many tools you can use to verify connectivity such as Ping and Tracert which come with just about every operating system ever created that runs TCP/IP.
In real world deployments, analog/dial-up connections and slow connections are common. If you have verified that your replication topology is set up properly, you should confirm that your servers are able to communicate over the network. Problems such as a failed dial-up connection attempt can prevent important Active Directory information from being replicated. Learn how to use ping and other ICMP based protocol troubleshooting tools in the links section at the end of this article.
Verifying Router and Firewall Configurations
When building a secure network, most times controls are placed on network devices to filter the traffic going from place to place. The most commonly used tool to control traffic is a Firewall. A router or any other device that utilizes a firewall feature set, or some other form of Access Control that stops access to and from other hosts connected can also be used. A firewall is usually dedicated to only protecting the perimeter so its been designed to do that, do not assume that the use of a firewall stops any risk of you being attacked, it only minimizes that risk.
Firewalls are used to restrict the types of traffic that can be transferred between networks. Their main use is to increase security by preventing unauthorized users from transferring information. In some cases, company firewalls may block the types of network access that must be available in order for Active Directory replication to occur. For example, if a specific router or firewall prevents data from being transferred using SMTP, replication that uses this protocol will fail.
Network Ports Used by Active Directory Replication
RPC replication uses dynamic port mapping as per the default setting. When you need to connect to an RPC endpoint during Active Directory replication, RPC uses TCP port 135. RPC on the client contacts the RPC endpoint mapper on the server at a well-known port and RPC randomly allocates high TCP ports from port 1024 to 65536. Because of this configuration, a client will never need to know what port to use for Active Directory replication; it will just take place seamlessly. There are also other ports assigned for Active Directory replication. There are as follows:
Protocol
Port
LDAP
udp 389
tcp 389
LDAP (SSL)
udp 636
tcp 636
Kerberos
udp 88
tcp 88
DNS
udp 53
tcp 53
SMB over IP
udp 445
tcp 445
Global Catalog Server
tcp 3269
tcp 3268
Examining the Event Logs:
Errors, if they occur, will show up in the Event Viewer logs. At the end of this article, I have placed a link to the Microsoft Website so that you can learn how to use the Event Viewer. The Event Viewer can be very helpful when trying to locate and resolve a replication problem. Many errors are reported to the Event Viewer for your review.
Whenever an error in the replication configuration occurs, the computer writes events to the Directory Service and File Replication Service (FRS) event logs. By using the Event Viewer administrative tool, you can quickly and easily view the details associated with any problems in replication. For example, if one domain controller is not able to communicate with another to transfer changes, a log entry is created.
You may receive events such as:
Event ID 1311 in the directory service log
Event ID 1265 with error "DNS Lookup Failure" or "RPC server is unavailable" in the directory service log. Or, received "DNS Lookup Failure" or "Target account name is incorrect" from the repadmin command
Event ID 1265 "Access denied," in directory service log. Or, received "Access denied" from the repadmin command
Note:
The link at the end of the article covers the explanation of these specific errors and more.
Verifying Site Links
Before domain controllers in different sites can communicate with each other, the sites must be connected by site links. If replication between sites is not occurring properly, verify that the proper site links are in place. Verify your site links by using the Replication diagnostics utility (Repadmin.exe). Use this tool to verify correct site links and to display inbound and outbound connections. You can also use it to display the replication queue. You can get the tool by using the link at the end of this article.
Verifying That Information Is Synchronized
It’s often easy to forget to perform manual checks regarding the replication of Active Directory information. One of the reasons for this is that Active Directory domain controllers have their own read/write copies of the Active Directory database. Therefore, if connectivity does not exist, you will not encounter failures while creating new objects.
It is important to periodically verify that objects have been synchronized between domain controllers. This process might be as simple as logging on to a different domain controller and looking at the objects within a specific OU. This manual check, although it might be tedious, can prevent inconsistencies in the information stored on domain controllers, which, over time, can become an administration and security nightmare.
Verifying Authentication Scenarios
A common replication configuration issue occurs when clients are forced to authenticate across slow network connections. The primary symptom of the problem is that users complain about the amount of time it takes them to log on to the Active Directory (especially during times of high volume of authentications, such as at the beginning of the workday). Usually, you can alleviate this problem by using additional domain controllers or reconfiguring the site topology. A good way to test this is to consider the possible scenarios for the various clients that you support. Often, walking through a configuration, such as “A client in Domain A is trying to authenticate using a domain controller in Domain B, which is located across a very slow WAN connection,” can be helpful in pinpointing potential problem areas.
Verifying the Replication Topology
The Active Directory Sites and Services tool allows you to verify that a replication topology is logically consistent. You can quickly and easily perform this task by right-clicking the NTDS Settings within a Server object and choosing All Tasks => Check Replication Topology. If any errors are present, a dialog box alerts you to the problem.
You can verify the Active Directory topology using the Active Directory Sites and Services tool.
Besides for ensuring that replication always continues, you can also learn how to monitor it as well. There are several ways in which you can monitor the behavior of Active Directory replication and troubleshoot the process if problems occur. In our next article we will look at the replication monitor and part III of this article will cover the system monitor.
http://www.windowsnetworking.com/pages/article_p.asp?id=464
Monitoring and Troubleshooting Active Directory Replication
Replication may be defined as a duplicate copy of similar data on the same or a different platform or system. When using a directory service such as Active Directory, the directory database is carried by all domain controllers so that when you want to contact a domain controller for use, there is always a local copy local for use so that requests do not have to be sent over the wide area network (WAN). Replication for Active Directory operates within the directory service component of the security subsystem. This component is called Ntdsa.dll and is accessed through the Lightweight Directory Access Protocol (LDAP). Ntdsa.dll runs as a part of the local security authority (LSA), which runs as Lsass.exe. Updates are transported over Internet Protocol (IP) by the remote procedure call (RPC) protocol. The Simple Mail Transfer Protocol (SMTP) is also available for use as well, although it’s more common to see RPC over IP used.
When considering Active Directory, replication takes place and a copy of the Active Directory database is stored and updated on all other participating domain controllers on your network and in a perfect world, each copy of the database is the same and all domain controllers are synchronized. If this happens, then all your domain controllers are synchronized with an exact duplicate copy of the Active Directory database. When you install Active Directory, for the most part even if all the default settings are chosen, the replication process from domain controller to domain controller is automatic and practically transparent. For the most part, domain controllers handle the replication processes without advanced configuration and most times, without a problem.
In figure 1, you can see a common network (2 sites connected via a WAN link) with a domain controller in each location. Again, the benefit of having a domain controller local to your PC’s at each network segment is to have requests made of the domain controller kept local to the PC’s in need of its services to speed up requests (by keeping them local) or in case of disaster recovery, which could happen if the WAN link drops, the local PCs can still find a local domain controller to use. Keeping traffic off the wide area network (WAN) and containing it to the local area network (LAN) is the best design practice you can implement.
Figure 1: A Common Wide Area Network (WAN)
As a systems administrator, you should still consider that Active Directory performance still needs to be monitored and analyzed. The health and maximized performance of Active Directory depends on a smooth replication process. If you are having problems with replication, you will know not only from blatant logging in your Event Viewer, but from poor performance as well. Many times, you cannot stop every problem from occurring, but hopefully after reading this article, you will be better equipped to handle issues and keep your network as optimized as possible to handle the traffic traversing it.
Consider a common problem such as a failed network link. In figure 2, you see that the main wide area network link has been broken.
Figure 2: A Failed Network Link
ISP’s and telecom service providers occasionally have problems and service can be interrupted. This of course stops the communication between domain controllers, therefore also severing the replication process. This can prevent the synchronization of information between domain controllers and possibly cause corruption and/or other problems.
A good way to make sure that this doesn’t happen is to set up a backup link (such as ISDN as seen in figure 2). ISDN (Integrated Services Digital Networks) is a digital WAN technology used to facilitate connections between sites. More commonly used today for disaster recovery, ISDN still has a place in today’s marketplace. Although still used, you don’t have to limit yourself to any technology when it comes to backup links, you can use a fractional or full T1, a DSL line, or any other technology that allows you to have redundancy in your links. The goal is to have redundant links to keep your domain controllers in constant communication with each other so that the Active Directory database stays synchronized and healthy. A common symptom of replication problems is that information is not updated on some or all domain controllers. For example, a systems administrator creates a user account on one domain controller, but the changes are not propagated to other domain controllers. In most environments, this is a potentially serious problem because it affects network security and can prevent authorized users from accessing the resources they require. You can take several steps to troubleshoot Active Directory replication; each of these is discussed in the following sections.
Verifying Network Connectivity
In order for replication to work properly in distributed environments, you must have network connectivity. Although ideally all domain controllers would be connected by high-speed and redundant LAN or WAN links, this is rarely the case for larger deployments and for most companies that utilize slow WAN links that aren’t recoverable from a disaster. Always make sure your network topology is documented and tested to ensure that it’s connected. There are many tools you can use to verify connectivity such as Ping and Tracert which come with just about every operating system ever created that runs TCP/IP.
In real world deployments, analog/dial-up connections and slow connections are common. If you have verified that your replication topology is set up properly, you should confirm that your servers are able to communicate over the network. Problems such as a failed dial-up connection attempt can prevent important Active Directory information from being replicated. Learn how to use ping and other ICMP based protocol troubleshooting tools in the links section at the end of this article.
Verifying Router and Firewall Configurations
When building a secure network, most times controls are placed on network devices to filter the traffic going from place to place. The most commonly used tool to control traffic is a Firewall. A router or any other device that utilizes a firewall feature set, or some other form of Access Control that stops access to and from other hosts connected can also be used. A firewall is usually dedicated to only protecting the perimeter so its been designed to do that, do not assume that the use of a firewall stops any risk of you being attacked, it only minimizes that risk.
Firewalls are used to restrict the types of traffic that can be transferred between networks. Their main use is to increase security by preventing unauthorized users from transferring information. In some cases, company firewalls may block the types of network access that must be available in order for Active Directory replication to occur. For example, if a specific router or firewall prevents data from being transferred using SMTP, replication that uses this protocol will fail.
Network Ports Used by Active Directory Replication
RPC replication uses dynamic port mapping as per the default setting. When you need to connect to an RPC endpoint during Active Directory replication, RPC uses TCP port 135. RPC on the client contacts the RPC endpoint mapper on the server at a well-known port and RPC randomly allocates high TCP ports from port 1024 to 65536. Because of this configuration, a client will never need to know what port to use for Active Directory replication; it will just take place seamlessly. There are also other ports assigned for Active Directory replication. There are as follows:
Protocol
Port
LDAP
udp 389
tcp 389
LDAP (SSL)
udp 636
tcp 636
Kerberos
udp 88
tcp 88
DNS
udp 53
tcp 53
SMB over IP
udp 445
tcp 445
Global Catalog Server
tcp 3269
tcp 3268
Examining the Event Logs:
Errors, if they occur, will show up in the Event Viewer logs. At the end of this article, I have placed a link to the Microsoft Website so that you can learn how to use the Event Viewer. The Event Viewer can be very helpful when trying to locate and resolve a replication problem. Many errors are reported to the Event Viewer for your review.
Whenever an error in the replication configuration occurs, the computer writes events to the Directory Service and File Replication Service (FRS) event logs. By using the Event Viewer administrative tool, you can quickly and easily view the details associated with any problems in replication. For example, if one domain controller is not able to communicate with another to transfer changes, a log entry is created.
You may receive events such as:
Event ID 1311 in the directory service log
Event ID 1265 with error "DNS Lookup Failure" or "RPC server is unavailable" in the directory service log. Or, received "DNS Lookup Failure" or "Target account name is incorrect" from the repadmin command
Event ID 1265 "Access denied," in directory service log. Or, received "Access denied" from the repadmin command
Note:
The link at the end of the article covers the explanation of these specific errors and more.
Verifying Site Links
Before domain controllers in different sites can communicate with each other, the sites must be connected by site links. If replication between sites is not occurring properly, verify that the proper site links are in place. Verify your site links by using the Replication diagnostics utility (Repadmin.exe). Use this tool to verify correct site links and to display inbound and outbound connections. You can also use it to display the replication queue. You can get the tool by using the link at the end of this article.
Verifying That Information Is Synchronized
It’s often easy to forget to perform manual checks regarding the replication of Active Directory information. One of the reasons for this is that Active Directory domain controllers have their own read/write copies of the Active Directory database. Therefore, if connectivity does not exist, you will not encounter failures while creating new objects.
It is important to periodically verify that objects have been synchronized between domain controllers. This process might be as simple as logging on to a different domain controller and looking at the objects within a specific OU. This manual check, although it might be tedious, can prevent inconsistencies in the information stored on domain controllers, which, over time, can become an administration and security nightmare.
Verifying Authentication Scenarios
A common replication configuration issue occurs when clients are forced to authenticate across slow network connections. The primary symptom of the problem is that users complain about the amount of time it takes them to log on to the Active Directory (especially during times of high volume of authentications, such as at the beginning of the workday). Usually, you can alleviate this problem by using additional domain controllers or reconfiguring the site topology. A good way to test this is to consider the possible scenarios for the various clients that you support. Often, walking through a configuration, such as “A client in Domain A is trying to authenticate using a domain controller in Domain B, which is located across a very slow WAN connection,” can be helpful in pinpointing potential problem areas.
Verifying the Replication Topology
The Active Directory Sites and Services tool allows you to verify that a replication topology is logically consistent. You can quickly and easily perform this task by right-clicking the NTDS Settings within a Server object and choosing All Tasks => Check Replication Topology. If any errors are present, a dialog box alerts you to the problem.
You can verify the Active Directory topology using the Active Directory Sites and Services tool.
Besides for ensuring that replication always continues, you can also learn how to monitor it as well. There are several ways in which you can monitor the behavior of Active Directory replication and troubleshoot the process if problems occur. In our next article we will look at the replication monitor and part III of this article will cover the system monitor.
http://www.windowsnetworking.com/pages/article_p.asp?id=464
Radius and TACACS
One of the solutions that was designed to accommodate the remote worker is that of RADIUS. Remote Authentication Dial-In User Service is what the acronym actually stands for. It is actually fairly descriptive as that is pretty much what it is used for. The worker will remotely authenticate for access to that remote network. I have previously mentioned that I like to map protocols before to the OSI Reference Model. This helps one visualize just what protocols belong where in the grand scheme of things. In the OSI model RADIUS fits into the application layer. This protocol is no exception either to the client/server model. A client will log into the RADIUS server and supply the required credentials. Also RADIUS uses UDP as a transport protocol to ferry about its information.
Like many well known protocols RADIUS has some well known ports that it is normally configured to be listening on. They are port 1812 and port 1813 with port 1813 being used for RADIUS accounting. Those ports are also RFC compliant, but what does RFC compliant actually mean? Well when the designers of RADIUS were sitting around talking about the design specifications for RADIUS they decided that they would make RADIUS use ports 1812 and 1813. The various design considerations were eventually all consolidated into what is called an RFC. After a period of time that RFC was accepted and thusly the ports of 1812 and 1813 were then called RFC compliant, as they were included in the original design of it.
I want details!
The devil is always in the details, and if you want details it is always best to go to the definitive source. In our case that would be RFC 2138 which deals with RADIUS itself and contains all of the details about it. Seen as most people break out into hives if they think of reading an RFC I will summarize a few important details for you. One of the biggest things to realize about RADIUS is that it will support various authentication methods. Notably, you can use PPP, PAP, and CHAP to name most of them. If you are familiar with Cisco gear or are in charge of supporting the routers and switches from them, then you are no doubt familiar with the various authentication methods offered by RADIUS.
Now once a user has supplied the required username and password combination and the RADIUS server receives it, it will do one of a couple of things. The RADIUS server will check its database for the received credentials and based on that, either reject the session or allow it. Further to the username and password combination, the RADIUS server can also check for validity by the port number. Typically RADIUS works as follows;
Access-Request: where the user sends their credentials to the server
Acess-Challenge: where the server sends a challenge and the user must respond
Based on the above access control the user is either authenticated or rejected. RADIUS itself, as mentioned earlier, uses UDP as its transport protocol, and that was decided during the initial design considerations for RADIUS. Using UDP has its advantages, notably there being less overhead and speed. This and other reasons was the driving force behind the choice of this transport protocol over TCP and its connection oriented design. Lastly, we should also realize that, like many application layer protocols, RADIUS has codes that were written into its core functionality. These codes deal with the access, accounting and status of RADIUS be it client or server. For further reading on this protocol I would suggest reading the above noted hyperlink for RFC 2138.
TACACS and TACACS+
Terminal Access Controller Access Control System or TACACS is similar to RADIUS and is used to regulate access to the network. One of the biggest differences between TACACS and RADIUS is that TACACS primarily uses TCP for its transport protocol needs vice the UDP that RADIUS will use. There are also three versions of TACACS with TACACS+ being the most recent. It is important to note that TACACS+ is not backwards compatible with the other earlier versions. This protocol is also an application layer protocol and observes the client/server model. Seen as TACACS+ is also a well known protocol it stands to reason that there is also a well known port associated with this activity, which is TCP port 49. That being said XTACACS does use UDP. There is always the exception to the rule!
Other notable differences between RADIUS and TACACS+ are that RADIUS only encrypts the password in the access request packet that is sent to the RADIUS server. TACACS+ on the other hand will encrypt the entire packet body, but will leave the TACACS+ header intact. TACACS+ does have weaknesses though, which can be exploited by a determined attacker. It is vulnerable to “birthday attacks” in which two messages use the same hash function and packet sniffing to mention a few.
Like many well known protocols RADIUS has some well known ports that it is normally configured to be listening on. They are port 1812 and port 1813 with port 1813 being used for RADIUS accounting. Those ports are also RFC compliant, but what does RFC compliant actually mean? Well when the designers of RADIUS were sitting around talking about the design specifications for RADIUS they decided that they would make RADIUS use ports 1812 and 1813. The various design considerations were eventually all consolidated into what is called an RFC. After a period of time that RFC was accepted and thusly the ports of 1812 and 1813 were then called RFC compliant, as they were included in the original design of it.
I want details!
The devil is always in the details, and if you want details it is always best to go to the definitive source. In our case that would be RFC 2138 which deals with RADIUS itself and contains all of the details about it. Seen as most people break out into hives if they think of reading an RFC I will summarize a few important details for you. One of the biggest things to realize about RADIUS is that it will support various authentication methods. Notably, you can use PPP, PAP, and CHAP to name most of them. If you are familiar with Cisco gear or are in charge of supporting the routers and switches from them, then you are no doubt familiar with the various authentication methods offered by RADIUS.
Now once a user has supplied the required username and password combination and the RADIUS server receives it, it will do one of a couple of things. The RADIUS server will check its database for the received credentials and based on that, either reject the session or allow it. Further to the username and password combination, the RADIUS server can also check for validity by the port number. Typically RADIUS works as follows;
Access-Request: where the user sends their credentials to the server
Acess-Challenge: where the server sends a challenge and the user must respond
Based on the above access control the user is either authenticated or rejected. RADIUS itself, as mentioned earlier, uses UDP as its transport protocol, and that was decided during the initial design considerations for RADIUS. Using UDP has its advantages, notably there being less overhead and speed. This and other reasons was the driving force behind the choice of this transport protocol over TCP and its connection oriented design. Lastly, we should also realize that, like many application layer protocols, RADIUS has codes that were written into its core functionality. These codes deal with the access, accounting and status of RADIUS be it client or server. For further reading on this protocol I would suggest reading the above noted hyperlink for RFC 2138.
TACACS and TACACS+
Terminal Access Controller Access Control System or TACACS is similar to RADIUS and is used to regulate access to the network. One of the biggest differences between TACACS and RADIUS is that TACACS primarily uses TCP for its transport protocol needs vice the UDP that RADIUS will use. There are also three versions of TACACS with TACACS+ being the most recent. It is important to note that TACACS+ is not backwards compatible with the other earlier versions. This protocol is also an application layer protocol and observes the client/server model. Seen as TACACS+ is also a well known protocol it stands to reason that there is also a well known port associated with this activity, which is TCP port 49. That being said XTACACS does use UDP. There is always the exception to the rule!
Other notable differences between RADIUS and TACACS+ are that RADIUS only encrypts the password in the access request packet that is sent to the RADIUS server. TACACS+ on the other hand will encrypt the entire packet body, but will leave the TACACS+ header intact. TACACS+ does have weaknesses though, which can be exploited by a determined attacker. It is vulnerable to “birthday attacks” in which two messages use the same hash function and packet sniffing to mention a few.
Tuesday, December 13, 2005
Windows System Errors
System error 5 - Access is denied
This is a permission issue. If the net view command fails with a "System error 5 has occurred. Access is denied." message, 1) make sure you are logged on using an account that has permission to view the shares on the remote computer.
2) Need to cache credential: logon the same username and password on both computers or use net net use \\computername /user:username command.
3) Make sure the Netlogon service is running.
System error 8 - Not enough storage is available to process this command
or System error 234 - More data is available.
Symptoms: If you attempt to start the server service manually, the following errors may be displayed: System error 234 has occurred. More data is available. Or system error 8 has occurred. Not enough storage is available to process this command. The event viewer shows "Event ID: 7023. Description: The Server service terminated with the following error: More data is available. Or Event ID: 7001. Description: The Net Logon service depends on the Server service which failed to start because of the following error: More data is available.
Resolutions: 1) apply (or reapply) the latest Windows NT Service pack.
2) remove any unnecessary entries from this value in the registry, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer \Parameters\NullSessionPipes
System error 51 has occurred - The remote computer is not available
Symptoms: You may receive "System error 51 has occurred. The remote computer is not available" when using net use to map the computer drive.
Resolutions: 1. Make sure server service is running on the remote computer.
2. Enable file and printer sharing.
System error 52 - You were not connected because a duplicate name exists on the network.
Symptoms: you can ping a host but not net view it. When using net view \\hostname, you get system error 52 - a duplicate name exists on the network.
Resolutions: there are two host names or alias name (cname) are pointed to the same IP. 1) check the WINS records. 2) check DNS records. 3) Go to System in the Control Panel to change the computer name and try again.
System error 53 - The network path was not found.
Symptom: when using net view \\ip or \\computername, you get system error 53.
Resolutions: 1) if it is domain environment, check your WINS; 2) if it is peer-to-peer workgroup, enable NetBIOS over TCP/IP; 3) make sure the machine is running; 4) make sure file and Printer Share enabled on remote computer; 5) make sure client for ms networks is enabled on local computer; 6) make sure you type the correct name.
Still need help, contact consultant at http://www.ChicagoTech.net for the tech support.
System error 67 - The network name cannot be found
Symptom: When using net view \\computer, you may receive above error message.
Resolution: make sure you type the correct computer name or shared name.
System error 85 has occurred. The local device name is already in use
Cause: net use /persistent:yes is default settings for NT and win2000/XP. If you have mapped some network drives and check the reconnect at logon, or your network uses logon script to map network drives, the mapped network drives may show red Xs. If you enable echo and pause the logon script or if using net use to map the same drive manually, you may get "System error 85 has occurred. The local device name is already in use." One thing you may want to try is using net use /persistent:no, for example, net use i: \\servername\folder /persistent:no.
System error 1219 has occurred - The credentials supplied conflict with an existing set of credentials
Symptoms: 1) When you log on to a domain from w2k client; 2) when attempting to join a domain, you may receive the following error message: The credentials supplied conflict with an existing set of credentials.
Resolutions: This may cause because of attempting to make two or more connections to the same server using two or more sets of credentials
1. Go to windows explorer and disconnect all network drives. Then re-logon.
2. Delete the profile or copy another profile. Note: you may lost all settings and data in My Documents when deleting or copying profile.
3. If solution 1 and 2 doesn't work, try this: 1) Log on as an administrator at any workstation and run regedt32. 2) Select HKEY_USERS, but do not open. 3) From the Registry menu, click Load Hive. 4) This will bring up a Load Hive dialog box. Locate the Ntuser.dat file for the user with the errors. Select the Ntuser.dat and click Open. You may enter any string for the Key Name. Use TEST for ease of use pertaining to the remainder of this article. 5) Locate the Username value under the following key in the registry: HKEY_USERS\TEST\Network\Username. 6) Delete the string for Username (leaving it blank is sufficient). 7) Select the TEST hive that you previously loaded, click the Registry menu, and then click Unload Hive. 8) Quit Registry Editor.
4. If you get this message when joining the domain, make sure 1) you have delete the computer from AD; 2) delete it from DNS; 3) delete it from WINS.
System error 1231 has occurred. The network location cannot be reached.
Symptom: When using net view \\computername, you may receive System error 1231.
Resolutions: 1) make sure Client for MS Networks is enabled, 2) make sure you have permission to access it.
System Error 1240 - The account is not authorized to login from this station.
Symptoms: 1. You may get the system error 1240 when using net view \\remotecomputer'
2. “Workgroup_name is not accessible… Account is Not Authorized to Log In to this Station” when attempting to browse the workgroup from a networking computer.
Resolutions: 1. Use Regedit to enable unencrypted (plain text) passwords for the SMB client.
2. Enable Send Unencrypted Password to Connect to 3rd Party SMB Servers under Local Security Policy.
3. Set the following policies as showing:
Digitally sign client communications (always) - disabled
Digitally sign server communications (always)- disabled
Digitally sign server communications (when possible) - disabled
LAN Manager Authentication Level set to Send LM and NTLM - use NTLMv2 session security if negotiated - (default) send LM & NTLM responses
Secure channel: Digitally encrypt or sign secure channel data (always) - disabled
Secure channel: Require strong (Windows 2000 or later) session key - disabled
4. Contact the third-party SMB server manufacturer if you have a third-party SMB server, such as DEC Pathworks, Samba or Linux.
System error 1311 - There are currently no logon servers available to service the logon request
Symptoms: The primary purpose of logging on with cached credentials is to enable you to access the local workstation. However, if you have logged on by cached credentials, you may be unable to access network resources because you have not been authenticated. For example 1) after you log on to a w2k/xp laptop by using cached credentials, you may be unable to access the network resources. This issue is commonly experienced by laptop users whose computer resides in a Windows Server domain and who log on to the computer by using cached credentials prior to being able to establish a remote access connection. 2) You log on to a w2k/xp laptop with a domain logon option in a workgroup network. After you establish the connection and you try to map the network drives, the operation may be unsuccessful, and you may receive the following error message: "System Error: (1311) There are currently no logon servers available to service the logon request."
Resolutions: To authenticate the cached credentials, 1) if it is w2k/xp, use net command, for example, net use \\servername\sharename /user:username. 2) if xp, open Windows Explorer>Tools>Map Network Drive. Click Connect using a different user name, enter the username and password.
System error 1326 has occurred - Logon failure: unknown user name or bad password.
Symptom: when using net use to map a network drive, you may receive "System error 1326 has occurred. Logon failure: unknown user name or bad password." message.
Resolutions: 1) create a user account on remote computer; 2) need to enable the guest account; 3) make sure the remote computer doesn't use auto-logon and blank password; 4) make sure you have a folder or drive shared on the remote computer. 5) use net use \\servername /user:username command. Make sure you type correct command (e.g. use net use \\servername \user:username will get this error too)
System error 1331 has occurred - Logon failure: account current disable
Symptom: When using net use \\computername command, you may receive above error message.
Resolutions: this is cache credentials issue. To fix this problem and cache the credentials, use net use \\computername /user:username command.
System error 1385 has occurred - Logon failure: the user has not been granted the requested logon type at this computer
Symptoms: When using net use \\remotecomouter\ahredname, you may receive above message.
Resolution: The users do not have permission to connect to the remote computer. To resolve this problem: on the remote computer, select Administrative Tools>Local Security Settings>Local Policies>User Rights Assignment, right-click on Access this computer from the network>Properties>Add Users or Groups, add everyone or any users you want to be able to access the computer from the network.
System error 1396 has occurred - Logon Failure: The target account name is incorrect.
Symptoms: 1. when using net use, you may receive above message.
2. when using net view \\hostname, you may receive "System error 5 has occurred. Access is denied.". However, net view \\ip works fine.
3. You may receive above error while running logon script.
Causes: 1. SPN for the domain that is hosting the replica has not been propagated.
2. Incorrect target account name or the server is not online.
3. If you have DFS, make sure the DFSRoot is available.
Refer to RL060704
System error 6118 has occurred. The list of servers for this workgroup is not currently available
SYMPTOMS: 1) After enabling ICS/ICF, you can't see any computes on My Network places. If you try, you may get "workgroup is not accessible". 2) If you use the net view command, you may receive "System error 6118 has occurred. The list of servers for this workgroup is not currently available." message.
Resolutions:
1) This behavior can occur if you enable the ICF that will closes the ports for file sharing by default. To open these ports, right-click the network connection that is firewall protected> Properties>Advanced>Settings>Service Tab>Add, Enter 127.0.0.1) for the required Internet Protocol (IP) number. Enter UDP ports from 135 through 139, and TCP ports from 135 through 139 one by one (the external and internal port numbers should be identical).
2) This may occur if the workgroup name and the domain name are the different.
3) No master browser. Starting Computer Browser Service on one of w2k/xp computers should fix the problem
This is a permission issue. If the net view command fails with a "System error 5 has occurred. Access is denied." message, 1) make sure you are logged on using an account that has permission to view the shares on the remote computer.
2) Need to cache credential: logon the same username and password on both computers or use net net use \\computername /user:username command.
3) Make sure the Netlogon service is running.
System error 8 - Not enough storage is available to process this command
or System error 234 - More data is available.
Symptoms: If you attempt to start the server service manually, the following errors may be displayed: System error 234 has occurred. More data is available. Or system error 8 has occurred. Not enough storage is available to process this command. The event viewer shows "Event ID: 7023. Description: The Server service terminated with the following error: More data is available. Or Event ID: 7001. Description: The Net Logon service depends on the Server service which failed to start because of the following error: More data is available.
Resolutions: 1) apply (or reapply) the latest Windows NT Service pack.
2) remove any unnecessary entries from this value in the registry, HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer \Parameters\NullSessionPipes
System error 51 has occurred - The remote computer is not available
Symptoms: You may receive "System error 51 has occurred. The remote computer is not available" when using net use to map the computer drive.
Resolutions: 1. Make sure server service is running on the remote computer.
2. Enable file and printer sharing.
System error 52 - You were not connected because a duplicate name exists on the network.
Symptoms: you can ping a host but not net view it. When using net view \\hostname, you get system error 52 - a duplicate name exists on the network.
Resolutions: there are two host names or alias name (cname) are pointed to the same IP. 1) check the WINS records. 2) check DNS records. 3) Go to System in the Control Panel to change the computer name and try again.
System error 53 - The network path was not found.
Symptom: when using net view \\ip or \\computername, you get system error 53.
Resolutions: 1) if it is domain environment, check your WINS; 2) if it is peer-to-peer workgroup, enable NetBIOS over TCP/IP; 3) make sure the machine is running; 4) make sure file and Printer Share enabled on remote computer; 5) make sure client for ms networks is enabled on local computer; 6) make sure you type the correct name.
Still need help, contact consultant at http://www.ChicagoTech.net for the tech support.
System error 67 - The network name cannot be found
Symptom: When using net view \\computer, you may receive above error message.
Resolution: make sure you type the correct computer name or shared name.
System error 85 has occurred. The local device name is already in use
Cause: net use /persistent:yes is default settings for NT and win2000/XP. If you have mapped some network drives and check the reconnect at logon, or your network uses logon script to map network drives, the mapped network drives may show red Xs. If you enable echo and pause the logon script or if using net use to map the same drive manually, you may get "System error 85 has occurred. The local device name is already in use." One thing you may want to try is using net use /persistent:no, for example, net use i: \\servername\folder /persistent:no.
System error 1219 has occurred - The credentials supplied conflict with an existing set of credentials
Symptoms: 1) When you log on to a domain from w2k client; 2) when attempting to join a domain, you may receive the following error message: The credentials supplied conflict with an existing set of credentials.
Resolutions: This may cause because of attempting to make two or more connections to the same server using two or more sets of credentials
1. Go to windows explorer and disconnect all network drives. Then re-logon.
2. Delete the profile or copy another profile. Note: you may lost all settings and data in My Documents when deleting or copying profile.
3. If solution 1 and 2 doesn't work, try this: 1) Log on as an administrator at any workstation and run regedt32. 2) Select HKEY_USERS, but do not open. 3) From the Registry menu, click Load Hive. 4) This will bring up a Load Hive dialog box. Locate the Ntuser.dat file for the user with the errors. Select the Ntuser.dat and click Open. You may enter any string for the Key Name. Use TEST for ease of use pertaining to the remainder of this article. 5) Locate the Username value under the following key in the registry: HKEY_USERS\TEST\Network\Username. 6) Delete the string for Username (leaving it blank is sufficient). 7) Select the TEST hive that you previously loaded, click the Registry menu, and then click Unload Hive. 8) Quit Registry Editor.
4. If you get this message when joining the domain, make sure 1) you have delete the computer from AD; 2) delete it from DNS; 3) delete it from WINS.
System error 1231 has occurred. The network location cannot be reached.
Symptom: When using net view \\computername, you may receive System error 1231.
Resolutions: 1) make sure Client for MS Networks is enabled, 2) make sure you have permission to access it.
System Error 1240 - The account is not authorized to login from this station.
Symptoms: 1. You may get the system error 1240 when using net view \\remotecomputer'
2. “Workgroup_name is not accessible… Account is Not Authorized to Log In to this Station” when attempting to browse the workgroup from a networking computer.
Resolutions: 1. Use Regedit to enable unencrypted (plain text) passwords for the SMB client.
2. Enable Send Unencrypted Password to Connect to 3rd Party SMB Servers under Local Security Policy.
3. Set the following policies as showing:
Digitally sign client communications (always) - disabled
Digitally sign server communications (always)- disabled
Digitally sign server communications (when possible) - disabled
LAN Manager Authentication Level set to Send LM and NTLM - use NTLMv2 session security if negotiated - (default) send LM & NTLM responses
Secure channel: Digitally encrypt or sign secure channel data (always) - disabled
Secure channel: Require strong (Windows 2000 or later) session key - disabled
4. Contact the third-party SMB server manufacturer if you have a third-party SMB server, such as DEC Pathworks, Samba or Linux.
System error 1311 - There are currently no logon servers available to service the logon request
Symptoms: The primary purpose of logging on with cached credentials is to enable you to access the local workstation. However, if you have logged on by cached credentials, you may be unable to access network resources because you have not been authenticated. For example 1) after you log on to a w2k/xp laptop by using cached credentials, you may be unable to access the network resources. This issue is commonly experienced by laptop users whose computer resides in a Windows Server domain and who log on to the computer by using cached credentials prior to being able to establish a remote access connection. 2) You log on to a w2k/xp laptop with a domain logon option in a workgroup network. After you establish the connection and you try to map the network drives, the operation may be unsuccessful, and you may receive the following error message: "System Error: (1311) There are currently no logon servers available to service the logon request."
Resolutions: To authenticate the cached credentials, 1) if it is w2k/xp, use net command, for example, net use \\servername\sharename /user:username. 2) if xp, open Windows Explorer>Tools>Map Network Drive. Click Connect using a different user name, enter the username and password.
System error 1326 has occurred - Logon failure: unknown user name or bad password.
Symptom: when using net use to map a network drive, you may receive "System error 1326 has occurred. Logon failure: unknown user name or bad password." message.
Resolutions: 1) create a user account on remote computer; 2) need to enable the guest account; 3) make sure the remote computer doesn't use auto-logon and blank password; 4) make sure you have a folder or drive shared on the remote computer. 5) use net use \\servername /user:username command. Make sure you type correct command (e.g. use net use \\servername \user:username will get this error too)
System error 1331 has occurred - Logon failure: account current disable
Symptom: When using net use \\computername command, you may receive above error message.
Resolutions: this is cache credentials issue. To fix this problem and cache the credentials, use net use \\computername /user:username command.
System error 1385 has occurred - Logon failure: the user has not been granted the requested logon type at this computer
Symptoms: When using net use \\remotecomouter\ahredname, you may receive above message.
Resolution: The users do not have permission to connect to the remote computer. To resolve this problem: on the remote computer, select Administrative Tools>Local Security Settings>Local Policies>User Rights Assignment, right-click on Access this computer from the network>Properties>Add Users or Groups, add everyone or any users you want to be able to access the computer from the network.
System error 1396 has occurred - Logon Failure: The target account name is incorrect.
Symptoms: 1. when using net use, you may receive above message.
2. when using net view \\hostname, you may receive "System error 5 has occurred. Access is denied.". However, net view \\ip works fine.
3. You may receive above error while running logon script.
Causes: 1. SPN for the domain that is hosting the replica has not been propagated.
2. Incorrect target account name or the server is not online.
3. If you have DFS, make sure the DFSRoot is available.
Refer to RL060704
System error 6118 has occurred. The list of servers for this workgroup is not currently available
SYMPTOMS: 1) After enabling ICS/ICF, you can't see any computes on My Network places. If you try, you may get "workgroup is not accessible". 2) If you use the net view command, you may receive "System error 6118 has occurred. The list of servers for this workgroup is not currently available." message.
Resolutions:
1) This behavior can occur if you enable the ICF that will closes the ports for file sharing by default. To open these ports, right-click the network connection that is firewall protected> Properties>Advanced>Settings>Service Tab>Add, Enter 127.0.0.1) for the required Internet Protocol (IP) number. Enter UDP ports from 135 through 139, and TCP ports from 135 through 139 one by one (the external and internal port numbers should be identical).
2) This may occur if the workgroup name and the domain name are the different.
3) No master browser. Starting Computer Browser Service on one of w2k/xp computers should fix the problem
