Login to web with domain account

[Nick2253]

I think I already know the answer to this, but is there a way to login to the web console with a domain account, instead of root?

What we'd love to do is make certain administrators "NAS Administrators" who have access to log in to the web GUI to make changes. Once there, I really don't care if they have root permission. I just want a better way to control who gets access and who doesn't other than changing the root password.

The reason this came up is because we let one of our network admins go, and it wasn't pretty. Though we shut down his network credentials and removed his access, the one thing we didn't think about was the FreeNAS root password, which was shared by the sysadmins. Long story short, he got on the network, and did major damage to our FreeNAS server (yay for backups!).

In our security audit, the only system that we allow remote non-domain root/admin access is the FreeNAS system because of the web GUI, which makes me uncomfortable. I'd love to change that somehow, but unfortunately, I don't think that's an option. As I recall, root is the only web login option.

Someone prove me wrong!

 

[pirateghost]

You need to figure out how he got in. That is your major security issue right now. There is no reason that FreeNAS should be accessible from outside the network, and in an enterprise environment, you should be using ACLs to limit what access there is to things like your storage. This isn't really a FreeNAS problem, as many vendors do the exact same thing across multiple platforms.

 

[anodos]

You need to figure out how he got in. That is your major security issue right now. There is no reason that FreeNAS should be accessible from outside the network, and in an enterprise environment, you should be using ACLs to limit what access there is to things like your storage. This isn't really a FreeNAS problem, as many vendors do the exact same thing across multiple platforms.

In this vein. I suppose an ugly hack to get what you want is to enable SSH, set an ACL on your switch blocking access to webserver ports, disable ssh into root account, and modify sshd_config to only allow ssh access from domain admins. Then access webserver via ssh tunnel. You should be able to correlate actions through webgui with entries in auth.log

 

[Nick2253]

You need to figure out how he got in. That is your major security issue right now. There is no reason that FreeNAS should be accessible from outside the network, and in an enterprise environment, you should be using ACLs to limit what access there is to things like your storage. This isn't really a FreeNAS problem, as many vendors do the exact same thing across multiple platforms.

We know how he got in. And FreeNAS is not accessible outside the network; where did I say that? We do use ACLs to limit access to the shares, but my issue is I can't do anything like that to limit access to the web gui.

If you really want to know, he came in through a remote site directly after he was terminated. He literally walked up to a user, said "we're having problems with your computer, mind if I take a look", logged in to the FreeNAS web gui, and went to town.

The problem was partially our fault, because we didn't notify the remote site. Prior policy was to notify day after termination, though we've since changed that as well. But, in all honesty, this wasn't something we expected. We've had messy terminations before, but never retaliation to this level.

The reason I'm concerned about FreeNAS is because, had we been able to restrict access to the web GUI based on domain credentials, he wouldn't have been able to do anything. In theory, even with the user's credentials, at best he could have deleted some files off a file share, which could have been easily restored from snapshot.

Based on our reconstruction, he tried. He even convinced the user to log in with her password to attempt access to a server. After fifteen minutes of not getting anywhere, he remembered the FreeNAS system, and logged in using the root account, which gave him open access. Once the network shares stopped working, it didn't take us long to figure out what happened.

The problem, in my mind, is that there is no other system on our network that requires us to use a root account to remotely manage it. I should clarify: we have many systems that allow both domain accounts and admin/root access remotely, but for those services, the CTO has randomly generated an admin/root password, and locked that in the emergency safe. So, realistically, there is no remote access for anyone who doesn't have access to the safe. My goal would be to at least also allow domain accounts to have web login ability, so that we could follow the same system for FreeNAS.

In this vein. I suppose an ugly hack to get what you want is to enable SSH, set an ACL on your switch blocking access to webserver ports, disable ssh into root account, and modify sshd_config to only allow ssh access from domain admins. Then access webserver via ssh tunnel. You should be able to correlate actions through webgui with entries in auth.log

I guess this would work, though it really is an ugly hack. I was hoping I wouldn't need to resort to something like this, but thanks for the suggestion.

 

[SweetAndLow]

I would think you would just change the password when someone no longer needs access. Simone solutions are sometimes best.

 

[anodos]

We know how he got in. And FreeNAS is not accessible outside the network; where did I say that? We do use ACLs to limit access to the shares, but my issue is I can't do anything like that to limit access to the web gui.

If you really want to know, he came in through a remote site directly after he was terminated. He literally walked up to a user, said "we're having problems with your computer, mind if I take a look", logged in to the FreeNAS web gui, and went to town.

The problem was partially our fault, because we didn't notify the remote site. Prior policy was to notify day after termination, though we've since changed that as well. But, in all honesty, this wasn't something we expected. We've had messy terminations before, but never retaliation to this level.

The reason I'm concerned about FreeNAS is because, had we been able to restrict access to the web GUI based on domain credentials, he wouldn't have been able to do anything. In theory, even with the user's credentials, at best he could have deleted some files off a file share, which could have been easily restored from snapshot.

Based on our reconstruction, he tried. He even convinced the user to log in with her password to attempt access to a server. After fifteen minutes of not getting anywhere, he remembered the FreeNAS system, and logged in using the root account, which gave him open access. Once the network shares stopped working, it didn't take us long to figure out what happened.

The problem, in my mind, is that there is no other system on our network that requires us to use a root account to remotely manage it. I should clarify: we have many systems that allow both domain accounts and admin/root access remotely, but for those services, the CTO has randomly generated an admin/root password, and locked that in the emergency safe. So, realistically, there is no remote access for anyone who doesn't have access to the safe. My goal would be to at least also allow domain accounts to have web login ability, so that we could follow the same system for FreeNAS.



I guess this would work, though it really is an ugly hack. I was hoping I wouldn't need to resort to something like this, but thanks for the suggestion.

I don't know anything about your network, but perhaps remote sites don't need access to the WebGUI. I believe the ACLs pirateghost was referring to are the type you can enable on the ports of fancy managed switches, but I could be wrong.

 

[Nick2253]

I would think you would just change the password when someone no longer needs access. Simone solutions are sometimes best.

Trust me, we are well aware of that. ;)

The problem comes from about half a dozen people who need semi-regular access to FreeNAS, and changing the password impacts all of them. I can disable a domain account pretty quietly, but when I start handing out new passwords, people know something is about to go down/just went down.

We've completely redone our policy, and taken a long, hard look at who does or doesn't need access to different resources on our network. Honestly, I'm decently happy where we are now, it's just that I'd like to have a better solution.

I don't know anything about your network, but perhaps remote sites don't need access to the WebGUI. I believe the ACLs pirateghost was referring to are the type you can enable on the ports of fancy managed switches, but I could be wrong.

That's something else we've looked at. Part of the problem is that we have techs at remote sites pretty regularly, so we can't just clamp down the whole thing. One solution that we've thought about doing is setting up a secured wireless network for the techs, and only let them in through that. However, that's a lot of work for what is ultimately minimal benefit.

 

[jprouvos]

How about setting up a central management station for when the techs are working from remote (untrusted) locations? SSH/RDP/VNC/ into that box, and connect from there to any system needed. Blocking the user on entry of that is easy (AD/NIS+/TACACS+/RADIUS) and you can have extra control on outgoing connections from there to the management environment... The cost/effort for this setup is relatively low and it can be used for more than your techs. Think vendor support. Heck, you can even do it with some sort of VPN server.

 

[Johnny Fartpants]

I agree with Nick, having a way to allow users to access the Web GUI instead of sharing the root password would be very helpful. One step further would be to be able to limit what those users can and can't do once logged in would be even better. If Joe Bloggs user could login and only change their password that would be good. Then perhaps sysadmins that can create users, datasets etc and then root to give all access. I can't see that this would be hard to implement and would provide a massive benefit.

 

[anodos]

I agree with Nick, having a way to allow users to access the Web GUI instead of sharing the root password would be very helpful. One step further would be to be able to limit what those users can and can't do once logged in would be even better. If Joe Bloggs user could login and only change their password that would be good. Then perhaps sysadmins that can create users, datasets etc and then root to give all access. I can't see that this would be hard to implement and would provide a massive benefit.

I see this more as a change to happen in FreeNAS 10. Perhaps it already has that feature. Might be worth looking into, but we're talking software that's got a long way to go.

 

[Ericloewe]

Good news for all: FreeNAS 10 will have more flexible management of users' access to the WebGUI.

Don't know the details and what kind of integration GUI admins and AD admins will be able to have, but at the very least, it allows for quiet takedowns of individual users.

 

[Nick2253]

Good news for all: FreeNAS 10 will have more flexible management of users' access to the WebGUI.

Don't know the details and what kind of integration GUI admins and AD admins will be able to have, but at the very least, it allows for quiet takedowns of individual users.

Yay! Happy to hear. That's very good news.

Dare I ask what the release schedule looks like?

 

[Ericloewe]

Yay! Happy to hear. That's very good news.

Dare I ask what the release schedule looks like?

We'll probably learn some details on 2015-08-15. That's the current target for FreeNAS 10 Milestone 2. We're probably looking at a year before a FreeNAS 10 Release.

 

[DrKK]

Can I ask a dumb question?

Were the police called on this employee? I personally think it is worth prosecuting him. Even in your hippie state, he's committed a felony.

 

[Nick2253]

Not a dumb question at all, even in my (terribly, awfully, horribly) hippy state ;)

I can't really comment on that, and I'll let you read into what that means.