AD is just a directory server with some extra features. It is meant to hold a list of users and their data, essentially a specified database.
AD is not a "field", it's a tool, same as NDS, IPA, OpenLDAP, 389/RHDS etc.
So most of the questions are totally irrelevant - you either don't understand what AD is, or you have been mislead into thinking it's not what it really is.
Her class is Microsoft Server
The field would be dealing with microsoft servers and AD (aka MS sys admin)
AD is the defacto standard in most businesses for their user authentication model.
It is relatively easy to set up and get working with it in a simple network.
It gets complicated fast when problems start to arise, especially when dealing with replication and dns problems.
It is a broken implementation of ldap which ends up leading to a lot of problems with integration outside of Microsoft products and other OSes.
>AD is the defacto standard in most businesses for their user authentication model.
I'd argue with that, but what's the point?
As for the rest, I don't get the reason for eyerolling
I'm curious as to why you would argue with AD being the de facto standard in most businesses? NASA, NIH and most other US govt agencies I can think of use AD as well as most large corporations. Therefore, it is the de facto standard whether we like it or not.
If you have other information, please share.
I rolled my eyes because your answer was unhelpful. She posted asking for help and instead of helping her, you said the constraints of this assignment are wrong/irrelevant... Whether they are or not, it's not really helping anything...
defacto standard was a pretty extreme term for me to use, but sadly, it is what it is. If you have windows desktops in an environment, you likely have AD.
the answer suited the question, which was not only presumptuous, but also completely misguided.
as for defacto standards, as I said - it's arguable, and it would be an argument nobody can win, since neither of us has real, detailed stats of every major DS implementation out there.
I may seem that, but I work with these people every day. The ones whose sole purpose is to watch AD are entry level juniors, who have a bit of rights delegated, and they are able to reset passwords, watch replication and sync logs etc.
AD is never a system in it's own rights, it's just another tool, and there really is no point in glorifying it unnecessarily.
yeah, that's definitely a counterargument. If you've nothing to say, don't say anything - you'll seem smarter.
I'd like to add the following:
You can also seriously break shit with GPOS. (don't ask me how I know this)
Can I hazard that the knowledge came from trial and error?
We finished up migrating roughly 95% of our systems from XP to windows 7 about a month ago. We also decided that it was a good idea to clean up our group policy implementation at the same time, as there was a lot of deadwood and stuff that actively screwed over windows 7 boxes if they got applied to one by accident.
I was the point-feline for all the group policy stuff, and there were a few times where I very nearly immolated our support manager because he kept insinuating that problems that were being caused by either a setting on the local machine*, incompatibility with an application**, or flat out lack of any testing or specifications on how the machine needed to behave*** were being caused by one of the group policies I had built.
Yeah, fun times.
* The image of which I had *zero* involvement in building
** One of our critical apps is such that the vendor won't even *look* at the issue if windows 7 is involved, let alone support it.
*** Despite the fact that I begged, pleaded, and threatened for people telling me how the machine needed to behave, all meetings that we had for it were fruitless because people didn't want to be responsible for it if it blew up. And then they bitched at me when it DID blow up and didn't like it when I said 'this is *why* I asked for this information 4 months ago!'
1,000,000,000,000 times this.
And it doesn't matter how good your 'testing' environment is. In the real world it can be completely different. We spent months testing a GPO because we knew it was dangerous. We played around with different AD setups, tried to mimic our real world one as good as we can. We finally feel comfortable enough to implement it and it basically renders all computers unusable in the production domain.
Luckily our replication isn't the best so I was able to login to a couple remote DC's before it applied, wait for it to apply, and change it back.
Can you tell that my hatred for Windows is nearly complete?
Considering that my first windows server class (I'm in server 2 atm) was nothing more than an expansive lesson in Murphy's law I fully understand the hate.
Thank you very much for the input.
I am the Group policy, Exchange, AD, and backup admin along with being the resident hardware alpha geek for $work.
I've always been interested in computer electronics- I've been in the industry for almost 15 years, and I've been in my present position for nearly 2.5 years, with 5 years total at the present company. Along the way at said company, they've paid for me to get my MCP and MCSA (which are just validations, really- We have an MCSE that can't find their arse with a 1:1 topo map, torch, and a tour guide.)
Pro: AD is pretty much the standard if you are going to network windows computers with each other with any semblance of central management. (I'm not sure if Netware is still around, haven't seen nor touched it in years.)
Con: AD does require at least one dedicated server; two is better. Depending on how complex the network topology is, it can also be somewhat tricky to setup; but then, the tricky part pays off in easier times managing it.
Pro: AD also allows for centralized management of everything- computers, printers, and users, all in one great big ball o yarn. As noted by others, you can do some seriously cool shit with group policy.
Con: The flip side of GPO management is that you can break a computer's behavior in seriously stupid and hear pulling ways with group policy. Plus, if you have multiple sites with multiple domain controllers, replication can become a serious issue in a hurry.
I learned about 90% of what I know and use in the field and from day to day operations and troubleshooting. the other 10% was stuff that you need for the certifications.
Other things to note... I find often that in courses, you learn the insecure methods of installation and configuration of most application, AD included, and then sort of boot strap on security methods after.
If you compare your class installation steps against a NIST or NSA or CIS template of how to harden AD, you will quickly find yourself not knowing what the hell to do.
Real world implementations, or rather, how real world implementations should be... very seldom conform to these rigid requirements for ease of administration and simplicity of troubleshooting.
Unrelated to your actual questions, but a important thing to note:
The most important thing to learn about any M$ class is... It's teaching you what M$ thinks their software does. You will find that in the real world you'll run into time and time again situations where you go "Uh, but the class said it'd do that...".
My favorite recent example of this is Exchange 2010. In class they tell you all about how to configure the SMTP relays. Finally we get to the 'lab' part and the instructor says "Ok, so everything you just learned is wrong. Anonymous does not work, you need to set the security permissions for Exchange Server if you want to be able to send anonymously."