Hi all,
We're getting to a point in our linux environment where it's starting to be cumbersome to keep shadow and passwd-files up-to-date for the users to login on each computer. Scripts can only get us so far. 8-/
I've looked a bit into central login systems for linux, and NIS and LDAP seem to be prevalent. NIS being the simpler-to-setup solution for small to medium networks as I understand it, while LDAP is the more modern and scalable solution. See eg http://www.yolinux.com/TUTORIALS/NIS.html or http://sysadmin-notepad.blogspot.se/2013/06/nis-server-setup-on-rhelcentos.h....
NIS-wise, what is a "small to medium network"? We have currently about 20-30'ish linux clients and servers, and the environment is not likely to increase much beyond this point. Is a 30ish-computer setup, a small network?
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
Hi Sorin we use here LDAP authentication and mail-control since more than 10 years. At that time, we did the conversion from passwd/shadow to LDAP using the tools on http://www.padl.com/download/ which are still available, probably in a newer version...
To represent a person or a service in LDAP we use the objectclasses: objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: mailRecipient
To represent a mail user for postfix we use the objectlcasses:
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: qmailUser
To represent a Domain which we serve mail-wise we use the objectclasses: objectClass: qmailControl objectClass: top
We also have developed an LDAP via Web Interface, which we use exclusively for LDAP administration.
We have two LDAP servers, syncronized via syncrepl.
suomi
On 2014-01-28 10:02, Sorin Srbu wrote:
Hi all,
We're getting to a point in our linux environment where it's starting to be cumbersome to keep shadow and passwd-files up-to-date for the users to login on each computer. Scripts can only get us so far. 8-/
I've looked a bit into central login systems for linux, and NIS and LDAP seem to be prevalent. NIS being the simpler-to-setup solution for small to medium networks as I understand it, while LDAP is the more modern and scalable solution. See eg http://www.yolinux.com/TUTORIALS/NIS.html or http://sysadmin-notepad.blogspot.se/2013/06/nis-server-setup-on-rhelcentos.h....
NIS-wise, what is a "small to medium network"? We have currently about 20-30'ish linux clients and servers, and the environment is not likely to increase much beyond this point. Is a 30ish-computer setup, a small network?
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of anax Sent: den 28 januari 2014 12:24 To: centos@centos.org Subject: Re: [CentOS] NIS or not?
Hi Sorin we use here LDAP authentication and mail-control since more than 10 years. At that time, we did the conversion from passwd/shadow to LDAP using the tools on http://www.padl.com/download/ which are still available, probably in a newer version...
To represent a person or a service in LDAP we use the objectclasses: objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: mailRecipient
To represent a mail user for postfix we use the objectlcasses:
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: qmailUser
To represent a Domain which we serve mail-wise we use the objectclasses: objectClass: qmailControl objectClass: top
We also have developed an LDAP via Web Interface, which we use exclusively for LDAP administration.
We have two LDAP servers, syncronized via syncrepl.
suomi
On 2014-01-28 10:02, Sorin Srbu wrote:
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Thank you. Can I use just the user authentication (uid/pwd) part and skip the whole mail-cocacho, or do these two go hand in hand when using LDAP?
-- //Sorin
Hi Sorin of course: you may omit the mail cocacho and realize only the authentication cocacho in LDAP. For us, however, it has proven to be most advantageous to have both on LDAP. You may also select to do first the authentication in LDAP and later on, if you are familiar with LDAP, realize the mail.
suomi
On 2014-01-28 13:32, Sorin Srbu wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of anax Sent: den 28 januari 2014 12:24 To: centos@centos.org Subject: Re: [CentOS] NIS or not?
Hi Sorin we use here LDAP authentication and mail-control since more than 10 years. At that time, we did the conversion from passwd/shadow to LDAP using the tools on http://www.padl.com/download/ which are still available, probably in a newer version...
To represent a person or a service in LDAP we use the objectclasses: objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: mailRecipient
To represent a mail user for postfix we use the objectlcasses:
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: qmailUser
To represent a Domain which we serve mail-wise we use the objectclasses: objectClass: qmailControl objectClass: top
We also have developed an LDAP via Web Interface, which we use exclusively for LDAP administration.
We have two LDAP servers, syncronized via syncrepl.
suomi
On 2014-01-28 10:02, Sorin Srbu wrote:
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Thank you. Can I use just the user authentication (uid/pwd) part and skip the whole mail-cocacho, or do these two go hand in hand when using LDAP?
-- //Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of anax Sent: den 28 januari 2014 13:45 To: centos@centos.org Subject: Re: [CentOS] NIS or not?
Hi Sorin of course: you may omit the mail cocacho and realize only the authentication cocacho in LDAP. For us, however, it has proven to be most advantageous to have both on LDAP. You may also select to do first the authentication in LDAP and later on, if you are familiar with LDAP, realize the mail.
Cool. Thanks!
-- //Sorin
2014-01-28 Sorin Srbu Sorin.Srbu@orgfarm.uu.se
Hi all,
We're getting to a point in our linux environment where it's starting to be cumbersome to keep shadow and passwd-files up-to-date for the users to login on each computer. Scripts can only get us so far. 8-/
I've looked a bit into central login systems for linux, and NIS and LDAP seem to be prevalent. NIS being the simpler-to-setup solution for small to medium networks as I understand it, while LDAP is the more modern and scalable solution. See eg http://www.yolinux.com/TUTORIALS/NIS.html or
http://sysadmin-notepad.blogspot.se/2013/06/nis-server-setup-on-rhelcentos.h... .
NIS-wise, what is a "small to medium network"? We have currently about 20-30'ish linux clients and servers, and the environment is not likely to increase much beyond this point. Is a 30ish-computer setup, a small network?
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
-- BW, Sorin
# Sorin Srbu, Sysadmin # Uppsala University # Dept of Medicinal Chemistry # Div of Org Pharm Chem # Box 574 # SE-75123 Uppsala # Sweden# # Phone: +46 (0)18-4714482 # Visit: BMC, Husargatan 3, D5:512b
# Web: http://www.orgfarm.uu.se
# () ASCII ribbon campaign - Against html E-mail # /\ # # This message was not sent from an iProduct! # # MotD follows: # Artificial Intelligence: the art of making computers that behave like the ones in movies. -Bill Bulko
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Use IPA. It combines LDAP with Kerberos, a server-client environment is easily setup and the documentation (RHEL deployment) is very helpful.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Darod Zyree Sent: den 28 januari 2014 13:00 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Use IPA. It combines LDAP with Kerberos, a server-client environment is easily setup and the documentation (RHEL deployment) is very helpful.
Thank you. I'll look it up.
LDAP and Kerberos though. That does sound a lot like Microsoft Active Directory. 8-)
-- //Sorin
On 1/28/2014 4:45 AM, Sorin Srbu wrote:
Use IPA. It combines LDAP with Kerberos, a server-client environment is
easily setup and the documentation (RHEL deployment) is very helpful.
Thank you. I'll look it up.
LDAP and Kerberos though. That does sound a lot like Microsoft Active Directory.8-)
--
FreeIPA provides an open source Active Directory equivalent. its pretty easy to setup a simple directory server, and it can expand to be an enterprise-wide directory. it allows both linux and windows computers to participate in the authentication domain.
yes, its basically LDAP and Kerberos, with a management suite.
On 01/29/2014 09:44 PM, John R Pierce wrote:
On 1/28/2014 4:45 AM, Sorin Srbu wrote:
Use IPA. It combines LDAP with Kerberos, a server-client environment is
easily setup and the documentation (RHEL deployment) is very helpful.
Thank you. I'll look it up.
LDAP and Kerberos though. That does sound a lot like Microsoft Active Directory.8-)
--
FreeIPA provides an open source Active Directory equivalent. its pretty easy to setup a simple directory server, and it can expand to be an enterprise-wide directory. it allows both linux and windows computers to participate in the authentication domain.
yes, its basically LDAP and Kerberos, with a management suite.
I've been following this with interest, about once every 6 months this topic is raised. From my observation there now appear to be two possible solutions: 1. FreeIPA - gives genuine LDAP and Kerberos with some web front end management 2. Samba4 - gives a windoze interoperable AD implementation, not sure how "standards" based this is, it is engineered to follow micro$oft's implementation and work well for windoze clients.
Issues: option 1 will work very well with linux clients, considerable work to get all the required windoze functions working option 2 - early days of implementation, CentOS does not yet support the complete package needed for full windoze integration. decent documentation in the form of a howto for server, linux client, windoze (many versions), iOS and Android are not yet out there. As evidenced by the few that have "been there, done that" they ALL say it takes A LOT of time and effort, and getting all the bits involved, just right, is difficult.
My appeal to those that have been there - how do we get all the tiny details that matter, documented, so that the black art / trial and error (months of) can be eliminated. Living in the hope that this will one day be accessible to the rest of us that cannot afford the many months of trial and error and frustration. BTW, I have tried openLDAP, 389 implementations, samba3 and a trial of samba4, all with limited success - there were always a few combinations that failed to work for me and I do not have the resources (mainly time/$$) to just keep trying.
--On Tuesday, January 28, 2014 12:45:09 PM +0000 Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
LDAP and Kerberos though. That does sound a lot like Microsoft Active Directory. 8-)
No, the other way around. Microsoft Active Directory sounds a lot like LDAP and Kerberos. Credit where credit is due ...
;)
Devin
No, the other way around. Microsoft Active Directory sounds a lot like LDAP and Kerberos. Credit where credit is due ...
No, the other way around. Microsoft Active Directory implements an LDAP like directory accessible interface for its own directory.
Calling Active Directory "LDAP" is like calling vim `echo "xx" > yy`. If you are unaware of all the moving parts under Active Directory, it might prove very informative to explore it.
Credit where credit is due ...
jlc
brilliant. ....
exactly. On 1/29/2014 2:24 PM, Joseph L. Casale wrote:
No, the other way around. Microsoft Active Directory sounds a lot like LDAP and Kerberos. Credit where credit is due ...
No, the other way around. Microsoft Active Directory implements an LDAP like directory accessible interface for its own directory.
Calling Active Directory "LDAP" is like calling vim `echo "xx" > yy`. If you are unaware of all the moving parts under Active Directory, it might prove very informative to explore it.
Credit where credit is due ...
jlc _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 1/29/2014 2:24 PM, Joseph L. Casale wrote:
No, the other way around. Microsoft Active Directory implements an LDAP like directory accessible interface for its own directory.
Calling Active Directory "LDAP" is like calling vim `echo "xx" > yy`. If you are unaware of all the moving parts under Active Directory, it might prove very informative to explore it.
Credit where credit is due ...
AD *is* a modified/extended LDAP+Kerberos based system, it just adds a ton more proprietary stuff around it to manage Windows workstations, the whole Group Policy Object stuff etc etc. Thats all implemented via LDAP extensions.
AD *is* a modified/extended LDAP+Kerberos based system, it just adds a ton more proprietary stuff around it to manage Windows workstations, the whole Group Policy Object stuff etc etc. Thats all implemented via LDAP extensions.
I'm sorry, with all due respect I disagree. There is an unfathomable quantity of functionality not accessible via LDAP.
You can query some aspects made available through the LDAP interface, you cannot set nor modify plenty.
On 1/29/2014 3:17 PM, Joseph L. Casale wrote:
I'm sorry, with all due respect I disagree. There is an unfathomable quantity of functionality not accessible via LDAP.
You can query some aspects made available through the LDAP interface, you cannot set nor modify plenty.
indeed, as I said, 'extended/modified'. the GPO stuff has actually nothing to do with the directory service per say, its just dispatched via it, using kerberos tickets for authentication. LDAP itself doesn't address replication either, and Microsoft made all that about as complicated as they could with their FSMO's and whatnot. its really simple and easy until something goes south, then you discover there's layers and layers of kludge under the skin and its amazing it works at all.
Pretty much right........and is not truly X.500 compliant...This AD. It makes me nervous when one refers to it as LDAP...heh. Do a low level trace when running: ldapsearch .. Problem is AD has to be dealt with until Microsoft dies! Becomes Novell. And it will someday....
Anyway.... The LDAP with CentOS is robust enough when built up as Master Master // rep. rep.
Lots of thing get missed....
"Paris in the the Spring" Did you catch that extra word there.....too much wrapper...Welcome to AD.
Wizard of Hass! Rarely wrong; usually right....
On Jan 29, 2014 3:00 PM, "John R Pierce" pierce@hogranch.com wrote:
On 1/29/2014 2:24 PM, Joseph L. Casale wrote:
No, the other way around. Microsoft Active Directory implements an LDAP like directory accessible interface for its own directory.
Calling Active Directory "LDAP" is like calling vim `echo "xx" > yy`. If
you
are unaware of all the moving parts under Active Directory, it might
prove
very informative to explore it.
Credit where credit is due ...
AD *is* a modified/extended LDAP+Kerberos based system, it just adds a ton more proprietary stuff around it to manage Windows workstations, the whole Group Policy Object stuff etc etc. Thats all implemented via LDAP extensions.
-- john r pierce 37N 122W somewhere on the middle of the left coast
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 01/28/2014 04:02 AM, Sorin Srbu wrote:
Hi all,
We're getting to a point in our linux environment where it's starting to be cumbersome to keep shadow and passwd-files up-to-date for the users to login on each computer. Scripts can only get us so far. 8-/
I've looked a bit into central login systems for linux, and NIS and LDAP seem to be prevalent. NIS being the simpler-to-setup solution for small to medium networks as I understand it, while LDAP is the more modern and scalable solution. See eg http://www.yolinux.com/TUTORIALS/NIS.html or http://sysadmin-notepad.blogspot.se/2013/06/nis-server-setup-on-rhelcentos.h....
NIS-wise, what is a "small to medium network"? We have currently about 20-30'ish linux clients and servers, and the environment is not likely to increase much beyond this point. Is a 30ish-computer setup, a small network?
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I used NIS for many years while working on Sun Solaris and it worked extremely well, although when it breaks it can be a real challenge to figure out the problems. I don't know how well it's implemented in Linux, bound to be a bit different than Solaris. In either case if it's important be aware of the potential security issues related to NIS, mainly the clear text passing of the password which is what pretty much doomed it.
Depending on how ansi your users get I would recommend a slave server as well, you might also consider using autofs to mount the user's homes.
The biggest potential problem that you might run into when you first implement NIS is to take a look at the uid of all the users on each host, you will need to ensure that they are the same before you start NIS or else it will be a mess for the users because they won't own their own files.
With all of that said I do think though that LDAP would be a better solution although I've not used LDAP.
Good luck with it either way.
Pete
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Pete Geenhuizen Sent: den 28 januari 2014 14:12 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
I used NIS for many years while working on Sun Solaris and it worked extremely well, although when it breaks it can be a real challenge to figure out the problems. I don't know how well it's implemented in Linux, bound to be a bit different than Solaris. In either case if it's important be aware of the potential security issues related to NIS, mainly the clear text passing of the password which is what pretty much doomed it.
Yeah, that last bit made me squirm over here. I don't feel good about that, even though the linux machines are all pretty much localized to one spot, so that hardly any traffic goes out of the department.
With all of that said I do think though that LDAP would be a better solution although I've not used LDAP.
Good luck with it either way.
Thanks. I'll look into LDAP some more.
//Sorin
Where I work we use NIS + Kerberos (Active Directory). We have about 150 machines at our site. It works quite well, as someone said, the big draw back to NIS is that it sends passwords insecurely, but if you use Kerberos for authentication it's really quite easy to manage. On Jan 28, 2014 6:23 AM, "Sorin Srbu" Sorin.Srbu@orgfarm.uu.se wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Pete Geenhuizen Sent: den 28 januari 2014 14:12 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
I used NIS for many years while working on Sun Solaris and it worked extremely well, although when it breaks it can be a real challenge to figure out the problems. I don't know how well it's implemented in Linux, bound to be a bit different than Solaris. In either case if it's important be aware of the potential security issues related to NIS, mainly the clear text passing of the password which is what pretty much doomed it.
Yeah, that last bit made me squirm over here. I don't feel good about that, even though the linux machines are all pretty much localized to one spot, so that hardly any traffic goes out of the department.
With all of that said I do think though that LDAP would be a better solution although I've not used LDAP.
Good luck with it either way.
Thanks. I'll look into LDAP some more.
//Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Logan McNaughton Sent: den 28 januari 2014 14:33 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Where I work we use NIS + Kerberos (Active Directory). We have about 150 machines at our site. It works quite well, as someone said, the big draw back to NIS is that it sends passwords insecurely, but if you use Kerberos for authentication it's really quite easy to manage.
We do have Active Directory as well, but only for the Windows clients.
But I'd rather keep them separated.
Kerberos on linux. Is that a pain or a bigger pain? Whenever I've worked with Kerberos on Windows I've come out all sweaty afterwards... 8-S
-- //Sorin
centos-bounces@centos.org schrieb am 28.01.2014 14:56:53:
Von: Sorin Srbu Sorin.Srbu@orgfarm.uu.se An: CentOS mailing list centos@centos.org Datum: 28.01.2014 14:57 Betreff: Re: [CentOS] NIS or not? Gesendet von: centos-bounces@centos.org
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Logan McNaughton Sent: den 28 januari 2014 14:33 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Where I work we use NIS + Kerberos (Active Directory). We have about
150
machines at our site. It works quite well, as someone said, the big
draw
back to NIS is that it sends passwords insecurely, but if you use
Kerberos
for authentication it's really quite easy to manage.
We do have Active Directory as well, but only for the Windows clients.
But I'd rather keep them separated.
Kerberos on linux. Is that a pain or a bigger pain? Whenever I've worked with Kerberos on Windows I've come out all sweaty afterwards... 8-S
-- //Sorin _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Sorin, we're using ldap with kerberos connected to Active Directoy on our squid proxy with success. And a few Linux-Admins are working (with their Windows User name and Password) with Kerberos connected to Active Directoy on their workstations.
Mit freundlichen Grüßen / Kind regards
Andreas Reschke
On Tue, Jan 28, 2014 at 8:56 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Logan McNaughton Sent: den 28 januari 2014 14:33 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Where I work we use NIS + Kerberos (Active Directory). We have about 150 machines at our site. It works quite well, as someone said, the big draw back to NIS is that it sends passwords insecurely, but if you use Kerberos for authentication it's really quite easy to manage.
We do have Active Directory as well, but only for the Windows clients.
But I'd rather keep them separated.
Kerberos on linux. Is that a pain or a bigger pain? Whenever I've worked with Kerberos on Windows I've come out all sweaty afterwards... 8-S
Then stop playing with yourself already! ;)
Kerberos on linux works quite well; keep everyone's clock within 5min of the auth server and you will be ok. I have not done sssd yet though. I did have timeout with nfs automount issues due to expired tickets, but that setup is old.
-- //Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mauricio Tavares Sent: den 28 januari 2014 15:20 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
We do have Active Directory as well, but only for the Windows clients.
But I'd rather keep them separated.
Kerberos on linux. Is that a pain or a bigger pain? Whenever I've worked with Kerberos on Windows I've come out all sweaty afterwards... 8-S
Then stop playing with yourself already! ;) Kerberos on linux works quite well; keep everyone's clock within5min of the auth server and you will be ok. I have not done sssd yet though. I did have timeout with nfs automount issues due to expired tickets, but that setup is old.
LOL!
Hmm, yes. It would seem most everybody recomends Kerberos. Will have to look into it then.
-- //Sorin (has self-consciously stopped playing with himself now... ;-))
Sorin Srbu wrote:
Behalf Of Mauricio Tavares
We do have Active Directory as well, but only for the Windows clients.
But I'd rather keep them separated.
Kerberos on linux. Is that a pain or a bigger pain? Whenever I've worked with Kerberos on Windows I've come out all sweaty afterwards... 8-S
Then stop playing with yourself already! ;) Kerberos on linux works quite well; keep everyone's clock within5min of the auth server and you will be ok. I have not done sssd yet though. I did have timeout with nfs automount issues due to expired tickets, but that setup is old.
LOL!
Hmm, yes. It would seem most everybody recomends Kerberos. Will have to look into it then.
Remember, kerboros came from the Unix world, so you'd expect it to work well in Linux. M$ added it in much later....
mark
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of m.roth@5-cent.us Sent: den 28 januari 2014 17:09 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Hmm, yes. It would seem most everybody recomends Kerberos. Will have to look into it then.
Remember, kerboros came from the Unix world, so you'd expect it to work well in Linux. M$ added it in much later....
I would like to thank you all for your hints, advice and suggestions. I now have quite a few leads to follow up on. Will probably be back later on with more questions if Google can't help me.
Thanks again. -- //Sorin
Hi friend -
what is your end goal with this effort to obtain security with your nodes over the 'wire' -
there are some other solutions -- kerberos is now used heavily by microsoft so that's enough to make me run for the hills... just saying..
i've set up other solutions to be sure -- even against the blasted (not a real LDAP) AD.
anyway.. just some thoughts... it's not trivial. any of the solutions, btw. not at all..
j/h San Francisco/Holland/Saudi Arabia
389882830-$$ (for those that know)
On 1/28/2014 11:30 PM, Sorin Srbu wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of m.roth@5-cent.us Sent: den 28 januari 2014 17:09 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Hmm, yes. It would seem most everybody recomends Kerberos. Will have to look into it then.
Remember, kerboros came from the Unix world, so you'd expect it to work well in Linux. M$ added it in much later....
I would like to thank you all for your hints, advice and suggestions. I now have quite a few leads to follow up on. Will probably be back later on with more questions if Google can't help me.
Thanks again.
//Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jeffrey Hass Sent: den 29 januari 2014 08:47 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Hi friend -
what is your end goal with this effort to obtain security with your nodes over the 'wire' -
there are some other solutions -- kerberos is now used heavily by microsoft so that's enough to make me run for the hills... just saying..
i've set up other solutions to be sure -- even against the blasted (not a real LDAP) AD.
anyway.. just some thoughts... it's not trivial. any of the solutions, btw. not at all..
j/h San Francisco/Holland/Saudi Arabia
Primarily to enable less administration in the long run with centralized logins, instead of keeping each single client updated with respect to shadow, passwd, bashrc, hosts and so on.
Some sort of encryption would probably be wise to use, as NIS uses clear text passwords. I don't trust our university network that much, even though the traffic should pretty localized.
I'm aware that setting up Kerberos probably will be a big project, nevertheless, we must do something about the current mess. As I'm the single sysadmin at the department, my time is finite. Automation is good, but as I wrote before, regular bash-scripting (however powerful) will only take you so far. 8-/ -- //Sorin
Hello Sorin,
Good call - not sure how far your coding goes and with what/how languages and scripts... Make sure to have as much as possible on VM's related to your security 'servers' -- so that you also get a virtual built in Disaster recovery as well.
KERBEROS is a very secure, albeit cumbersome component to implement (// network wide // think of... )
Having said this, um, with the tools available with openSource.. and I'm assuming you're such a shop due to running CentOS -- you can customize the ticket transport aspect after the encrypted authentication token is created and 'capture' that and with some slight tweaks create your own 'virtual Federated' auth method by way having total control of your requests, successes, failures and the like.
Note: I didn't catch it are you using the Microsoft's implementation of Kerberos? There's a reason I ask, you said you need to do something,, sounds like fairly quick, probably a good thing, if nothing else get centralization = control! - more so -- than before ~ and so it goes, you will have encapsulated tickets on steroids, to be sure.. but if you're the only person.. is your shop that big that SSL wouldn't do the trick? with some slight coding and enhancements // customization // - usually not supported by a 'given vendor' so beware there...
You will see performance over the other solutions in this space and some scalability - without know 'a lot' about your infrastructure -- and appliances therefore entered into the equation - it's hard to really say.
But sounds like you have Unix/Linux backend and alot of Windows stuff (we can't seem to ever get away from the highly faulty Windows suite) -- maybe when I retire, but anyway, and you're probably hitting a few AD servers -- and therefore there is the rub.
I have some implementations of several solutions if you're really serious about this as I can strip out the confidential stuff (I do weird things for various 'friendly' governments, world-wide) and have seen a thing or two here... mostly what 'not to do..'
Watch out for the posers out there as they will fire off the first thing from their minds and usually because they do not know much and end up with a flame or such ~ rarely a thank you..
In any event, I offer this as is and hope you enjoy your career with security. It truly is the highest paying area of IT at this given time.. I don't care what anyone says.
Think of the Target stores out there and such.. and you'll see SECURITY all over 2014 and more. We most don't get it.. They do a VISIO chart and build a server and usually *uck it up worse than ever.
GOOD LUCK. CentOS - is awesome for this kind of thing as a back-end and front-end. ENCIRCLE your WINDOWS servers and crush them! heh.
~ good night.
Oh summary:
KERBEROS good for larger scale operations that need total control and performance for many up-calls and down-calls NTLM - um, don't do it. SSL - vxx - ~! you can do this -- with customization - the rub here is customization means little if any support, if you leave, the 'company' is toast, in many cases.. there are no 'upgrades' to security with an ENHANCEMENT or customization.. and so it goes, you own it, until you die or leave...
Some experience for you here. Lots of it. Tons of it.
Okay.. I did my community service for the day.
Wizard of Hass!
On 1/29/2014 12:11 AM, Sorin Srbu wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jeffrey Hass Sent: den 29 januari 2014 08:47 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Hi friend -
what is your end goal with this effort to obtain security with your nodes over the 'wire' -
there are some other solutions -- kerberos is now used heavily by microsoft so that's enough to make me run for the hills... just saying..
i've set up other solutions to be sure -- even against the blasted (not a real LDAP) AD.
anyway.. just some thoughts... it's not trivial. any of the solutions, btw. not at all..
j/h San Francisco/Holland/Saudi Arabia
Primarily to enable less administration in the long run with centralized logins, instead of keeping each single client updated with respect to shadow, passwd, bashrc, hosts and so on.
Some sort of encryption would probably be wise to use, as NIS uses clear text passwords. I don't trust our university network that much, even though the traffic should pretty localized.
I'm aware that setting up Kerberos probably will be a big project, nevertheless, we must do something about the current mess. As I'm the single sysadmin at the department, my time is finite. Automation is good, but as I wrote before, regular bash-scripting (however powerful) will only take you so far. 8-/ -- //Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jeffrey Hass Sent: den 29 januari 2014 09:49 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Good call - not sure how far your coding goes and with what/how languages and scripts... Make sure to have as much as possible on VM's related to your security 'servers' -- so that you also get a virtual built in Disaster recovery as well.
My Google Fu is usually okay. ;-)
We've started offing physical servers in favour of virtual ones. So far mostly Windows servers, but I've started testing e.g. Owncloud on a virtualized CentOS guest. More Linux-machines are likely to be virtualized in due time. We (well, I actually...) decided on standardizing on Hyper-V as there was a really good P2V-tool available for migrating Windows servers. We had lots of them...
Note: I didn't catch it are you using the Microsoft's implementation of Kerberos?
We do have a Windows AD in place, it's the main IT here, but it's soon to be migrated to the central university IT-dept. One less thing to worry about... *nix was originally only a group-business at the dept., but over the years the Linux-ratio has upped considerably, what with backup-servers etc. running on Linux as well as us affording more machines for the original CADD-group.
There's a reason I ask, you said you need to do something,, sounds like fairly quick, probably a good thing, if nothing else get centralization = control! - more so -- than before ~ and so it goes, you will have encapsulated tickets on steroids, to be sure.. but if you're the only person.. is your shop that big that SSL wouldn't do the trick?
SSL? How do you mean? Can you elaborate a bit?
-- //Sorin
Hey Sorin,
I'm getting ready to catch a plane to Dubai but wanted to answer you real quick and short: SSL for smaller networks in terms of authentication is fine and secure - as long as your infrastructure is secure.
I'm glad to hear your using VM's more and more. It give you a lot more control to manipulate, change and recover from 'all kinds of errors' - tweaking .conf files, someone having 'root' or 'admin' on you as you have to trust someone/sometime...
.. anyway, um, I'm hoping you consider the SSL implementation if you have to do something 'quick..' if not, Kerberos will certainly help you from getting 'fired ..' it won't be the reason you do anyway..
About the previous post about IPA - you're hitting LDAP anyway (that is AD) and probably a few more out there if you're somewhat of 'shop' with stuff everywhere......
IPA was hacked by a user group (exploit) in Seattle - and you get what 'you don't pay for' sometimes.
Having said this, all these tools at the end of the day generally get the job done, the truth is 'what are you protecting..' and from 'what..' usually determines the component and/or tool you'd want to entertain.
Once you have it in-house // and your name is on it.. // and it's in Production, really HARD to back out, in some cases impossible.. Case in point: TARGET was hacked by a 17-year old punk with no date on a Friday night... ... and, well, they went from an 'openSource (which I FIRMLY believe in)' to a mix-bag implementation to include Oracle and IBM SSO/IdM implementation .. They removed Kerberos out of the equation - mixed SSL with a non-REAL x.500 compliant LDAP, we can say it has the letters DA in it but you can 'reverse' that and come up with a name... ....and then, so it goes, BAM! someone's inside.. You see, the problem here is many will jump in and recommend a solution because 'they worked with it... and in most cases, IT IS all they know...' You drive this car, you love it more than all other cars but have yet to drive the other cars and see for yourself... Point is, milage may vary and WILL and I will say this in my last post here on this thread, I've been in court as a witness during DoD audits and it was always, 'we went with a solution' that was proven and tried.. and recommended... TRIED by who? Recommended by who?? Best practices?? Just a collective agreement by a bunch of dweebs that say, yeah, that sounds right.
Message is: For what you need Kerberos would work and should work. Enough documentation out there... and such to help you... Also, YouTube, believe it or not has a lot of posts (many by myself but in my alter ego name, which are many) even this name is not real, but as I was saying - a ton of info.
It's funny what qualifies as a guru as at one time there was no Google to get an answer and rattle a 'solution' All my recommends is actual dogfood I have eaten and I don't want to see the same thing happen to others as this Security business is getting out of hand with all 'these experts' that truly don't have the heart to do what you're doing and get it done right and to care enough to do that.
SSL is implemented on every WebApplication Server, product that is Internet based except UDP - good luck with that... but having said that, you can surely -- do this with SSL and/or Kerberos.. Anything else, you're going to pay for it.
Here's a snip and it comes down to your infrastructure, what you do for a business, who your audience is/what they do once they do have access.. who wants your information, risk assessment is big here... and then there you go.
If you really wanted security.. you'd put another wrapper around this using a SSO tool, Access Manager -- and combined the Kerberos ticket into the packet once the SSL header is created with the credentials and CERT it down the wire. NO ONE IS GETTING IN, especially that 17-year old with a runny nose that mom is paying for his college is trying to do... Crazy world... Too bad we can meet these guys in person.. It would be a whole different world.
Sorry so long.. I post a few times of year to help those that are really burning the oil at night.
GOOD LUCK.
1. Kerberos SSL/TLS 2. LDAP has industrial strength protection build in if you hash the passwords/encrpt 3. Stay away from ANYTHING MICROSOFT security - Enter: Oxy-moronic 4. An openSource SSO tool built on JBoss or Tomcat
THis is the real world right now..
And if anyone challenges, like the song says, it surely means they don't know: Carry on.......
Wizard of Hass
--
Real men write their own device drivers ~ A. Tuckett
On 1/29/2014 1:49 AM, Sorin Srbu wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jeffrey Hass Sent: den 29 januari 2014 09:49 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Good call - not sure how far your coding goes and with what/how languages and scripts... Make sure to have as much as possible on VM's related to your security 'servers' -- so that you also get a virtual built in Disaster recovery as well.
My Google Fu is usually okay. ;-)
We've started offing physical servers in favour of virtual ones. So far mostly Windows servers, but I've started testing e.g. Owncloud on a virtualized CentOS guest. More Linux-machines are likely to be virtualized in due time. We (well, I actually...) decided on standardizing on Hyper-V as there was a really good P2V-tool available for migrating Windows servers. We had lots of them...
Note: I didn't catch it are you using the Microsoft's implementation of Kerberos?
We do have a Windows AD in place, it's the main IT here, but it's soon to be migrated to the central university IT-dept. One less thing to worry about... *nix was originally only a group-business at the dept., but over the years the Linux-ratio has upped considerably, what with backup-servers etc. running on Linux as well as us affording more machines for the original CADD-group.
There's a reason I ask, you said you need to do something,, sounds like fairly quick, probably a good thing, if nothing else get centralization = control! - more so -- than before ~ and so it goes, you will have encapsulated tickets on steroids, to be sure.. but if you're the only person.. is your shop that big that SSL wouldn't do the trick?
SSL? How do you mean? Can you elaborate a bit?
-- //Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Almost forgot, //Sorin:
SSL uses public key cryptography:
1. You (or your browser) has a public/private keypair 2. The server has a public/private key as well 3. You generate a symmetric session key 4. You encrypt with the server's public key and send this encrypted session key to the server. 5. The server decrypts the encrypted session key with its private key. 6. You and the server begin communicating using the symmetric session key (basically because symmetric keys are faster).
Kerberos does not use public key cryptography. It uses a trusted 3rd party. Here's a sketch:
1. You both (server and client) prove your identity to a trusted 3rd party (via a /secret/). 2. When you want to use the server, you check and see that the server is trustworthy. Meanwhile, the server checks to see that you are trustworthy. Now, mutually assured of each others' identity. You can communicate with the server.
I'm always nervous about 'trusted third parties..' Can you imagine.. That's what holds our credit cards and such, like, um, at Target.. the trusted 'third-party...' Damn, people really go for that??? See, it's a hard call, isn't it??
// weigh it all out... // and make sure you get buy in and put the DISCLAIMERS in your documentation and on the Wiki's because it will come back to you at some point ..... if it ever goes down...
BEWARE of anything related to Security solutions on the Net -- because most don't have more than three or four years experience. Most.
~ later.
j/h
On 1/29/2014 1:49 AM, Sorin Srbu wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jeffrey Hass Sent: den 29 januari 2014 09:49 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Good call - not sure how far your coding goes and with what/how languages and scripts... Make sure to have as much as possible on VM's related to your security 'servers' -- so that you also get a virtual built in Disaster recovery as well.
My Google Fu is usually okay. ;-)
We've started offing physical servers in favour of virtual ones. So far mostly Windows servers, but I've started testing e.g. Owncloud on a virtualized CentOS guest. More Linux-machines are likely to be virtualized in due time. We (well, I actually...) decided on standardizing on Hyper-V as there was a really good P2V-tool available for migrating Windows servers. We had lots of them...
Note: I didn't catch it are you using the Microsoft's implementation of Kerberos?
We do have a Windows AD in place, it's the main IT here, but it's soon to be migrated to the central university IT-dept. One less thing to worry about... *nix was originally only a group-business at the dept., but over the years the Linux-ratio has upped considerably, what with backup-servers etc. running on Linux as well as us affording more machines for the original CADD-group.
There's a reason I ask, you said you need to do something,, sounds like fairly quick, probably a good thing, if nothing else get centralization = control! - more so -- than before ~ and so it goes, you will have encapsulated tickets on steroids, to be sure.. but if you're the only person.. is your shop that big that SSL wouldn't do the trick?
SSL? How do you mean? Can you elaborate a bit?
-- //Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jeffrey Hass Sent: den 29 januari 2014 11:11 To: CentOS mailing list Subject: Re: [CentOS] NIS or not?
Almost forgot, //Sorin:
SSL uses public key cryptography:
- You (or your browser) has a public/private keypair
- The server has a public/private key as well
- You generate a symmetric session key
- You encrypt with the server's public key and send this encrypted session key to the server.
- The server decrypts the encrypted session key with its private key.
- You and the server begin communicating using the symmetric session key (basically because symmetric keys are faster).
Kerberos does not use public key cryptography. It uses a trusted 3rd party. Here's a sketch:
- You both (server and client) prove your identity to a trusted 3rd party (via a /secret/).
- When you want to use the server, you check and see that the server is trustworthy. Meanwhile, the server checks to see that you are trustworthy. Now, mutually assured of each others' identity. You can communicate with the server.
I'm always nervous about 'trusted third parties..' Can you imagine.. That's what holds our credit cards and such, like, um, at Target.. the trusted 'third-party...' Damn, people really go for that??? See, it's a hard call, isn't it??
// weigh it all out... // and make sure you get buy in and put the DISCLAIMERS in your documentation and on the Wiki's because it will come back to you at some point ..... if it ever goes down...
BEWARE of anything related to Security solutions on the Net -- because most don't have more than three or four years experience. Most.
Thanks for your insights. Appreciated.
My boss just looks funny at me when I ask him about security and has he considered all those post-Snowden details. 8-)
I've begun dabbling a bit with SSL while I did the Owncloud-testing and running. -- //Sorin
Security is a major consideration, and even though as you say most of the traffic is local, most problems are internal as opposed to external.
Pete On 01/28/2014 08:22 AM, Sorin Srbu wrote:
Yeah, that last bit made me squirm over here. I don't feel good about that, even though the linux machines are all pretty much localized to one spot, so that hardly any traffic goes out of the department.
Thanks. I'll look into LDAP some more.
//Sorin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
We have been using NIS for over a decade on our network, and it has been an effective solution. The network spans several subnets, and we have been able to deploy slave NIS servers on the various subnets. The reason for this is several fold:
Quicker response for login and other domain requests Network policy requires slave servers to be on subnets to reduce network traffic.
While the security is not as strong as it is for the LDAP solution, as long as you are employing NIS on an internal network, you should be all set.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Sorin Srbu Sent: Tuesday, January 28, 2014 4:03 AM To: CentOS mailing list Subject: [CentOS] NIS or not?
Hi all,
We're getting to a point in our linux environment where it's starting to be cumbersome to keep shadow and passwd-files up-to-date for the users to login on each computer. Scripts can only get us so far. 8-/
I've looked a bit into central login systems for linux, and NIS and LDAP seem to be prevalent. NIS being the simpler-to-setup solution for small to medium networks as I understand it, while LDAP is the more modern and scalable solution. See eg http://www.yolinux.com/TUTORIALS/NIS.html or http://sysadmin-notepad.blogspot.se/2013/06/nis-server-setup-on-rhelcentos.h....
NIS-wise, what is a "small to medium network"? We have currently about 20-30'ish linux clients and servers, and the environment is not likely to increase much beyond this point. Is a 30ish-computer setup, a small network?
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Kaplan, Andrew H. Sent: den 28 januari 2014 14:31 To: 'CentOS mailing list' Subject: Re: [CentOS] NIS or not?
We have been using NIS for over a decade on our network, and it has been an effective solution. The network spans several subnets, and we have been able to deploy slave NIS servers on the various subnets. The reason for this is several fold:
Quicker response for login and other domain requests Network policy requires slave servers to be on subnets to reduce network traffic.
While the security is not as strong as it is for the LDAP solution, as long as you are employing NIS on an internal network, you should be all set.
So you don't have any problem running clear-text passwords as mentioned in a previous post?
-- //Sorin
On Tue, Jan 28, 2014 at 3:02 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.
Thanks! Matt
Matt Garman matthew.garman@gmail.com a écrit :
On Tue, Jan 28, 2014 at 3:02 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.
Thanks! Matt
You’d be fine with IPA which allows you to create such rules.
HTH, Laurent.
2014-01-28 Laurent Wandrebeck l.wandrebeck@quelquesmots.fr
Matt Garman matthew.garman@gmail.com a écrit :
On Tue, Jan 28, 2014 at 3:02 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se
wrote:
The only thing I'm trying to accomplish is a system which will allow me
to
keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.
Thanks! Matt
You'd be fine with IPA which allows you to create such rules.
HTH, Laurent. _______________________________________________
Indeed, and IPA does this quite well.
We use IPA on all servers and workstations.
- Sudo information comes from IPA
- Autofs information comes from IPA
- Host based access control comes from IPA
- Central user management/identity
It all works really good.
On Tue, Jan 28, 2014 at 9:47 AM, Darod Zyree darodzyree@gmail.com wrote:
2014-01-28 Laurent Wandrebeck l.wandrebeck@quelquesmots.fr
Matt Garman matthew.garman@gmail.com a écrit :
On Tue, Jan 28, 2014 at 3:02 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se
wrote:
The only thing I'm trying to accomplish is a system which will allow me
to
keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.
Thanks! Matt
You'd be fine with IPA which allows you to create such rules.
HTH, Laurent. _______________________________________________
Indeed, and IPA does this quite well.
We use IPA on all servers and workstations.
Sudo information comes from IPA
Autofs information comes from IPA
Host based access control comes from IPA
Central user management/identity
i read that IPA can do multimaster. How well does it do it compared to openldap?
It all works really good. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
2014-01-28 Mauricio Tavares raubvogel@gmail.com
On Tue, Jan 28, 2014 at 9:47 AM, Darod Zyree darodzyree@gmail.com wrote:
2014-01-28 Laurent Wandrebeck l.wandrebeck@quelquesmots.fr
Matt Garman matthew.garman@gmail.com a écrit :
On Tue, Jan 28, 2014 at 3:02 AM, Sorin Srbu <Sorin.Srbu@orgfarm.uu.se
wrote:
The only thing I'm trying to accomplish is a system which will allow
me
to
keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.
Thanks! Matt
You'd be fine with IPA which allows you to create such rules.
HTH, Laurent. _______________________________________________
Indeed, and IPA does this quite well.
We use IPA on all servers and workstations.
Sudo information comes from IPA
Autofs information comes from IPA
Host based access control comes from IPA
Central user management/identity
i read that IPA can do multimaster. How well does it do itcompared to openldap?
I can't say how well it does compared to openldap but the replication is quick reliable.
For example; we test IPA masters by (re)applying settings in user accounts etc. while "crashing" them at random (removing power; they were virtual machines)
Laurent Wandrebeck wrote:
Matt Garman matthew.garman@gmail.com a écrit :
On Tue, Jan 28, 2014 at 3:02 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
The only thing I'm trying to accomplish is a system which will allow me to keep user accounts and passwords in one place, with one place only to administrate. NIS seems to be able to do that.
Comments and insights are much appreciated!
A related question: is NIS or LDAP (or something else entirely) better if the machines are not uniform in their login configuration?
At this late date, I'd be really, *REALLY* leery of using NIS. You say that *most* of your traffic is local, suggesting that some of it is *not*. And, for that matter, how good are the firewalls keeping other traffic out?
I'd say no to NIS. Yes, other answers may be more difficult to set up, but consider the alternatives.
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
Here you may not realize you're distinguishing between authentication and authorization.
I currently have a custom script with a substantial configuration file for checking that the actual machines are configured as per our intent. It would be nice if there was a single tool where the configuration and management/auditing could be rolled into one.
We have an in-house written set of scripts that administer relevant configuration files, including /etc/passwd. It copies the correct version of that file (among many others) to each host, and shell of /bin/noLogin works just fine.
You’d be fine with IPA which allows you to create such rules.
I'd vaguely heard of IPA, so I just looked it up. *chuckle* You do notice that it has its own implementation of LDAP and uses kerboros, right? So seems like several folks are recommending LDAP and kerboros.
I sincerely hope it's easier to set up and administer and upgrade than native LDAP. In '06, after a discussion with the other admin and manager I was working with at that job, I volunteered to set up openLDAP. Let's just say that the tools were NOT vaguely ready for prime time, though I did find that running webmin helped a *lot* to get it working.
But that was nearly 8 years ago....
mark
On Tue, Jan 28, 2014 at 9:18 AM, m.roth@5-cent.us wrote:
At this late date, I'd be really, *REALLY* leery of using NIS. You say that *most* of your traffic is local, suggesting that some of it is *not*. And, for that matter, how good are the firewalls keeping other traffic out?
I'd say no to NIS. Yes, other answers may be more difficult to set up, but consider the alternatives.
That is, we have an ever-growing list of special cases. UserA can login to servers 1, 2 and 3. UserB can log in to servers 3, 4, and 5. Nobody except UserC can login to server 6. UserD can login to machines 2--6. And so on and so forth.
Here you may not realize you're distinguishing between authentication and authorization.
Yeah, I forgot to mention that we already have Kerberos in place for authentication. It's authorization that is currently done by hand and checked with a manual script. (I needed that for the secure mount options NFSv4 provides.)
I sincerely hope it's easier to set up and administer and upgrade than native LDAP. In '06, after a discussion with the other admin and manager I was working with at that job, I volunteered to set up openLDAP. Let's just say that the tools were NOT vaguely ready for prime time, though I did find that running webmin helped a *lot* to get it working.
I know you can find a horror story for any piece of software on the Internet, but my impression is that LDAP has an unusually high number of scary-sounding anecdotes. I know random Internet blogs forum posts aren't really authoritative, but they do give me a little trepidation regarding LDAP.
We have an in-house written set of scripts that administer relevant configuration files, including /etc/passwd. It copies the correct version of that file (among many others) to each host, and shell of /bin/noLogin works just fine.
Why set the shell to /bin/noLogin, rather than simply not create that user's /etc/passwd entry?
I don't have /bin/noLogin on any of my systems - I assume you deliberately specified a non-existent program for the shell? What's the difference between setting the user's shell to a bogus program versus something like /bin/false?
Matt Garman wrote:
On Tue, Jan 28, 2014 at 9:18 AM, m.roth@5-cent.us wrote:
<snip>
We have an in-house written set of scripts that administer relevant configuration files, including /etc/passwd. It copies the correct version of that file (among many others) to each host, and shell of
/bin/noLogin
works just fine.
Why set the shell to /bin/noLogin, rather than simply not create that user's /etc/passwd entry?
I don't have /bin/noLogin on any of my systems - I assume you deliberately specified a non-existent program for the shell? What's the difference between setting the user's shell to a bogus program versus something like /bin/false?
There's one master passwd file, and the scripts that centrally manage it set the shell, one way or another, depending on a different configuration file. Why noLogin? I know I've seen it elsewhere; I think I've also seen it as /bin/false. That's a call above my pay grade.... <g>
mark
On Tue, Jan 28, 2014 at 11:38 AM, Matt Garman matthew.garman@gmail.com wrote:
Here you may not realize you're distinguishing between authentication and
authorization.
Yeah, I forgot to mention that we already have Kerberos in place for authentication. It's authorization that is currently done by hand and checked with a manual script. (I needed that for the secure mount options NFSv4 provides.)
What is it that your scripts tweak? I have a small setup using kerberos against an AD for authentication, but the linux servers have their own passwd files for the small subset of users there. /home is shared from one server to all of the others in the set. This worked when initially set up with matching users (w/matching uids) but when I added new ones, nfsv4 mapped them to 'nobody' until I rebooted the clients. Restarting nfs and/or idmapd didn't help. Is there some way to make added users work?
-
anax -
Andreas Reschke -
Darod Zyree -
Devin Reade -
Jeffrey Hass -
John R Pierce -
Joseph L. Casale -
Kaplan, Andrew H. -
Laurent Wandrebeck -
Les Mikesell -
Logan McNaughton -
m.roth＠5-cent.us -
Matt Garman -
Mauricio Tavares -
Pete Geenhuizen -
Rob Kampen -
Sorin Srbu