migrating from NIS to AD+kerberos

[Longina Przybyszewska]

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

[Jakub Hrozek]

On Wed, Feb 13, 2013 at 11:28:17AM +0000, Longina Przybyszewska wrote:
> 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..?

I assume you meant POSIX
                                    attributes.
> We would not like activate NIS services on AD server for migration.
>
> Longina

Hi,

I don't know any tools to migrate users from NIS to AD myself, maybe
others on this list do.

In general starting with SSSD 1.9 you don't need to enable SFU and
populate the POSIX attributes at all, you can just use the SSSD
ID-mapping feature to map AD SIDs to UNIX IDs automatically. I'm not
sure if that's a good idea in your particular case, because most
probably the mapped attributes would be different than those you have
manually created in NIS. Just saying.

[Ondrej Valousek]

For populating the posix attributes you can use the NIS migration tool that comes with IDMU. You do not have to activate NIS afterwards. Or 
write yourself some fancy shell/perl script (like I did) if you want more control of what is happening.

Ondrej

On 02/13/2013 12:28 PM, Longina Przybyszewska wrote:
> 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Greg Lehmann]

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: [e-mail] [mailto:sssd-users-
> [e-mail]] On Behalf Of Longina Przybyszewska
> Sent: Wednesday, 13 February 2013 9:28 PM
> To: End-user discussions about the System Security Services Daemon
> ([e-mail])
> 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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Ondrej Valousek]

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, [e-mail] 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: [e-mail] [mailto:sssd-users-
> > [e-mail]] On Behalf Of Longina Przybyszewska
> > Sent: Wednesday, 13 February 2013 9:28 PM
> > To: End-user discussions about the System Security Services Daemon
> > ([e-mail])
> > 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
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Longina Przybyszewska]

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: [e-mail] [mailto:[e-mail]] 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, [e-mail] 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: [e-mail] [mailto:sssd-users-

[e-mail]] On Behalf Of Longina Przybyszewska

Sent: Wednesday, 13 February 2013 9:28 PM

To: End-user discussions about the System Security Services Daemon

([e-mail])

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

[e-mail]

https://lists.fedorahosted.org/mailman/listinfo/sssd-users

_______________________________________________

sssd-users mailing list

[e-mail]

https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Jakub Hrozek]

On Thu, Feb 14, 2013 at 11:24:23AM +0000, Longina Przybyszewska wrote:
> 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.

If you're renumbering the UIDs (and by extension changing the file
permissions) anyway, you might as well go with the ID mapping feature
completely.
> …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?

I'm not sure what you mean by "across all types of file servers" but
the mapping should be consistent, yes.
> 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?

See http://jhrozek.livejournal.com/2500.html for example.
> 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

[Ondrej Valousek]

On 02/14/2013 01:02 PM, Jakub Hrozek wrote:
> > 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?
>
> Seehttp://jhrozek.livejournal.com/2500.html  for example.

Good document, thanks Jakub!
Unfortunately, Jakub assumes LDAP server w/ RFC2307bis schema loaded - which is not the AD case. In AD you have 2 options:
1. Extend the AD schema to contain the necessary RFC2307bis attributes
2. store automount maps using RFC2307 attributes, and do some mapping on the sssd side.

Maybe Jakub will add this AD specific stuff in the document at some stage, too.
Ondrej

[Aaron Grewell]

On Feb 14, 2013 4:22 AM, "Ondrej Valousek"  wrote:
> >
>
> Good document, thanks Jakub!
> Unfortunately, Jakub assumes LDAP server w/ RFC2307bis schema loaded -

which is not the AD case. In AD you have 2 options:
> Extend the AD schema to contain the necessary RFC2307bis attributes
> store automount maps using RFC2307 attributes, and do some mapping on

the sssd side.
> Maybe Jakub will add this AD specific stuff in the document at some

stage, too.
> Ondrej

That depends on the version of Windows used on your DC's. RFC2307bis
attributes have been in every version since 2003R2.

[Ondrej Valousek]

Nope. Microsoft did not include all of them. For example, the automount* attributes (as per RFC2307bis) are not included in any version of 
AD schema I am aware of....
Ondrej

On 02/14/2013 04:28 PM, Aaron Grewell wrote:
> That depends on the version of Windows used on your DC's. RFC2307bis attributes have been in every version since 2003R2.

[Longina Przybyszewska]

> > I understand that the approach with RID (real ID ??) mapping achieves 
> > consistent name mapping across all types file servers – am I right?
> I'm not sure what you mean by "across all types of file servers" but the mapping should be consistent, yes.

We have diverse file servers  Oracle Sun 7000(zfs), Ubuntu server( in test NFS4+sssd ), SAN ;

For example  Zfs  mapping algorithm (using window-sid) is not the same as client's with sssd-ad so,
 we do not get the same user on both ends.

If we would like to have common storage for all possible clients(linux, mac, win), to give user access to  the same files 
simultaneously - we need to have  common and unique mapping between windows sid and unix uid/gid.

In my understanding we can achieve it only if Posix uid/gid are  built from windows sid.
Only then   from window client and linux client we get the same uid on the file server.

Maybe I am wrong - please, enlighten me.

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

See http://jhrozek.livejournal.com/2500.html for example.
> 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

_______________________________________________
sssd-users mailing list
[e-mail]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Greg Lehmann]

I was not aware zfs could do a uid mapping. If you understand what it is doing then perhaps you can configure sssd to use the same scheme. I have not used that feature either since we decided on our mapping over 6 years ago. I think it makes sense to use AD to store all the password file fields in AD. Not everybody has the luxury of cooperative AD administrators, so understand others having to work around it. SAN is not a fileserver by itself.
> -----Original Message-----
> From: [e-mail] [mailto:sssd-users-
> [e-mail]] On Behalf Of Longina Przybyszewska
> Sent: Friday, 15 February 2013 1:02 AM
> To: 'End-user discussions about the System Security Services Daemon'
> Subject: Re: [SSSD-users] migrating from NIS to AD+kerberos
> > > I understand that the approach with RID (real ID ??) mapping
>
> achieves
> > > consistent name mapping across all types file servers – am I right?
> > I'm not sure what you mean by "across all types of file servers" but
>
> the mapping should be consistent, yes.
>
> We have diverse file servers  Oracle Sun 7000(zfs), Ubuntu server( in
> test NFS4+sssd ), SAN ;
>
> For example  Zfs  mapping algorithm (using window-sid) is not the same
> as client's with sssd-ad so,
>  we do not get the same user on both ends.
>
> If we would like to have common storage for all possible clients(linux,
> mac, win), to give user access to  the same files
> simultaneously - we need to have  common and unique mapping between
> windows sid and unix uid/gid.
>
> In my understanding we can achieve it only if Posix uid/gid are  built
> from windows sid.
> Only then   from window client and linux client we get the same uid on
> the file server.
>
> Maybe I am wrong - please, enlighten me.
>
> Longina
> > > 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?
> > >
>
> See http://jhrozek.livejournal.com/2500.html for example.
> > 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
>
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Greg Lehmann]

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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, [e-mail] 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: [e-mail] [mailto:sssd-users-

[e-mail]] On Behalf Of Longina Przybyszewska

Sent: Wednesday, 13 February 2013 9:28 PM

To: End-user discussions about the System Security Services Daemon

([e-mail])

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

[e-mail]

https://lists.fedorahosted.org/mailman/listinfo/sssd-users

_______________________________________________

sssd-users mailing list

[e-mail]

https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Ondrej Valousek]

That's the beauty of following standards. RFC2307 standard tells you how to do the mapping. SSSD honors RFCs (as well as any other appliance 
I am aware of) so you do not have to do any fancy mapping on your own at all - it just works consistently everywhere.

Ondrej

On 02/14/2013 06:22 PM, [e-mail] wrote:
> 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.

[Longina Przybyszewska]

Thanks for all the comments- all of them are very helpful...

Longina

From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 14. februar 2013 18:23
To: [e-mail]
Subject: Re: [SSSD-users] migrating from NIS to AD+kerberos

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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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, [e-mail] 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: [e-mail] [mailto:sssd-users-

[e-mail]] On Behalf Of Longina Przybyszewska

Sent: Wednesday, 13 February 2013 9:28 PM

To: End-user discussions about the System Security Services Daemon

([e-mail])

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

[e-mail]

https://lists.fedorahosted.org/mailman/listinfo/sssd-users

_______________________________________________

sssd-users mailing list

[e-mail]

https://lists.fedorahosted.org/mailman/listinfo/sssd-users