Thanks for the wonderful explanation. It did helped me to come up with
something more informative.
I was going through Windows Sync and want to know about these points:
1.What all changes has to be done on Active Directory Server? Just to check
risk and feasibility factor.
2. Say, I follow Red Hat Directory Server Guide. Do our 389 do contain every
little stuff which RHDS has.Please clarify.
What difference these servers have?
3. Can I follow the complete RHDS Docs to set my Fedora DS to work with
ADS?What section may be missing?
4. What are the overall steps (just in points) to setup Fedora DS sync with
ADS with Few ADS users synched to have permission to access the Linux
I do got 2 links:
1. Restrictively allowing only ISST Sysadmins on Fedora DS(synchronized with
ADS) to access the certain resources(Linux Machine) : *
2.Check ADS <=> Fedora DS Synchronization for User Creation/Deletion:
Do yu think they are enough for me to setup as my requirements.
Do help me with detail docs if yu have any so that I can help myself with
On Mon, Jan 4, 2010 at 7:10 PM, Kenneth Holter <kenneho.ndu(a)gmail.com>wrote:
Well, I don't have any documentation on the posix/netgroup type
But I can try to outline our approach:
In the AD LDAP tree, we have created an organizational unit (OU) named
"linux" (or something like that). Under this OU we have two OUs, named
"users" and "groups". Under these OU's we've moved all users
and groups that
are to be synced over to our Red Hat Directory Server (RHDS, which is
basically the same as FDS).
On the RHDS, we've done this: Using the Windows Sync (
plugin, we've defined that all entries under the "linux" OU on AD should
synced over to RHDS. Windows Sync basically copies those entries from AD.
In addition, we have a few script running on the RHDS server. On script
adds posix attributes to users that have been synced over from AD to RHDS.
Another script populates NIS netgroups based on AD groups. Let me explain:
Say we have a AD group called "linux-admins", and that it's placed under
"groups" OU (as explained above) as is thus synced over to the RHDS. On the
RHDS side, we have a similar NIS netgroup called for example
"netgroup-linux-admins". Our script reads the "linux-admins"
info, and makes sure that the "netgroup-linux-admins" is updated with the
same membership info. This way we can rely on the AD admins to manage group
memeberships on the RHDS side.
The NIS netgroup information can the be used for defining which groups of
users can access which groups of servers (note that we're going to put
server names into netgroup too), by configuring PAM to allow access based on
netgroup membership. For example, we can define that users that are members
of "netgroup-linux-admins" will have access to all servers. Furhtermore, we
can use the same netgroups to define sudo privileges for groups of users.
For the "netgroup-linux-admins", they will typically be given full sudo
access on all servers.
I hope this made some sense. Let me know if you want me to elaborate on
some of the points.
Btw, the most relevant info I've found on setting this thing up is the RHDS
), and the 389 web
On Mon, Jan 4, 2010 at 12:40 PM, Ajeet S Raina <ajeetraina(a)gmail.com>wrote:
> Hello Kenneho,
> Thanks for the quick response. I appreciate your helpful words on these
> I would be thankful if yu can provide me with the tutorials or documents
> or links which you followed for the same setup.
> May I know what should be approach for syncing ADS to Fedora DS?
> Any step by step approach for the sa
> On Mon, Jan 4, 2010 at 2:37 PM, Kenneth Holter <kenneho.ndu(a)gmail.com>wrote:
>> We're currently working on a similar setup.
>> Regarding your first question: Using the Windows Sync plugin on the FDS
>> you sync specific users from AD over to FDS. Just move your sysadmin users
>> to an LDAP organization unit (OU), and sync that over to FDS. Next, you'll
>> need to add posix attributes (user ID, group ID, home directory, etc) to
>> these users on the FDS side. You can create simple scripts for doing this.
>> In our setup, we're going to use groups defined on the AD side as basis for
>> NIS netgroups on linux, so that we can control access to and sudo privileges
>> on linux servers based on these groups. This adds to the complexity, but
>> lets us manage users and access from the AD side.
>> When you delete a user on the AD side, it will get deleted on the FDS
>> side too.
>> Kenneth Holter
>> On Tue, Dec 29, 2009 at 5:41 PM, Ajeet S Raina
>>> I have a certain query regarding the following structure:
>>> Active Directory Server
>>> Fedora Directory Server <=> Client(Linux | Fedora | Ubuntu |
Solaris | HP)
>>> Let me explain you what I want:
>>> 1.There is a company Active Directory Server under domain
>>> intinfra.com.As <http://intinfra.com.as/>
of now there are limited
>>> Windows Desktop Machine under that domain.I have few Linux / Unix Machines
>>> which I want to authenticate through ADS(which are presently not under
>>> ADS).Why? Becoz' everytime I need to delete the users whenver they leave
>>> project.Thats Cumbersome.
>>> So what I want is Setup Fedora DS(Wonder if We can do that without
>>> Fedora DS).Now I can ads join to Fedora DS(I have administrative privileges
>>> for ADS).What I really want to know is:
>>> If I join Fedora DS to ADS then all employee can login to the Linux
>>> Machine through their login credentials. I dont want that to happen.We have
>>> 3000 employee in intinfra Domain but We are only 30 Admins. I only want
>>> those 30-40 admins to login restrictly.Is it possible to restrict at
>>> FedoraDS level.
>>> 2.Say, I joined ADS and fedora DS and say after 30 days one of System
>>> Admin left the company.So his name will be removed from ADS. Is it possible
>>> that ADS and Fedora DS are synchronized in such a way that a user whose name
>>> gets deleted in ADS, gets deleted too from fedora .Do fedora DS has the
>>> capability to synchronize to ADS everytime.
>>> Pls Suggest.
>>> 389 users mailing list
>> 389 users mailing list
> ”It is not possible to rescue everyone who is caught in the Windows
> --Make sure you are on solid Linux ground before trying.”
389 users mailing list
”It is not possible to rescue everyone who is caught in the Windows
--Make sure you are on solid Linux ground before trying.”