m0n4g3's foray into LDAP/AD auth in linux and more!

Hi Guys,

I work in a business that is predominantly WINTEL based, but i've done some work on linux and also just completed the RH199 course so I'm now i'm looking to put all that knowledge to use. Just wanted to know if my thinking is correct here.

Trying to offer a method for our linux boxes to A) authenticate using our AD infrastructure. B) authenticate predetermined SMB mounts on a Windows File Server using AD creds.

So for A) we used authconfig on RHEL systems. Unfortunately, we use predominantly debian and ubuntu servers, and this is not available on RHEL. Looking further into it i've been led down the realmd path using sssd and krb5.

Unfortunately i've hit a snag. When using:

Code:

 realm discover domain.example.local 

I get a resolve timeout on _ldap._tcp.domain.example.local and it doesn't allow me to join the realm.

Doing a:

Code:

 host -t SRV _ldap._tcp.domain.example.local 

Returns entries for all of our DC's, but still get timeouts for the realm discover. Another interesting thing to note is that it doesn't even discover any of the services available.

For B) once i do get realmd working and sssd for authentication, i should be able to use sec=krb5p/krb5i on the fstab entry correct, or should i use smbcreds file and use a "service" account to map this predetermined account?

 

Fixed A)!

Modified /etc/nsswitch.conf from:

Code:

 hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 

to:

Code:

 hosts:          files dns mdns4_minimal [NOTFOUND=return] mdns4 

Has fixed the realm discover! Now to join!

Edit:
Joined, and made domain admins sudoers. Seems to be working great!

I'll tackle B) at a later stage for now.

 

I decided to modify the title a bit to i suppose make this a relative thread around implementing LDAP/AD auth into my linux infrastructure, keep a sort of knowledge base for all the things i am doing around this, and hopefully help someone that may be doing the samething for the first time.

Also i may as well ask any questions related to linux admining in the one thread.

So one other thing that i wanted to do was to limit who actually is able to login to this machine. It seems to do so you need to modify a pam access file (/etc/security/access.conf) and then ensure that PAM (/etc/pam.d/login) is actually using this.

So the first thing to do is to modify /etc/security/access.conf with the following:

Code:

 -:ALL EXCEPT root local-account ('domain\ admin') (hostname-admin) :ALL

Obviously, root and a single local account with sudoers access need to be able to login. Now i believe to have ldap groups you need to have them in ( )? Is this correct?

once that's done, i then have to modify /etc/pam.d/login and add in:

Code:

account  required     pam_access.so

and finally so that they can ssh in modify /etc/ssh/sshd_config with:

Code:

UsePAM

Does this seem about right?

 

So it seems that /etc/security/access.conf with the following line does not work

Code:

 -:ALL EXCEPT root local-account (Domain?admin) (hostname-admin) :ALL 

It's still allowing me to login, and it's still allowing me to ssh with any AD account. really wanna lock this down so that only those 2 groups and those 2 local accounts are available for login.

Any one done this?

elvis - i know your time is pretty limited but any advice?

 

So i've scrapped the pam_access method. It works, but it's a pain to maintain.

Instead, realm actually has permit functions specifically allowusers and allowgroups for this function!

Using this i've locked it down to 2 groups for ldap, and locally have the root account (which i will probably lock) and another account that just has sudoers access.

This works for all services as well, so logging in via SSH is managed by these groups too.

Quick question outside of this, how does one setup a partial mirror from an upstream deb repo? What's the best methods, what are the easiest methods for purely local repo's (approx ~20 clients, both debian and ubuntu, and also potentially a couple of centos machines too).

 

We use RFC2307 (sometimes called rfc2307bis) extensions in AD, and use POSIX style UID/GID mappings to identify all of our users. From there we can reference groups as if they were native Linux groups (nsswitch and getent understand them, so does any other part of the OS like access.conf).

What do your groups look like when enumerated at the OS level?

 

when i do a groups username@domain.example.com i get the UPN of the groups eg Domain Users@domain.example.com, or IT-Admins@domain.example.com.

I've edited the sssd.conf file to have simple_allow_groups= domain\\Domain Admins, domain\\Boxname_Admins.

This has worked really well and has limited logons to just those 2 groups and no one else.

 

Yeah, I must admit, I push more and more into sssd.conf too. I know it kind of breaks the "rules" about how policies have been set on machines in the past, but it is a hell of a lot less work to make sssd figure out who's allowed on the box, and just tell everything else to ask sssd.

 

What do you use for local repo syncing?

I've looked at apt-cacher-ng and it doesn't seem to do updates/dist-upgrades so for me i think that's a no go.

i know there's debmirror and debpartialmirror but they seem a touch... convoluted in their setup. Aptly seems ok, so might give this a go.

 

So, quick rundown. I've decided on using apt-mirror. This seems to be the most supported way of doing it easily.

So far, caching Ubuntu 12.04-16.04, and Debian 8+9.

Seems to work well so i'll keep to that.

Thanks
m0n

 

You've already answered this for yourself, but apologies for my tardy reply. I use:

1) At home, apt-cache-ng. It only caches what I need, and works fine for ~5-ish systems hitting it. I've found in practice it tends to corrupt quite a bit when you've got >25 clients hitting it, so I don't use it for larger setups where I have the disk space to mirror everything (like work and a few places I volunteer assist). For them I use:

2a) rsync by preference. Places like Aarnet and Internode's mirrors offer the ability to rsync, which means deltas only and compression (not a big deal, as the bulk of packages are already compressed). Plus it's handy as you can bandwidth throttle rsync easily. Where I can't rsync I...

2b) apt-mirror. Handy to clean up shitty little repos like KDE Neon, Google Chrome, Atom.io, and a bunch of PPAs we need for stuff.

Some sizes, for interest's sake. We store Ubuntu 14.04LTS, 16.04LTS, and CentOS6 and 7. Although for Ubuntu, it's difficult, as you have to store everything in "pool", which is all current supported releases. Kind of annoying how they sort their stuff.

3.4G archive.canonical.com
70G archive.neon.kde.org
33G centos
19G dl.google.com
47G epel
456G macos
16G libreoffice
1.5G ubuntu-wine
220M repo.skype.com
1.4G www.ubnt.com

782G ubuntu
And inside that:
42G ubuntu/dists
740G ubuntu/pool
159K ubuntu/project

 

Hmmmm weird. My config file looks like this atm....

Code:

#Debian 8 x64 only. main contrib and non-free
deb-amd64 http://ftp.au.debian.org/debian/ jessie main main/debian-installer contrib non-free
deb-amd64 http://ftp.au.debian.org/debian/ jessie-updates main contrib non-free
deb-amd64 http://security.debian.org/ jessie/updates main contrib non-free

#Debian 9 x64 only. main contrib and non-free
deb-amd64 http://ftp.au.debian.org/debian/ stretch main main/debian-installer contrib non-free
deb-amd64 http://ftp.au.debian.org/debian/ stretch-updates main contrib non-free
deb-amd64 http://security.debian.org/ stretch/updates main contrib non-free

#Ubuntu 16.04 mirroring
deb-amd64 http://archive.ubuntu.com/ubuntu xenial main main/debian-installer restricted restricted/debian-installer universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu xenial-proposed main restricted universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu xenial-backports main restricted universe multiverse

#Ubuntu 14.04 mirroring
deb-amd64 http://archive.ubuntu.com/ubuntu trusty main main/debian-installer restricted restricted/debian-installer universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-security main restricted universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-updates main restricted universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-proposed main restricted universe multiverse
deb-amd64 http://archive.ubuntu.com/ubuntu trusty-backports main restricted universe multiverse

This seems to work fine so far? Haven't got any clients updating from it though. Just these are hitting 380gb so far.

 

apt-mirror evaluates specific packages and only downloads what's needed. It more or less acts like "apt-get" and downloads every package that's current now for the given release.

For that purpose, it requires less space on disk, which is nice. I find in practice the rsync method slightly more reliable, even if it wastes space thanks to how Debian/Ubuntu organise packages inside the "pool" directory.

 

Thanks elvis! Appreciate the advice/help!

Kinda getting excited about the job again now that i'm looking at these types of things.

After the sync i'll be testing it with various packages, and looking at a way to implement a repo for Centos based machines.

Once that's done, i'll be looking into maybe implementing SELinux for all of our servers and ensuring it's mandatory, along with creating a kickstart/anaconda style install answer file for various distro's so that our guys can have most of this done for them.

Any good sources on server hardening for various distro's?

 

Couple of good links here:

https://www.linuxtrainingacademy.com/hardening/

Hardening really is a "fit for purpose" thing though. You'll need to tweak it for the applications and packages you have installed, and what your intended purpose is. In general, minimising the attack footprint (i.e.: installing only the bare minimum of what you need on production servers, limiting access at all levels to only the necessary accounts from the necessary sources) and patching frequently (hourly/daily) will serve you pretty well. But there's plenty of other stuff you can go bananas on, like tripwire, mandatory access control (SELinux/AppArmor) and other things. They all have their own management overhead of course.

Once you get past those basics, it really becomes about hardening the applications and services you're using. There's dos and don'ts for everything, whether it's http, smb, bind, or whatever other things you've got on a box. Each one needs to be looked at specifically, if it's the exposed service.

 

Definitely. Security is like an onion, and the best implementations, have multiple layers.

 

And both tend to make you cry as you peel back the layers.

 

Ain't that the truth!

Thanks for that resource, had more than just linux guides. Downloaded all applicable stuff and will look at implementing. 300 page documents, lots of reading to be had!

 

Interesting thread. I've not played with LDAP all that much but now I've moved to a new job and the chances of me being able to introduce more Linux things probably mean I'll have to take a bit more notice of stuff like this now.

 

If you are interested i can post some of the step by step guides along my discovery journey.

Happy to have said guides updated as well for the benefit of all.