user1686's questions

Practically all instructions on enabling certificates for Remote Desktop server authentication (and configuring auto-enrollment through Group Policy) say that you should create a new certificate template (named "RemoteDesktopComputer" or similar), adding only the RDP-specific OID 1.3.6.1.4.1.311.54.1.2 as an extendedKeyUsage.

However, some third-party clients always expect the certificate to have a "TLS server" extendedKeyUsage and have issues verifying servers which only have this OID. So I would much rather use a generic TLS certificate for RDP as well.

Will there be any operational issues if I don't use a custom template, but instead specify the built-in 'Computer' template in the GPO setting? (The one under "Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security".)

Will there be any operational issues if the GPO also has certificate enrollment under "Public Key Policies/Automatic Certificate Request Settings" enabled for the same 'Computer' template? Will this possibly cause the computer to get two redundant certificates based on the same template?

Will there be any security issues due to computers using their generic 'Computer' certificate (with the standard "TLS server" OID) for serving Remote Desktop?

First, I apologize for posting a question in this site despite not having a football-court-sized datacenter under my management (I'm a tech support monkey at a small non-profit), but the topic seemed appropriate regardless.

The question I have is: What sort of damage exactly would happen if one connected a SC/APC patch cord to a SC/UPC module? (Assuming it's a low-power Ethernet connection in the ~2 km range.)

I've found different websites with claims ranging between "you'll just get a bit of insertion loss" (well yes, that's to be expected) and "you'll permanently destroy both connectors and/or the module" (how?).

However, out of a dozen websites claiming the latter, only two had any sort of concrete explanation, mainly about UPC reflections destroying very-high-power equipment.

We don't have high-powered equipment here; we have short-distance Gbit Ethernet which expects UPC in the first place. (And as it happens, the only patch cords at hand are either APC or multi-mode... Don't ask.)

Is that the only kind of damage that can occur, or can the mismatched angles also physically damage the connector "faces" and make them unusable? Or, well, something else?

I have a DNS domain and host it on my own server. My desktop PC (Windows XP) is configured to have mydomain.tld as its primary DNS suffix. Now, when the system tries to resolve any domain - stackoverflow.com, for example - it tries with the suffix added first, even if the name has periods in it. In other words, it tries stackoverflow.com.mydomain.tld. before stackoverflow.com..

1. Is this valid according to DNS standards and common sense?
2. Is there anything I can do to prevent it, other than removing the prefix completely? (I still want it to be appended to single-component hostnames. Currently I have two prefixes . and mydomain.tld. configured, but it isn't very fast when resolving foohost.)

I'm an administrator of a small Debian Lenny server, and I have this problem: Sometimes, when a user's SSH session is closed, the entry is not removed from /var/run/utmp, resulting in such messages from finger:

grawity@sine ~$ finger
finger: /dev//pts/31: No such file or directory
Login        Name              Tty      Idle  Login Time   Office     Office Phone
user1        (user)            pts/1      1d  Jul 15 19:12 (foo.uk)
user2        (another user)    pts/33   6:25  Jul 13 12:02 (bar:S.1)
user2        (another user)   *pts/34   6:31  Jul 13 17:00 (bar:S.0)
grawity      (me)              pts/25         Jul 17 11:57 (78-56-197-6:S.0)
grawity      (me)              pts/27         Jul 17 11:57 (78-56-197-6.static.zebra.lt)
Segmentation fault
grawity@sine ~$ _

...and sometimes even a segfault or two. Once utmp even had two entries pointing to the same tty (but belonging to different users).

Any ideas why this happens?

So far, I manage to fix utmp (using some utility designed for erasing Unix logs :> ), but that is obviously not a solution, not when it happens every day.

Edit: This question is not about records disappearing (so far I haven't seen that) - it's about the opposite: records not being removed when a login session is closed.