Red HatThis forum is for the discussion of Red Hat Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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\\firstname.lastname@example.org" 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 email@example.com" 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:
130.126.xx.xxx pweb6.dept.foo.edu CCSG-PWEB6.ad.foo.edu
Admin Server ad.foo.edu
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
(And a whole slew more...)
ipmweb:~ mikeg$ ssh foo\\firstname.lastname@example.org
foo\email@example.com's password: (Enter AD password...)
Last login: Wed Jan 23 12:19:43 2013 from ipmweb.dept.foo.edu
[FOO\mikeg@pweb6 ~]$ pwd
[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.
Last edited by chilinski; 02-13-2013 at 12:36 PM.
Reason: added info
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, 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
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
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.
Last edited by acid_kewpie; 02-15-2013 at 02:31 AM.
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.