New accounts are generated only in AD so will get a UID based on SID. If you create local
accounts on Unix then you need to ensure no overlap with AD global accounts. Since we
started our AD based account UIDs above 2^32 we have plenty of space below that for local
account UIDs. Same for GIDs.
I am not a windows person and this is from memory. Someone correct me if I am wrong.
Windows SID has a domain part + a RID. Our scheme was only for a single AD domain so was
based on RID (32 bits?) If you need more than 1 AD domain, you should use SID otherwise
you may not have unique UIDs.
I like the idea of storing a unique UID in the AD attribute for a user. Using sssd to do
it means you have to define the same mapping on each sssd implementation. This means you
have more chance of getting it wrong with a typo or editing stuff up and that means you
could have users creating files with the wrong UID that then need to be cleaned up. The
other problem is users having an incorrect UID reading files they should not have access
to.
Can’t help with automount yet, sorry.
Greg
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Longina Przybyszewska
Sent: Thursday, 14 February 2013 9:24 PM
To: 'End-user discussions about the System Security Services Daemon'
Subject: Re: [SSSD-users] migrating from NIS to AD+kerberos
UID/GID allocating – is my missing link.
We need to renumber at least UIDs as they overlap across NIS domains.
As all users have in advance AD account it seems obvious to me to generate posix uid based
on AD IDs.
…Or just assign Linux UIDs numbers during migrating.
What about making new accounts in the future – how the uid would be generated for Linux
Users?
Do we need a special group say ‘linuxusers’ then make a new template for new account in
the group?
Can AD make for us also continuously unique POSIX UIDs when creating the new account?
I don’t know YET much about MSWin identification process – sorry for very basic questions
;).
I understand that the approach with RID (real ID ??) mapping achieves consistent name
mapping across all types file servers –
am I right?
But maybe in sssd context it doesn’t make sense – as Ondrej points out.
Ondrej, if you say “sssd can serve automount maps for automounter” – that means sssd can
read ldap automounter map, and do
it automatically if we define autofs service in [nss] but first automounter has to know
about sssd and link to sssd libraries?
Alternative, now we have to convert NIS auto.home maps to ldap format, and load them to
AD (???), then reconfigure automounter to
ask AD for entry instead of NIS.
By the way how do I find what class/attributes I want in AD-ldap for autofs?
Longina
From:
sssd-users-bounces@lists.fedorahosted.org<mailto:sssd-users-bounces@lists.fedorahosted.org>
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Ondrej Valousek
Sent: 14. februar 2013 09:22
To: End-user discussions about the System Security Services Daemon
Subject: Re: [SSSD-users] migrating from NIS to AD+kerberos
Few comments:
- Uid/gid renumbering is a pain that should be avoided.
- I prefer using RFC2307 attributes rather than relying on some fancy RID mapping. I like
to have things under my control.
- sssd can serve automount maps for automounter - it is not mature yet, but will be
(hopefully). Mean time, automounter can talk to AD on its own, so it is not a big deal to
get rid of NIS right now.
Ondrej
On 02/14/2013 08:40 AM, Greg.Lehmann@csiro.au<mailto:Greg.Lehmann@csiro.au> wrote:
We started on this path several years ago when an IT consolidation happened across all the
divisions which had previously done their own thing in IT. We had multiple NIS domains and
recognised it was getting a bit old as a technology. The main project driver was file
server consolidation, and the NIS part of the project was not funded initially. Because
the NIS domains had historically grown independently we had overlapping user name space as
well as overlaps in uid and gid. The first part of the work consisted of making those 3
spaces unique as it was a pre-requisite for file server consolidation. I don't think
we had overlap in group names, but it was a while ago now.
We decided on an HR identifier as the userid as it was unique and it was already being
used on Windows (which had come along well after Unix) and was already set up as a single
domain across the entire organisation. In the uid and gid space we decided on renumbering
all existing users and groups to a range above all those currently in use, and chose above
2^32.
Userids were renamed first. Unix groups were added into AD as security groups. The
numbering scheme was a formula based on the Windows SID for both group and user. All files
on fileservers were renumbered before fileserver consolidation. We were not really happy
with any of the existing replacements for NIS around 6 years ago so did some NIS
consolidation as required. We did not populate AD with uidNumber or gidNumber at that
time, but did experiment a bit with it on a few users and groups with vanilla ldap. NIS
servers were setup to nightly look up a global passwd and group file which was generated
from Windows AD using the formula based uids and gids. Account changes in AD would then be
reflected as updates in NIS. This was of course batch only. This was made hourly
eventually to handle group membership changes which could happen through the day. HR
processes generally happened only nightly.
A few years later we updated our HR processes to populate and maintain the extra AD
attributes, like uidNumber, gidNumber, shell, unixhomedir, gecos. Just recently we have
added some extra processes to manage the gidNumber, so now have all the pieces in place to
use AD as our single source of information.
sssd will now likely be the final piece that lets us get rid of NIS. It will probably be a
gradual shift as older Linux hosts drop off and new ones replace them. We will be running
both schemes for a while in parallel and since they have the same information it won't
be a problem.
The one thing we have yet to really address is automount maps and I suspect we will have
to turn on NIS in AD to get that part to work properly, or use something like puppet to
manage flat file versions of automount maps.
Hope this helps.
Greg
-----Original Message-----
From:
sssd-users-bounces@lists.fedorahosted.org<mailto:sssd-users-bounces@lists.fedorahosted.org>
[mailto:sssd-users-
bounces@lists.fedorahosted.org<mailto:bounces@lists.fedorahosted.org>] On Behalf Of
Longina Przybyszewska
Sent: Wednesday, 13 February 2013 9:28 PM
To: End-user discussions about the System Security Services Daemon
(sssd-users@lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org>)
Subject: [SSSD-users] migrating from NIS to AD+kerberos
As a continuation of sssd evaluatin we plan migration from NIS to
Active Directory+Kerberos.
Now again the question - what is the best approach and practice to
migrate users ?
AD administrators enabled SFU, and we got extended schema with POSIX
attributes.
I guess there might be some free or commercial tools for extracting
data from NIS and loading into AD -ldap objects.
Our Linux users are dispersed in separated NIS domains, and all have
AD account beside the entry in NIS.
Home directories are NFS-mounted with autofs from Linux storage
server but some users access MSWin storage with smbclient.
Can you share experiences on assigning POSTFIX attributes in SSSD
context, best practice etc..?
We would not like activate NIS services on AD server for migration.
Longina
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org<mailto:sssd-users@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users