3

Over the last year we have migrated almost all services that used to run on our Windows server (SBS 2003 Premium) to another server running Linux. The last few services will shortly be moving to a new Windows 2003 Server running as a VM on top of the Linux box - we plan to keep this VM long term as we anticipate there will always be a need for certain software that will only run on Windows.

As all of the migrated services (email, fileserver etc) use their own authentication, I am left wondering if the benefit of keeping the windows domain is outweighed by the cost (primarily increased complexity for disaster recovery). Should I take the opportunity to get rid of it entirely if there is no obvious need to keep it?

The company has about 20 desktops, including several that are not currently joined to the domain because they are XP Home boxes got on the cheap.

  • 1
    If you're not using it, and you'r considering shutting it down altogether, how would keeping it increase the complexity of disaster recovery? Wouldn't you simply ignore it in a DR scenario? – joeqwerty Jun 06 '11 at 12:20
  • If we keep it, all the windows clients will be set up to use it - DR is more complicated as we would have to recover the original domain, not just install any old Windows OS that could run the Windows services we need - or stomach the pain of reconfiguring all the desktop machines when it happens. –  Jun 06 '11 at 12:23
  • 3
    I'm curious as to why you've moved to services with their own authentication. Don't your users find that tedious or you find you spend a lot of time recovering passwords? – uSlackr Jun 06 '11 at 12:40
  • @uSlackr - Take imaps/smtps for example, our users need access from all sorts of different mobile devices - we need non-domain auth for this anyway. With 15 desktops on the domain I haven't really missed domain auth for email much. What do you mean by 'recovering passwords'? We give the users passwords that they cannot change, and different for each service. So far everyone is happy... –  Jun 06 '11 at 12:49
  • 4
    @Jack - Ouch, passwords that users cannot change is baaaaaaad. I hope that you're not working with sensitive data at all, you'll fail an audit immediately with a policy like that. – MDMarra Jun 06 '11 at 12:54
  • 1
    @JackPDouglas: You need non-domain auth for SMTP/IMAP? Funny, we're using Exchange for that (with Activesync devices and regular POP/IMAP/SMTP devices), and it's working just fine. – pauska Jun 06 '11 at 12:58
  • @pauska - I'm not saying it isn't possible, but we are a small shop with a very tight budget. –  Jun 06 '11 at 13:02
  • @MarkM - care to elaborate? –  Jun 06 '11 at 13:03
  • 3
    @Jack - Not really, it's an instant failure in almost every type of audit, since both a member of IT *and* the user will know that password. It's much too long of a topic to get into beyond that. – MDMarra Jun 06 '11 at 13:06
  • @JackPDouglas: A budget that can't even fit a SBS2008 server? Have you considered moving to cloud based services? – pauska Jun 06 '11 at 13:09
  • @pauska - we have to work with what we have got - there are shops of all shapes and sizes in the SMB world. We have considered Google Apps for example but really don't feel comfortable delegating responsibility for our data in that way. –  Jun 06 '11 at 13:20
  • 8
    So you're comfortable with shared passwords but not with the cloud? I'm all for being cautious about putting important data into the cloud but combining that with shared passwords is like someone who smokes 10 packs of cigarettes a day who won't drink coffee because they've heard that caffeine is bad for you. – Rob Moir Jun 06 '11 at 13:25
  • @Robert - yes, I trust myself but not cloud providers :) passwords are not shared between users, but yes, as MarkM points out, I understand there is a trust issue with the IT team. I think that is usually the case anyway (can't you see your users email in exchange without knowing their password? I can.) –  Jun 06 '11 at 13:31
  • 2
    If I have to access a users's emails in exchange as an admin, then it will be logged, so that's hardly the same. Being able to impersonate users because I know their credentials is a very bad thing. I'll give you a simple example - your company needs to discipline an employee for gross misconduct using your email system. They claim you used their password to impersonate them and send the email, and sue for wrongful dismissal. Good luck proving they did it. Your password policy is from about 20 years ago. It has very little to do with who you "trust". – Rob Moir Jun 06 '11 at 13:47
  • @Robert - If I was a criminal IT admin I would be able to install a keylogger on my users PCs to discover their passwords. No-one can prove I didn't do that. Trust always comes into the equation, in court or otherwise. No doubt there are many other ways too... –  Jun 06 '11 at 13:50
  • 2
    But they can't *prove* you did install a keylogger. They can prove you know their password, because you set it for them. At the end of the day it's up to you how you run your IT setup, but all the justification in the world isn't going to turn bad practice into good. – Rob Moir Jun 06 '11 at 13:54
  • @Robert - no more than they can *prove* I logged in and impersonated them. My point is that 'proof' is not the main issue, trust is. –  Jun 06 '11 at 13:59

2 Answers2

7

If you plan for your company to never grow, then it sounds like you can certainly do away with it. The major benefits to AD are centralized auth, group policy, and integration into other systems. With a desktop fleet of 15-20, you can handle most of the grunt work by hand rather than GPO (though GPO would still be faster).

If you ever plan on growing, your current setup will quickly spiral out of control. Without a way to centrally manage settings and dictate policy to the Windows clients, you'll have your work cut out for you if your user base doubles. If you try and do everything on the cheap, you'll end up spending more money on man-hours trying to manage it. There is going to be a certain cost to IT operations and trying to go as cheap as possible never works.

Also, not allowing users to change passwords is a huge security issue. You should really remedy that whether you stick with AD or not.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • Thanks - growth is a consideration but we've been 15-20 desktops for 15 years and will probably be heading lower over the next couple of years. Still, I can't predict the future and it's helpful to have my attention drawn to the potential pitfalls here. As for passwords, I think letting users choose passwords is a huge security issue - in fact passwords are a terrible way of authenticating (do users remember and regularly change their sufficiently-complex passwords? or do they write them down on a post-it?). Shame there is nothing better. –  Jun 06 '11 at 13:37
  • 2
    @Jack - While I understand that there are social problems with passwords, almost every type of authentication database/directory allows for complexity and expiration requirements. A fence with chain-link and razor wire will keep whatever is behind it much more secure than some posts and string. Just because passwords aren't perfect doesn't mean that common best-practices regarding them should be ignored. – MDMarra Jun 06 '11 at 13:40
  • 1
    @Jack, GPO in AD allows you to centralize passwords, so users only have to remember one, force password complexity, password length, how often they have to change their password (both min and max time frames), can't reuse passwords.. MS put a lot of thought into what password security you can enforce (or throw out the window, as you have). – Chris S Jun 06 '11 at 13:42
  • @Chris - I have nothing against MS or AD - and you can also achieve SSO in a Unix environment if you try hard enough. I am not the only one who thinks a single password is *less* secure however: it is an old argument. –  Jun 06 '11 at 13:46
  • 1
    @Jack, could you point me in the direction of some scholarly articles regarding SSO being less secure? I'd be very interested in reading up on that. – Chris S Jun 06 '11 at 13:49
  • @Chris - The point is simple: if a computer is hacked and a password is compromised, access and therefore damage may be limited to that one service. [Here](http://securitymusings.com/article/353/dangers-of-single-sign-on)'s the same argument. Note that I'm not saying SSO is bad for *you*, just that there are valid arguments against it that may apply to any given environment. –  Jun 06 '11 at 13:56
  • 1
    @Jack - People certainly go back and forth about SSO (with most people taking the convenience of SSO), but the problem isn't so much with that as with the non-expiring, non-changable passwords that are not known exclusively by the user. – MDMarra Jun 06 '11 at 13:57
  • @MarkM - I can of course expire/change the passwords, and I'll consider doing that - certainly if there is any suspicious activity. The users typically don't even know their passwords. –  Jun 06 '11 at 14:03
  • 3
    So you don't let users pick their passwords. Instead, what?, you pick them for everyone. And you don't see a significant security risk in knowing everyone's password. Does your boss? And if the users don't know their passwords, what IS your security mechanism? – uSlackr Jun 06 '11 at 14:44
  • @uSlackr - Yes I generate passwords for each user/service. Then I set up access on the PC/device. That way I can force far more secure passwords on my users than you can. If my boss does not trust *me* then changing our password policy is hardly the answer, he needs to fire me quick - is there anyone in your IT department who cannot access sensitive information if they want to? It sounds to me that your boss has a false sense of security if he thinks his password policy is any protection from malicious server admins. –  Jun 06 '11 at 16:21
  • 1
    @jackpdouglas, Certainly in a windows environment there can be information that admins cannot access directly (and if they are not allowed to back it up then they can't access it indirectly either). Active directory has the ability to set a complex password policy of any complexity you like, as well as the ability to set up auditing and monitoring capabilities so that if you do access files you should not be accessing (abusing your admin rights), management can get notified with seconds. – Jim B Jun 06 '11 at 16:52
  • @Jim: If the admins have physical access to the servers than I think it if fair to say they can do what they like. The first step around all your auditing and monitoring could be to clone your server - in some environments as simple as faking a disk failure and swiping half a mirror. As to password complexity, you are limited in practice by what your users will accept - I am fairly sure no user would accept the passwords I generate if they ever had to type them in :) Our concern is primarily about security from *outside* threats rather than internal - that may be different is your environment. –  Jun 06 '11 at 16:59
0

Certainly having some directory service and a single authoritative source of authentication / authorization (which supports replication) is a good idea but (JackPDouglas Read this):

1) It does not have to be MAD - GoSA provides an excellent set of tools for implementing a LDAP based directory, there are other solutions available.

2) LDAP/MAD is NOT SSO

symcbean
  • 21,009
  • 1
  • 31
  • 52
  • @syncbean - the SSO thing was a side issue after this comment: "GPO in AD allows you to centralize passwords, so users only have to remember one" - my question was not about SSO specifically. Nevertheless, thanks for the link to GoSA which is interesting. –  Jun 06 '11 at 14:30