The project I'm on recently had a broken build due to a failing unit test. This is relatively unremarkable except the unit test in question would pass consistently on the developers machine but fail on others including our build server. This unit test relied on an external resource (an LDAP server) that was not visible to some of our development machines but was to others. This behaviour meant the test was of negative value as a failure could be attributed either to a legitimate bug or simple unavailability of the external resource. In general it would not be worth tracking down the cause on every failure. The test failure therefore becomes noise and will be ignored regardless of whether a legitimate failure has been detected.
This is in general true of all external resources. I've previously had systems where the unit tests relied on a test database to function. Despite numerous mechanisms to set up the data in this database correctly this lead to tests that were brittle and subject to failure if not run in a specific order. This seriously degraded the utility of the tests. In this case the availability of the resource could be reasonably assumed but its state could not.
In both cases what the test is actually testing cannot be considered a unit but rather a section of the system code plus some other thing the state and availability of which the test cannot control. This degrades the extent to which you can rely on the success or failure of the test. As such external resources should not form part of your unit tests.
This is not to say that interaction with external resources should not be tested. Clearly it will need to be tested if the system behaviour is to be confirmed. However this is a job for other forms of testing such as integration testing. This implies a recognition that unit testing, while a valuable element of constructing software, cannot be considered to be the whole of testing. Unit tests cannot reliably test integration which may require setup and resources not practical for repeated invocation in a development environment.
A unit test should therefore exercise complete control over the environment that the unit under test is running in. A failure of the test can then be assumed with some confidence to be an actual defect. This unfortunately inevitably means that certain elements of the code that deal with external resources cannot be tested. Ideally this should be properly decoupled from the remainder of the system so as to minimise the proportion that is not able to be unit tested. Testing of this code will therefore devolve to integration and related testing.