Hi.

I'm working on a few small scripts aimed at AD<->FDS/RHDS. In my organization we're setting up RHDS as a AD slave, and but do not store any linux user information on the AD side. So from AD we get only limited user information, and have to add things such as posix attributes on the RHDS side. In addition, we'd like to use AD group memberships to create NIS netgroups on the RHDS side, and use this info to control which users get access to which servers.
I've not yet come across scripts that solves these issues, so I'm working on my own scripts.

Btw, for those who's interested, let me briefly describe the functionality of the scripts:
Currently there are three different scripts.
# The first one add posix attributes to users synced over from AD. It can be used in a cron job to automatically add posix attributes to new users.
# The second one create NIS netgroups based on group information defined on the AD side. An example: If you have a AD-group called "hardware-admin", you can create a corresponding netgroup on the RHDS-side, say "ng-hw-admin". The script makes sure that changes made to the AD-group is reflected on the RHDS-side.
#The third script is more of a admin script: It let you create new netgroups, define which netgroup should correspond (i.e. "match") with which AD-group, and stuff like that.

If anyone knows about existing solutions that solves what I'm trying to accomplish please let me know. Otherwise I'll share my scripts on github or something, so that sysadmins with similar setup can review and make use of my code.

Regards,
kenneho

why bother with netgroups?? They're just an old throwback to years ago. What's wrong with using exactly the same group heirarchy as AD?? The only difference by default is that there is no MemberOf attribute on the RHDS side, but that seldom matters.

as for POSIX details, there are plugins for RHDS8.1 (i think) which handle UID / GID assignment. no need to write your own (although someone did where I am and it's a huge scary unweidly beast of a script running on a cronjob to condition a 8.0.4 installation)

1 members found this post helpful.

Does linux recognize AD groups for use in PAM (to control which users have access to which servers)? I really didn't know that! Can you please provide a link to where this is described?

And can the AD groups be used by sudo? Again, please link to this if you know of any information on this..

well it's all abstracted. A good point to appreciate the demarcation is the getent tool. Just like you should already have "getent passwd" listing all local AND ldap users (and possibly, nis, hesiod etc.. if you so desired) running "getent group" SHOULD list all the groups that the given user is in, regardless of where that group information comes from. So PAM and LDAP / AD really know nothing about each other there. The only point at which they DO know about each other is user authentication, not user information, which are really totally seperate pieces of information (e.g. NIS only provides user information (not technically true, but you're nuts if you do anything else with it) and kerberos only provides user authentication. LDAP (via AD) can provide both, but they are not done as a single thing.)

I think I understand. If I'm not mistaking I'll need to tell nss_ldap and pam_ldap how and where to look for such group memberships. For nss_ldap, I'll need to configure /etc/ldap.conf with the "nss_base_group" attribute and possibly also "nss_map_<something>". Correct? If correct, do you happen to have an example of which attribute mappings must be in place for it to work? I've tried different mappings, but none seems to work..

yeah that's about it for nss_ldap. you should see plenty of examples in /etc/ldap.conf for a number of different ldap servers, including MSSFU on AD. We use RHDS where I work and had to make no changes at all to the mappings side of ldap.conf, in fact nothing that authconfig doesn't handle.

Again though, pam won't know about group memberships, it doesn't need to. PAM will do authentication "Is dave really dave?" but the user info is then part of the authorization stage - "is dave allowed to log in?" the two questions don't need to know the answer to the other. PAM usually does match the connections between these two, getting the authorization sorted via pam_access, but the source information is not down to it, but nss. There are ways to push this responsibility more directly to a PAM/LDAP interaction for the membership stuff, i think you can add extra options in the pam_ldap config for example, but it's not the normal way to do it.

Thanks. I'm a bit lost when it comes to mapping attributes though, and I'm hoping you can help me along... Running authconfig and then "getent group" returns any posix groups defined in the RHDS, but no AD-groups (i.e groups synced over from AD). So I'm guessing that my linux box don't recognize the attributes found those groups objects, and will need some attribute mapping. This is a typical AD group object found on my RHDS:
Running "getent group" returns nothing, so I've tried different mapping in /etc/ldap.conf, but haven't found the combination that works. Let me first explain my understanding of this mapping thing: When I have a entry like this, it means that when linux tries to look up "posixGroup" entries, it instead does a lookup of the "ntGroup" attribute:
So what need to be done is that I need to configure a number of "nss_map_objectclass <linux-objectclass-name> <AD-object-objectclass-name>", and likewise for nss_map_attribute. Is this correct? If so, how do I identify which attributes need to be mapped?


- kenneho

OK, you don't seem to have installed MSSFU going by that output. There is mssfu examples in most ldap.conf

http://www.microsoft.com/downloads/d...n#Requirements

additional info here https://help.ubuntu.com/community/Ac...Query:%20Linux

I just talked to our AD guy, and found that we're running Windows Server 2009. Do you know if that MS-SFU extension really a Windows Server 2003 extension, while it is built into Windows Server 2008 by default?

Anyway, how does that MS-SFU functionality work - are attributes such as home directory and so on defined on the AD side, then synced over to RHDS, and then the linux clients use the attribute mappings to make sense of the MS-SFU attributes? So in other words, all I'd have to do is to have the AD admin populate those attributes, then add UID/GUI to the user objects on the RHDS side (by using the plugin you mentioned), and then authconfig will do the rest?

I'm sorry if I ask a lot of basic questions, but I'm quite new to AD and RHDS<==>AD integration.

Btw, where does MSSFU fit in this picture? As far as I know MSSFU is a posix extension to the AD schema, allowing AD to store posix attributes. But posix attributes aren't synced over to RHDS (I'm using RHDS's Windows Sync plugin), so how can you make use of these attributes? If you could outline the basic steps in our setup that would be really great...

Well my original suggestion was to not bother using RHDS at all.

Ah, I must have misunderstood. Sorry. I thought that the setup you described were a AD<==>RHDS setup with users and groups synced over that link, and that you configured your linux clients to user the groups directly rather than converting them to netgroups like I suggested.

But you're suggesting dropping RHDS altogether, and simply point the linux clients directly to AD. I see....That would propably be the best and simplest setup. We're running Windows Server 2008, so we already have access to "Subsystem for UNIX-based Applications" (SUA).

I'll look into this. Thanks for the tip. Didn't know that linux clients could talk directly to AD to get group membership info etc.

Where I am no, there was a really really odd rational that despite having a full AD domain, linux clients needed to authenticate against a linux server, and so RHDS was brought in, and it syncs and it's horrible (the syncing bit, as a server in it's own right, it's good). As AD alrady provides an LDAP interface by default it seemed strange to not just use it for simplicity. Now most things are being removed from a monolithic RHDS cluster and given their own small ldap servers, some via "application mode" AD, whatever that's officially called. Why does LDAP always tend to get pushed into the LDAP server? People have no concern about having a bunch of HTTP servers etc... why assume you need to hold all unrelated data centrally just because it requires LDAP access to it?

I've gotten our linux boxes to fetch users and user groups directly from AD (as you've already read in this thread: http://www.linuxquestions.org/questi...=1#post3849268). It looks very promising! It is a lot simpler than setting up our own RHDS server (with AD-syncing and everything).

There's still a few issues, like that of defining groups of computers, but I feel we've come a long way allready.

Thanks for the help so far.

- kenneho