LinuxQuestions.org - Active Directory and RHEL

- Red Hat (https://www.linuxquestions.org/questions/red-hat-31/)

- - Active Directory and RHEL (https://www.linuxquestions.org/questions/red-hat-31/active-directory-and-rhel-4175449962/)

Active Directory and RHEL

Hi Folks.

I've been pulling my hair out (not really, I'm bald) on-and-off for the better part of a month trying to get our webservers hooked up to our campus active directory so that I can have users connect with their AD credentials instead of me creating them a local account each time.

I thought I was really close today, but now my Windows guys think I'm even further away than I thought. :/

I saw the post a few down from this one that said to try centrify express, and I will look into that today when I get to work.

In the meantime, I was hoping that someone out there could provide me with the missing piece to what I'm doing wrong.

I'm at the point now where I've joined the machine to the domain, and can log in as me using active directory. However, it doesn't map FOO\me ---> me so when I log in I have no permission to view anything in my home directory.

(I log in doing something like "ssh FOO\\me@server.dept.foo.edu" and the Windows guys tell me that "\" is really a Windows-only thing and I should have to be using that to connect to the server... And what I was hoping for was to log in with something like "ssh me@server.ad.foo.edu" and just have it work--maybe I'm crazy...).

Some important (I think) parts of my documentation of this effort are below. If anyone notices anything out of the ordinary or knows the one final last step that I haven't taken, and could point it out to me, I'd be forever in your debt. Here's parts of what I've tried:

Code:

In /etc/sysconfig/network-scripts/ifcfg-eth0

DOMAIN=dept.foo.edu



/etc/hosts

130.126.xx.xxx  pweb6.dept.foo.edu  CCSG-PWEB6.ad.foo.edu



Configure PAM:

 

run authconfig-tui



Realm AD.FOO.edu

KDC ad.foo.edu

Admin Server ad.foo.edu



Next...

Domain: FOO



Here's what the guts of smb.conf look like:



  workgroup = FOO

  password server = ad.foo.edu

  realm = AD.FOO.EDU

  security = ads

  idmap backend = rid

  idmap uid = 16777216-33554431

  idmap gid = 16777216-33554431

  winbind use default domain = false

  winbind offline logon = false

  template shell = /bin/bash

  template homedir = /home/%U





[root@pweb6 samba]# net ads join -U mikeg createcomputer="HCD/CCSG Servers"

Enter mikeg's password:

Using short domain name -- FOO

Joined 'CCSG-PWEB6' to realm 'ad.foo.edu'

No DNS domain configured for ccsg-pweb6. Unable to perform DNS Update.

DNS update failed!



[root@pweb6 samba]# wbinfo -tm

checking the trust secret for domain FOO via RPC calls succeeded

BUILTIN

CCSG-PWEB6

FOO

(And a whole slew more...)



ipmweb:~ mikeg$ ssh foo\\mikeg@pweb6.dept.foo.edu

foo\mikeg@pweb6.dept.foo.edu's password: (Enter AD password...)

Last login: Wed Jan 23 12:19:43 2013 from ipmweb.dept.foo.edu

[FOO\mikeg@pweb6 ~]$ pwd

/home/mikeg

[FOO\mikeg@pweb6 ~]$ ls

ls: cannot open directory .: Permission denied

I'd very strongly suggest you get (or check if there already are) posix extentions on the AD domain controllers, and just interface directly with pure LDAP and nothing else. It's so so much simpler than all the pain you're finding now. IF all you want is to log in, then keep all the data in the DC and just use LDAP.

I only half-understand what you wrote, so I'll look into it further this morning when I get to work.

Basically what I want to do is have be able to add end-users to certain groups in the AD so that they don't need local Linux accounts to access various web sites on our servers.

The problem I had yesterday, that I failed to list above (sorry) was that while *I* could log in with my AD credentials, nobody else could, and the Windows guys think that it's a problem on my side, and not theirs.

And installing a server/client solution won't work either because we're at a large university and we're just a small unit and there's no way campus is going to let us install (or install for us) that Centrify software at a campus level.

The other big problem was that if I deleted my local user account, I could no longer log-in with my campus AD account--and having to have local user accounts created first so that folks can log in with AD sort of defeats the purpose (or am I missing something...).

Thanks for the suggestion, and like I said, I'll look into it today when I get to work. :)

I've just started looking at Centrify as a way of moving from LDAP on the UNIX side. It is not an application where something has to be installed on the the AD side. It is merely an agent that runs on the UNIX/LINUX box. During the install, it asks for some info about the location of the AD and then it resolves it all itself...much like adding a windows machine to a domain. It's worth installing the free version just to find out how it works. If you don't like it, you can turn it off with one /etc/init.d/xxxxxxx command, and you can do it all yourself without any help from the AD side. I put it on a test Sun T2000, and it worked without me having to ask the Windows AD people for stuff other than for the ip address of the AD machine and a username/account that could add a machine to the AD, but you probably already have that info.

Oh, one last thing. The Centrify agent gets installed on every box that needs to check username/passwords. So if you have five boxes, you put it on each of them.

sounds like a new product where no product was needed in the first place. As far as the more basic requirements of just being able to log in to a box with AD creds goes.

It's been one of those days. I re-read the original post just now to discover for the first time that the OP was talking about Samba. I didn't get that the first time I read the post. Which changes my thoughts.

I have users who need access to Windows machines and Samba machines as shares, and some of those same users need to be able to SSH to a Unix box for other purposes. My predecessors determined that there should be an LDAP server on the UNIX side and AD on Windows, so every time a new user was created, he/she had to be added to Solaris' LDAP and Windows AD. I started looking at Centrify so I could very easily do away with the LDAP, which is rather cumbersome to manage on Solaris (I think it's cumbersome, but that's just my opinion). Centrify also has a build of Samba, but I couldn't get it to install on Solaris 10 and I didn't want to spend more time with it because our Samba works fine checking AD with "security=domain" and "password server = name_of_password_server."

well samba 4 has a builtin ldap server, but outside of that I don't *think* there is a need to use a linux ldap server to achieve that. AD has a fully functional LDAP interface to the directory, which is surprisingly flexible. Whilst I'd never advocate installing AD in the first instance, once it's there, port 389 is open.... so why not work with it...?

griffey,

Is a home dir created when you login, or did you manually create it???

Here are my PAM Settings where I could view and see my home dir and it was created on login.

Code:

cat /etc/pam.d/system-auth



#%PAM-1.0

# This file is auto-generated.

# User changes will be destroyed the next time authconfig is run.

auth        required      pam_env.so

auth        sufficient    pam_unix.so nullok try_first_pass

auth        requisite    pam_succeed_if.so uid >= 500 quiet

auth        sufficent    pam_krb5.so use_first_pass

auth        sufficent    pam_winbind.so cached_login use_first_pass

auth        required      pam_deny.so



account    required      pam_unix.so

account    sufficient    pam_succeed_if.so uid < 500 quiet

account    [default=bad success=ok user_unknown=ignore] pam_krb5.so

account    [default=bad success=ok user_unknown=ignore] pam_winbind.so cached_login

account    required      pam_permit.so



password    requisite    pam_cracklib.so try_first_pass retry=3

password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok

password    sufficent    pam_krb5.so use_authtok

password    sufficent    pam_winbind.so  cached_login use_authtok

password    required      pam_deny.so



session    optional      pam_keyinit.so revoke

session    required      pam_limits.so

session    optional      pam_mkhomedir.so  silent

session    [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

session    optional      pam_mkhomedir.so skel=/etc/skel  umask=0644 silent

session    required      pam_unix.so

session    optional      pam_krb5.so

SSH Config:

Code:

vim /etc/ssh/sshd_config



KerberosAuthentication yes

SAMBA Config:

Code:



vim /etc/samba/smb.conf



workgroup = FOO

password server = footown.foo.foo

realm = FOO.EDU.AU

security = ads

idmap uid = 16777216-33554431

idmap gid = 16777216-33554431

template shell = /bin/bash

template homedir = /home/%D/%U

winbind use default domain = yes

winbind enum users = yes

winbind enum groups = yes

wins server = 10.10.10.1

wins support = no

netbios name = footown

You shouldn't be logging in as: ssh FOO\\me@server.dept.foo.edu" just login as me@server.dept.foo.edu it automatically will assume the FOO domain if you have set it up properly.

There is no need for a 3rd party product unless there are certain needs, samba can handle this itself.

griffey, I completely understand your frustration. I maintain many Linux distributions RHEL5/6. Ubuntu, and Fedroa and trying to get samba/winbind to work well on all of them was a nightmare. I started my current job with relatively working configs but there were many issues. I eventually got ok working configs but hosts would randomly disconnect from the realm, or UID-SID mapping would stop working...plus the permission issues that would arise.

I then discovered Power Broker Identity Service (formerly Likewise) and words are not enough to describe how much better it works. They have a free open-source edition (what we use), but the Enterprise version comes with a lot of nice propitiatory tools. It's just a simple BASH script to install, and both a CLI or GUI method to join the domain. Plus integrating Windows AD groups is simple, for example, I have the option RequireMembershipof AD_GROUP for all the servers I maintain so not just anybody in the domain can login. No more local user or groups to mess with :)

The best part is you can add AD groups to the sudoers file to delegate sudo access and just add users to that AD group. ie, LinuxAdmins

http://www.powerbrokeropen.org/

Meh, just use ldap. No need for any closed source gubbins like Powerbroker. Total overkill.

Adding a free Microsoft AD schema extension on AD gives you everything you need, no need to install *ANYTHING* extra on the Linux side.

Apparently...

Quote:

In Windows Server 2008 R2 you need to install the feature "Subsystem for UNIX-based applications".

Secondly, under Roles > Active Directory Domain Services you need to install "Identity Management for Unix".

Once these are installed each user will have have some extra unix attributes :)

The ldap mapping for /etc/ldap.conf is as follows:

# RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad

Once this is set up, all these sexy features that you say powerbroker gives you are just plain there implicitly, an AD group is just now a bog standard group, so of course you dan use it in sudeors, in *exactly* the same way as any other group on the local box. No additional config files full of obscure settings, just standard OS config.

True, but for use Sys Admins that don't have total AD access and cannot just add the UNIX schema PBIS is a godsend. It's nice having a solution that (in most cases) just works and there is a dedicated team of paid employees behind it.

PBIS is really easy to use...yes it totally takes over the PAM directory but it's mostly just adding the lsass.so module and their documentation is well made.

any company where the unix admins and the windows admins don't co-operate is a shitty place to be.