user1686's questions

We have a Microsoft Azure/Entra domain or 'tenant', originally converted from a "Work Account" self-signup into a fully-managed one with free plan (academic), therefore it has our base domain (i.e. example.com as opposed to something like ad.example.com) as the primary domain.

We don't use Azure much, but now we're adding a few accounts for Teams one-by-one. So far, we've chosen the account names to match the on-premises email addresses – e.g. my work email address is [email protected] so likewise my Entra account for Teams is [email protected].

But I've noticed that if Teams sends an invitation email to [email protected], it never arrives at our on-premises email server – instead, we find that email in an O365 mailbox when I open it via https://outlook.com and sign in with my Azure account.

I didn't know we had mailboxes as part of our free plan, but more to the point, can I make it send mail to our on-premises email server as the MX records already indicate? We don't use O365 mail at all (yet?), so I don't need it per-mailbox, but for the entire domain – at least for the time being. And if yes: how do I make it do that?

(Edit: We assign users "Office 365 A1 for Faculty" licenses, as not doing so seemed to completely break Teams in the past (to the extent of having to delete the account and re-create it), but I guess that is also what grants them an O365 mailbox as well.)

Or should we just switch the Azure tenant to use a different DNS subdomain as primary (like az.example.com) and then remove the old base domain? I'm hesitant to do so, as I don't want to accidentally end up with someone creating another ghost tenant via self signup like already happened before.

Please excuse the mess of terminology; our IT team of two people has almost zero experience with Microsoft's cloud stuff.

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.