Hello,
On 02/12/2013 03:09 PM, Longina Przybyszewska wrote:
Thanks, for beginning a very interesting thread!
We are planning migration from NIS to Active Directory+Kerberos.
I run sssd as evaluation project - and I really love it ...so far ;) - this
is obviously the road ahead.
Have a question for those who tried it - What is the best approach and practice
to migrate users in the most possible transparent (for users) way?
I think I would try a dual-stack configuration on the client machines. A
pam.d configuration that would first try AD, then NIS. The same would go
for NSS - first try SSSD then NIS. This would allow users who do not yet
have an account in AD to log in against NIS.
All our (Linux) users have AD account beside entry in NIS and usually a home
directory
NFS-mounted from Linux storage server.
Users can also access MSWin storage .
So... if they have an account in AD... what's missing from the
migration? Their NSS data, like UID, GID, shell and homedir?
Do you know any helpful migration tools?
I mean scripts for extracting data from NIS and putting into AD's ldap.
Not sure, perhaps using ldapmodify with an admin account against AD
would do the job?
For joining computers to AD we use a 'msktutil' .
Wow! That's something new to me. We use samba3's tools but that works a
little bit fishy and does not provide a system keytab. I will check this
out and probably we will even switch to that. Thank you.
Until now we have got ( for testing) a container ' LinuxComputers' in AD to
put all Linuxer there, when joining domain.
That's pretty valid. We use a machine naming convention that tells
whether it's a Windows or Unix machine.
We use FAI and puppet for automated installation and configuration.
FAI is pretty powerful. My colleagues are using it for machine
deployment. It was interesting to learn from them that FAI is using
cfengine (version 2, but still) in a script-like fashion to setup its
environment and I was told that you can write your own rules to extend it.
What services do you configure with Puppet?
I can not see why we should use AD's GroupPolicy for computers.
Well, I can see some benefits if that was possible. AD's Group Policy
has already implemented inheritance of settings and you can stop
inheritance. As our company's group policies already contain a lot of
useful information, it would be a valid source of information that we
could then put on our Linux machines. Although we use DHCP for providing
the proxy servers, some companies enforce proxy through the group policy
and we could then use this information to configure our Linux clients.
I also believe that the AD Group Policies are easily extendable and
could well serve as a store for our variables which we needed to move to
text files. This won't happen.
Cheers,
Ballock
--
Mailing list: https://launchpad.net/~enterprise-ubuntu
Post to : enterprise-ubuntu@lists.launchpad.net
Unsubscribe : https://launchpad.net/~enterprise-ubuntu
More help : https://help.launchpad.net/ListHelp
