複数のLinuxシステムへのアクセスの管理


15

回答を検索しましたが、ここで何も見つかりませんでした...

要するに、非営利組織はインフラストラクチャの近代化を切実に必要としています。まず、多くのLinuxホストでユーザーアカウントを管理する代替手段を見つけることです。

12台のサーバー(物理サーバーと仮想サーバーの両方)と約50台のワークステーションがあります。これらのシステムには500人の潜在的なユーザーがいます。長年にわたってシステムを構築および保守していた個人は退職しました。彼はそれをすべて管理するために彼自身のスクリプトを書きました。それでも機能します。苦情はありません。ただし、多くのものは非常に手作業でエラーが発生しやすいものです。コードは乱雑であり、更新後に頻繁に調整する必要があります。最悪の部分は、ドキュメントがほとんどまたはまったく書かれていないことです。ほんの数個のReadMeとランダムなメモがありますが、これらはもう関係がないかもしれません。そのため、メンテナンスは困難な作業になりました。

現在、アカウントは各システムの/ etc / passwdを介して管理されています。アカウントが「メイン」サーバーに追加されると、システムを修正するために、cronスクリプトを介して更新が配布されます。すべてのシステム(sysadminアカウントなど)へのアクセスが必要なユーザーもいれば、共有サーバーへのアクセスが必要なユーザーもいれば、ワークステーションまたはそれらのサブセットのみへのアクセスが必要なユーザーもいます。

次の要件を満たすアカウントの管理に役立つツールはありますか?

  • できればオープンソース(つまり、予算が非常に限られているため無料)
  • メインストリーム(つまり、メンテナンス済み)
  • LDAP統合を持っているか、ユーザー認証のためにLDAPまたはADサービスとインターフェイスすることができます(近い将来、アカウントを他のオフィスと統合するために必要になります)
  • ユーザー管理(追加、期限切れ、削除、ロックアウトなど)
  • 各ユーザーがアクセスできるシステム(またはシステムのグループ)を管理できます-すべてのユーザーがすべてのシステムで許可されているわけではありません
  • ログインしているシステムに応じて、異なるホームディレクトリとマウントを使用できるユーザーアカウントのサポート。例えば
    • 「メイン」サーバーにログインしたsysadminには、homedirとしてmain:// home / sysadmin /があり、すべての共有マウントがあります
    • スタッフワークステーションにログインしたsysadminは、nas:// user / s / sysadminをhomedir(上記とは異なる)として持ち、マウントのセットを潜在的に制限します。
    • ログインしたクライアントは、別の場所にhomedirを持ち、共有マウントはありません。
  • 素晴らしい管理インターフェースがあればそれは素晴らしいでしょう。
  • このツールがクロスプラットフォーム(Linux / MacOS / * nix)である場合、それは奇跡です!

ウェブを検索しましたが、適切なものが見つかりませんでした。私たちはどんな提案にもオープンです。ありがとうございました。

編集:この質問は誤って重複としてマークされています。リンクされた回答は、すべてのシステムで同じhomedirを使用することについてのみ説明しますが、現在ログインしているシステムユーザー(MULTIPLE homedirs)に基づいて異なるhomedirが必要です。また、全体ではなく一部のマシンにのみアクセスを許可する必要があります。改造、ポイントの重複として単にマークするのではなく、問題の全範囲を理解してください...


「ポイント」は重複をマークしても授与されません。あなたの質問は、5人が重複していると考えるほど明確ではありませんでした。
user9517

知りませんでした。はい、ありがとう。ただし、急いで重複とマークされました。必要なものを明確に記載したポイント形式の要件をお読みください。これは重複ではありません。「ソリューション」への提供されたリンクにより、すべてのシステムへの無差別アクセスが可能になります(誰がアクセスできるか、どのシステムまたはシステムのグループにアクセスできるかを制限する必要があります)。実際のhomedirの場所は、アクセスされているシステムによって異なります。同じユーザーは、ログインしているシステムに応じて異なるhomedirとマウントを持っている可能性があります。
スワーツ

明確にするために:上記のsysadminの例では、mainとnasは異なるサーバーですか?だから、同じユーザーは、ログインするhomedirに応じて異なるhomedirにアクセスできますか?
マルコビザッリ

@MarcoBizzarri:わかりません。ユーザーがログインしているシステムがhomedirを決定します。SysAとSysBの両方が/ etc / passwdに/ home / bobを持ち、SysCのBobのhomdirが/ someplace / else / bobになる場合があります。2つの場所には異なるデータが含まれます。システムユーザーがログインすると、使用可能な他のマウントが決まります。これにより、スタッフシステムのみが共有スタッフマウントにアクセスできます。「公に」利用可能なシステムが他のマウントに制限される場合。したがって、スタッフがスタッフ指定のPCにアクセスしてスタッフマウントにアクセスする必要があります。少しの区画化
...-スワルツ

わかりました。したがって、ここには2つの異なる点があります。homedirは固定されており、どこかに(同じサーバーまたは別のサーバーに)配置できますが、常にそうです。つまり、SysAには常にserverXのhomedirがあります。その後、staff間に共有ディレクトリがあります。staff_dirと呼びましょう。staff_dirは、staff_workstationにログインするときは使用できますが、normal_workstationにログインするときは使用できません。あれは正しいですか?
マルコビザッリ

回答:


17

FreeIPAはおそらくあなたが探しているものです。Linuxにとって、WindowsにとってのActive Directoryとは何か。(異種環境がある場合はADと通信することもできますが、Windowsマシンを直接管理するために使用すべきではありません。そのためにADを使用してください。)

Red Hatのドキュメント(Identity Managementと呼ばれます)は非常に徹底的でわかりやすいため、Red Hat派生システムを使用していない場合でもほとんど適用できます。


+1 freeipaは素晴らしいです。
Sirex

FreeIPAを見ていきます。ヒントをありがとう。質問:FreeIPAは、異なるシステムで異なるhomedirをサポートしていますか?例:ユーザーBobは、SystemAおよびSystemBにログインしたとき/ shared / home / xyzに(NFSエクスポートされた)homedirを持っていますが、SystemCにあるときは/ whatever / specialはBobのhomedirです。
スワルツ

自動マウントを見ましたか?これにより、そこの約90%が得られ、残りの10%は既存の環境へのわずかな変更です。
マイケルハンプトン

はい、既存のシステムは自動マウントを使用します。これらは、システムのタイプごとに手動で構成されます。残念ながら、既存の環境は維持するのが面倒です。特に、更新後または新しいシステムイメージを作成する場合。そのコアは機能しますが、機能させるためには微調整が必​​要なものが常にあります。
スワーツ

じゃあ。これで、クリーンアップを開始する良い機会になりました。
マイケルハンプトン

6

あなたの状況の詳細を評価するために、良い地元のコンサルタントをお勧めします...

本当に。

このフォーラムの人々が認識していない、または十分に投資できない可能性のある他のビジネス要件またはニュアンスがある場合があります。専用のリソースが最善の策です...それ以外の場合は、単純なQ&Aの範囲外である可能性のあるものについて、製品の推奨事項を単に投げかけています。


それにもかかわらず、私のアプローチはMicrosoft Active Directoryを活用し、SSSDまたはLDAP を使用してLinuxシステムを結びつけることです。FreeIPAはすべてLinuxの家では問題ありませんが、「非営利」と言っても、必ずしもWindowsを除外するわけではありません。パスのどこかにActive Directoryがあります。自動マウントされたホームディレクトリでこれを拡張したい場合がありますが、いつまたはどこでマウントされるかは明確ではありません。

現在構築している99%Linuxプライベートクラウド環境でも、管理の容易さと一元化された認証のためにActive Directoryに依存しています。グループとアクセス許可は簡単で、パスワードポリシーとアカウントエージングは​​簡単です。保守性、マインドシェア、互換性に関する懸念は、マイクロソフトのソリューションでカバーされます。レプリケーションはビルトインであり、十分に文書化されており、テクノロジに固有の将来の保証が少しあります。

ただし、元の質問にはいくつかの詳細が欠けています...

  • 環境にはどのような特定のLinuxディストリビューションが存在しますか?バージョンに一貫性はありますか?
  • Macintoshシステムに同じレベルの管理粒度が必要ですか(ほとんどの組織はAppleコンピューターを完全に管理しようとはしていません)?
  • リモートユーザーはいますか?
  • あなたは「* nix」と言っています-どんなタイプの* nixesが存在しますか?

2
freeipaがLinuxマシン(レプリケーション、パスワードポリシー、グループなど)に対してこれらすべてを実行できることは何の価値もありませんし、セットアップは非常に簡単です(本当に!)。また、Active Directoryに対して双方向レプリケーションを実行します(ADに余分なフィールドがあるため、新しいユーザーは単方向であることは確かです)が、Windowsマシンがある場合は、Windowsの中心的な方法であるにもかかわらず、ADが必要です生活。また、freeipaのドキュメンテーションには、まだ私見が欠けています。
Sirex

悲しいことに、コンサルタントには予算がありません。Windowsマシンはありません(スタッフが自分で持ってきた場合のみ)。すべてのシステムはCentOSです(一部の5.xは6.xです)。組織はいくつかの古い(2007年式)iMacを入手するプロセスにあるため、OSXおよびLinuxで動作するツールがあれば良いと思います。1つの良い点:Windowsについて心配する必要はありません。
スワーツ

Active Directoryの提案に同意します-ライセンスコストが問題になる場合、Samba4は無料の代替手段であり、ネイティブのWindowsがホストするADと同じ管理ツール/インフラストラクチャを使用します。ほとんど何か他のものは、インフラ全体のための構成管理についてなど。、PAM、winbindの、LDAPを通じてADに対して認証するように設定することができ、塩をチェックアウト(saltstack.com/community.html blog.smartbear.com/devops/...
ネッド

3

現在のシステムは動作しますが、管理が困難です。すべてが手動で行われた場合、それらのサーバーを管理する他の問題もあると思います。動作するもの(ユーザー管理)を置き換えないことで、別のアプローチを取り、サーバーの管理上の問題を解決します。

cfengine http://cfengine.com/community(無料版)などを使用して、ユーザー管理だけでなくシステム管理を「近代化」することをお勧めします。現在のシステムはcfengineを使用してサーバーに設定を配布するのと同じように機能するため、試してみるのに良い機会です。この場合は/ etc / passwdです。そのため、これらのスクリプトを置き換えるのではなく、cfengineに移行します。同じ/ etc / passwdをまだ使用しているため、影響が非常に少なくなることを願っています。

cfengineに慣れたら、完全に新しいユーザー管理システムを持つなど、より多くの問題を解決するためのレシピを作成し、サーバー上の構成を管理するツールを使用できます。

簡単に始められるように、http://explosive.net/opensource/cfpasswd/doc/cfengine.htmlのリンクを見つけました。このリンクは、/ etc / passwdと関連ファイルの配布方法を示しています。

ユーザー管理システムを今すぐ交換したい場合でも、それらのサーバーを管理する管理ツールが必要です。管理ツールをすぐに使用し、管理ツールでユーザー管理を再構成することをお勧めします。


0

追加するいくつかの簡単なもの-

展開でPuppetを使用しています-cfengineと同様のアイデア-http ://puppetlabs.com

これにより、ユーザー管理と一般的な構成/サーバー管理も実行できます。

Sambaのような汎用性のあるものを試したい場合は、何らかの構成でディレクトリーの管理を行う可能性と、構成にLDAPバックエンドを使用する可能性があります。Samba 4は非常に成熟しており、実際には管理および認証のためにWindowsおよびLinuxを使用した統合環境を提供できます。

SambaはADとともに、またはADの代替としても機能します。

少し前に見たCentrifyという製品もあります。私はそれで行き過ぎたことは一度もありませんが、フリーウェア/オープンソース版も持っていると思います。私が思い出すと、WindowsとLinuxの管理、そして場合によってはMacを提供する混合環境の可能性がありました。

次にコンサルタントの提案をします。これらの展開は、非常に高速にセットアップするのは非常に複雑になる可能性がありますが、文書化して構成すると保守が容易になります。

幸運のベスト


1
私はPuppetとChefを初期設定管理のために見てきました。Puppetは10個の無料ノードを許可し、Chefでは5個の無料ノードを取得できます。それ以降、Puppet Labsは1ノードあたり年間99ドルを請求します。私たちにとっては数千になります。合意を壊すもの。Chefの価格設定は覚えていませんが、同じ考えです。予算ではありません。:(
スワーツ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.