![]() You can test this really easily by just pinging your domain name (for instance, if I ping should return an IP of one of my domain controllers.) If this doesn’t work, well, just keep reading. That’s not always the case, and if you have some other appliance or system to manage your DNS, this might not work for you (but see below for some workarounds). It’s always DNS, isn’t it? In most Active Directory environments, DNS plays really well with AD because you usually configure one when you configure the other. That same network has a properly configured DNS zone for your domain.Obviously, you need to be somewhere that has a place that you can get a ticket and key from. You’re currently on the same local area network as a domain controller.Okay, so what if you wanted to request a ticket on your own? Well, before we get to this demo, there’s a couple really big assumptions I’m going to make: You just have to manually request your ticket (and authenticate in the process). But if you don’t authenticate via Active Directory, there’s no reason you can’t do this manually. It’s all part of your handshake with the domain controller. If that kind of stuff excites you, go Google it, and I promise you’ll get more than you ever bargained for.īack on topic: so when you log into an Active Directory domain, this is managed for you, even on non-Windows machines. It’s way, way more complex than this, with lots of complicated terms and moving parts, so I’m doing a lot of hand-waving, but that’s the core of the system. That key is then forwarded onto the resource, allowing you to access the thing you were trying to connect to. Then, when you want to access a resource (like a SQL Server), the client re-ups with the store you got your initial ticket from (to make sure it’s still valid), and you get a “key” to access the resource. If you succeed, you get a ticket that get stored within your local machine. Simply put, it’s a ticketing and key system: you, a user, requests a ticket from a store, usually by authenticating to it via a username and password. It’s arcane, it’s complex, and it’s hard to even describe unless you use it on the regular. A lot of people cringe when you mention Kerberos because, well, Kerberos is hard. SQL Server supports different kinds of authentication mechanisms and protocols: the older NTLM protocol, and Kerberos. A lot of people will just create a SQL Server-based login and use that, but what if you can’t (or don’t want) to enable SQL authentication? Are you out of luck? When you’re using Active Directory to manage user identities and devices like you company computer, the simple act of logging in successfully each day handles a lot of things behind the scenes as to determining who you are, what groups you belong to, and other domain-related features like group policies.īut what if you’re using a computer that isn’t tied to (or even knows about) your domain? Maybe you’ve got a Mac (like me) or a Linux PC that isn’t joined to the domain. And, given such a system, you probably have access defined to things like SQL Server via your domain credentials (probably through group membership). Most often, this is Microsoft’s Active Directory. ![]() If you work for a company, chances are you’re subject to some kind of network identity management system. It can run on Windows, on a Mac, and even on Linux with an appropriate desktop experience installed. You need not take my word for it take a look at how many products and components now have been ported to Linux and/or Mac. It’s getting less and less important what kind of hardware you’ve got on your desk and more about where the things you’re trying to connect to are. ![]() Today though, we live an increasingly cross-platform and cloudy world. Granted, I’m totally making this up but if you ever make a trip to a decent sized technical conference centered around SQL Server, I think if you took a straw poll, I bet I’d be closer than not. That probably still holds true for my totally-made-up-just-now statistic of 80-90% of the general SQL Server users out there. Likewise, if you worked for an organization that had SQL Server running, you probably were subject to being part of an Active Directory domain. Time was, if you were a SQL Server-based administrator/analyst/developer you probably were locked into using a Windows-based machine. This ain’t your daddy’s Windows-only world ![]()
0 Comments
Leave a Reply. |