-   Red Hat (
-   -   Active Directory and RHEL (

griffey 02-13-2013 04:42 AM

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\\" 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" 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:


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


Configure PAM:
run authconfig-tui

Admin Server

Domain: FOO

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

  workgroup = FOO
  password server =
  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 ''
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
(And a whole slew more...)

ipmweb:~ mikeg$ ssh foo\\
foo\'s password: (Enter AD password...)
Last login: Wed Jan 23 12:19:43 2013 from
[FOO\mikeg@pweb6 ~]$ pwd
[FOO\mikeg@pweb6 ~]$ ls
ls: cannot open directory .: Permission denied

acid_kewpie 02-13-2013 05:10 AM

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.

griffey 02-13-2013 07:05 AM

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. :)

chilinski 02-13-2013 12:33 PM

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.

acid_kewpie 02-13-2013 02:17 PM

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.

chilinski 02-13-2013 02:46 PM

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."

acid_kewpie 02-13-2013 03:00 PM

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...?

gdizzle 02-13-2013 03:49 PM


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.


cat /etc/pam.d/system-auth

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required
auth        sufficient nullok try_first_pass
auth        requisite uid >= 500 quiet
auth        sufficent use_first_pass
auth        sufficent cached_login use_first_pass
auth        required

account    required
account    sufficient uid < 500 quiet
account    [default=bad success=ok user_unknown=ignore]
account    [default=bad success=ok user_unknown=ignore] cached_login
account    required

password    requisite try_first_pass retry=3
password    sufficient md5 shadow nullok try_first_pass use_authtok
password    sufficent use_authtok
password    sufficent  cached_login use_authtok
password    required

session    optional revoke
session    required
session    optional  silent
session    [success=1 default=ignore] service in crond quiet use_uid
session    optional skel=/etc/skel  umask=0644 silent
session    required
session    optional

SSH Config:


vim /etc/ssh/sshd_config

KerberosAuthentication yes

SAMBA Config:


vim /etc/samba/smb.conf

workgroup = FOO
password server =
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 =
wins support = no
netbios name = footown

You shouldn't be logging in as: ssh FOO\\" just login as 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.

brandoness 02-14-2013 05:30 PM

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 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

acid_kewpie 02-15-2013 02:04 AM

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.


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.

brandoness 02-17-2013 09:38 PM

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 module and their documentation is well made.

acid_kewpie 02-18-2013 02:28 AM

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

All times are GMT -5. The time now is 10:17 AM.