<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>ひよこ IT</title>
<link>https://ameblo.jp/halhalhal44/</link>
<atom:link href="https://rssblog.ameba.jp/halhalhal44/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>なにもできない、知らないまま夢だけ背負ってIT企業に入ってしまった新卒2年目学びのメモ</description>
<language>ja</language>
<item>
<title>CALについて</title>
<description>
<![CDATA[ <h2>CAL の概要</h2><p>CAL は大きく以下の 2 種類に分類され、</p><p>お客様のリモート デスクトップ サービス環境に応じて、使い分けていただく</p><p><br>・デバイス CAL…接続元デバイス (クライアント) 毎に対して発行<br>・ユーザー CAL…接続ユーザー毎に発行</p><p>&nbsp;</p><p>使い分けの例は下記のような感じ。</p><p><br>一つのデバイスを複数人利用するなら、デバイス CAL！<br>１人のユーザーが複数のデバイスを利用するなら、ユーザー CAL ！<br>とすれば、購入 (インストール) CAL の数量を効率よく管理できる</p><p>&nbsp;</p><p>ポイントは、セッション ホスト サーバーが両方の CAL に応じる事はできない。<br>&nbsp;</p><p>なので、１台のセッション ホスト サーバー (ターミナル サーバー) に対しては、<br>デバイス CAL を使って接続させるか、ユーザー CAL を使って接続させるかに応じて、<br>いずれかのライセンス モードを選択する必要がある。</p><p>&nbsp;</p><p>なお、一台のライセンス サーバーに、デバイス CAL、ユーザー CAL の両方インストールは可能。</p><p>デバイス CAL、ユーザー CAL はそれぞれ発行動作が異なる。</p><h2>デバイス CAL について</h2><p>デバイス CALとは<br>クライアント コンピューター (デバイス) に対してセッション ホスト サーバーへアクセスする権限を与える。</p><p>デバイス CAL が一度発行されると、その情報がクライアント コンピューター上に保持される。</p><p>デバイス CAL の情報は、クライアントの以下のレジストリに格納される。<br>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store\LICENSE00x<br><br>デバイス CAL は、以下の２種類が存在<br>&nbsp;</p><p>①初回接続時に発行される一時 CAL&nbsp;<br>②２回目の接続時に発行される恒久 CAL</p><p>&nbsp;</p><p>①一時 CAL<br>クライアント コンピューターからセッション ホスト サーバーに初めて接続した時に発行されるライセンス</p><p>&nbsp;</p><p>ポイント<br>・有効期限は、一律で 90 日間。恒久 CAL の余剰数がない状態の場合は、２度目以降の接続時も一時 CAL のまま接続する<br>・一時 CAL の発行数に制限はない</p><p>&nbsp;</p><p>②恒久 CAL<br>一時 CAL を持っているクライアント コンピューターが二回目に接続した時に発行されるライセンス</p><p>&nbsp;</p><p>ポイント<br>・恒久 CAL の有効期限は、52 日間から 89 日間のランダムな期間が設定される<br>・この有効期限を任意の期間にすることはできない<br>・ライセンス サーバーにインストールした数量を上限として発行される</p><p>&nbsp;</p><p>恒久CALの更新<br>・有効期限日の 1 週間前から CAL の更新期間となり、更新期間中にセッション ホスト サーバーに接続する事で、<br>新たに 52 日間から 89 日間のランダムな期間が設定される<br>・Windows Server 2008 以降の CAL については、ライセンス マネージャー上から、失効処理を行う事が可能</p><p>&nbsp;</p><p>ライセンスの失効<br>接続する事がなくなったクライアントや、誤って接続して発行させてしまったクライアントに対して、<br>発行された CAL を失効させ、別のクライアントのために発行の余剰を作ることができる</p><p>&nbsp;</p><p>失効のポイント<br>・ Windows Server 2003 以前の CAL については失効処理を行う事ができない<br>・失効できる数はインストールしている CAL 総数の 20 % まで<br>・失効された CAL についても、発行先のクライアントが保持する CAL の情報は変わらず、有効期限内は接続する事が可能<br>・失効処理は、あくまでライセンス サーバー上の管理上の情報となります。</p><p>&nbsp;</p><p>極端な例…<br>100 CAL が存在し、全ての CAL が発行済みであるとき、<br>その状態で上限となる 20 % の CAL を失効させ、さらに新規で 20 台のクライントが接続し</p><p>恒久 CAL が発行された場合、<br>一時的には 120 台のクライアントが恒久 CAL を持つことになる</p><h2>ユーザー CAL について</h2><p>ユーザー CAL には、デバイス CAL と違い、<br>・一時 CAL や恒久 CAL といった概念はない<br>・接続元クライアントのレジストリに情報が記録される動作はない</p><p>&nbsp;</p><p>CAL の発行情報は、ドメイン コントローラー上の各ユーザー コンテナに情報として格納される。<br>&nbsp;</p><p>この情報の表示について、<br>・Windows Server 2012 以降の環境あれば、ライセンス マネージャー上に表示<br>・Windows Server 2008 R2 以前のバージョンにおいては、ライセンス マネージャー上には</p><p>表示されず、レポート機能が必要</p><p>&nbsp;</p><p>また、ライセンス サーバーが、ドメイン環境かつ Windows Server 2012 以降の場合は、<br>ライセンス マネージャー上でユーザー CAL の発行状況を確認する事ができる</p><p>&nbsp;</p><p>ユーザー CAL の有効期限：一律で 60 日間</p><p><br>60日間の有効期限は、</p><p>あくまでその時点で発行されているユーザー CAL の情報管理のため使われる。</p><p>なので、<br>有効期限を超過した場合も、超過直後の接続時に新たな有効期限が付与される。<br>長期間アクセスが無い場合においても、接続不可となる事は発生しない</p><p>&nbsp;</p><p>ユーザー CAL (ユーザー数ライセンス モード) では、<br>1 人のユーザーに対して、</p><p>無制限の数のクライアントからセッション ホスト サーバーにアクセスする権限が与えられる<br>ユーザー CAL (ユーザー数ライセンス モード) はライセンスによって強制されることはない<br>そのため、</p><p>ライセンス サーバーにインストールされている CALの数に関係なく、クライアント接続を行うことができる。</p><p>&nbsp;</p><p>注意<br>各ユーザーに有効な CAL を持たせなければならないという</p><p>MS のソフトウェア ライセンス条項の要件から管理者が免除されるわけではない。<br>なので、<br>接続ユーザー数ライセンス モードを使用している場合に、</p><p>各ユーザーに有効な CAL を持たせることができなければ、ライセンス条項違反となる<br><br>&nbsp;</p><p><b>ひよこコメント</b><br>&nbsp;</p><p>お客様のご質問から、CALについて学ぶこととなりました。<br>&nbsp;</p><p>管理・運用のベストプラクティスについて相談されましたが、<br>「ユーザ様にて、ユーザ様の責任で適切に管理いただくしか方法が無い」<br>「ライセンスも１つの資産と考えていただき、その資産の守り方について</p><p>推奨方法の提示は難しい」という結論でした。</p><p>&nbsp;</p><p>ただ、お客様への理解や共感を示せるためにも、</p><p>このくらいの最低限の知識は必要だと思いました。</p><p>&nbsp;</p><p>特に、ユーザーCALの使用に関しては、モラル頼りなところもあり、</p><p>紳士協定の上でも、お互いの正しい理解が大事だと感じます。</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p><p>&nbsp;</p>
]]>
</description>
<link>https://ameblo.jp/halhalhal44/entry-12679616296.html</link>
<pubDate>Wed, 09 Jun 2021 19:04:13 +0900</pubDate>
</item>
<item>
<title>図でわかるフェデレーション</title>
<description>
アメンバー限定公開記事です。
</description>
<link>https://ameblo.jp/halhalhal44/amemberentry-12679554225.html</link>
<pubDate>Wed, 09 Jun 2021 12:34:28 +0900</pubDate>
</item>
<item>
<title>認証について　後編</title>
<description>
<![CDATA[ <p><span style="font-weight:bold;">③クラウド時代の認証　</span></p><p>&nbsp;</p><p><span style="font-weight:bold;">フェデレーション</span><br>一度認証されれば、その認証情報を使って</p><p>許可されているすべてのサービスを使えるようにする仕組み</p><p>&nbsp;</p><p>これを利用し、別組織とのＳＳＯを構築。<br>認証が1度で済むんだから、便利。<br><br>特徴<br>・事前に組織間で信頼関係を結べば、ユーザは１つの資格情報の登録で、</p><p>　複数の組織のシステムの利+　用が可能になる。<br>・ID/PWなどの資格情報を信頼先の組織に預ける必要がない</p><p>&nbsp;</p><p><img alt="画像1" height="320" id="image-ttZBp" src="https://assets.st-note.com/production/uploads/images/54124621/picture_pc_5c16df0bebcd74f74a81c9c58fb0541b.png" width="620"></p><p>&nbsp;</p><p>参考までに、<br>マイクロソフトが提供しているフェデレーションサービスは２つ。</p><p>&nbsp;</p><p><b>①ADFS</b><br>オンプレADDSにフェデレーションの仕組みを加えるためのサーバー<br><b>②AzureAD</b><br>IDaaSと呼べれるクラウド上に展開される認証基盤サービス<br><br>これらの製品の技術を活用すれば、<br>新しいビジネスのニーズに対応しつつ、セキュリティを担保することが可能となる！<br><br>次回以降は、さらに内容を細分化してブレイクダウンしていきます。</p><p>&nbsp;</p><p>&nbsp;</p>
]]>
</description>
<link>https://ameblo.jp/halhalhal44/entry-12679509795.html</link>
<pubDate>Wed, 09 Jun 2021 07:49:43 +0900</pubDate>
</item>
<item>
<title>認証について　前編</title>
<description>
<![CDATA[ <header data-v-5f339e98="">認証の歴史をさかのぼると、下記に分かれる。</header><header data-v-5f339e98="">&nbsp;</header><main data-v-5f339e98="" id="note-editor-screen"><p name="8e0qC">①システム固有のユーザアカウントとPWでの認証<br>②ドメイン構成による認証<br>③クラウド時代の認証</p><p name="8e0qC">&nbsp;</p><p name="7W3h9">①と②を、まずはまとめていく。</p><p name="7W3h9">&nbsp;</p><p name="1R2mF"><span style="font-weight:bold;">①システム固有のユーザアカウントと PW での認証</span><br>アプリケーションとユーザー間で秘密の文字列を決め、一致したら許可<br><br>①の問題点は…<br>ユーザーはアプリ毎に固有 ID・PW 管理の必要があり面倒</p><p name="1R2mF">&nbsp;</p><p name="nJX5L"><span style="font-weight:bold;">②ドメイン構成による認証</span><br>ドメインを構成し、ユーザーは所属しているドメイン内のアプリ利用時にはアプリ毎のPWが不必要に。<br>( 例：Microsoft の Active Directory Domain Service )<br><br>☆Kerberos 認証 を利用した 「Kerberos の壁」<br>ユーザー名( PC 名 )や PW などの資格情報をもとに、本人か検証するプロセス</p><p name="nJX5L"><br>(ふにゃふにゃな図でごめんね…)</p><p name="nJX5L">&nbsp;</p><p name="Qa5Vh"><a href="https://stat.ameba.jp/user_images/20210609/07/halhalhal44/3e/c3/p/o1505081214954633428.png"><img alt="" height="227" src="https://stat.ameba.jp/user_images/20210609/07/halhalhal44/3e/c3/p/o1505081214954633428.png" width="420"></a></p><p name="zCR5a">※アクセストークン<br>ユーザのSID、参加しているグループのSID、権限リスト、他のアクセス情報などの認証情報。<br>※SID<br>Windowsのユーザーアカウントやユーザーグループに与えられる、固有の識別番号</p><p name="w6XE5">例えば共有ファイルを読み取るときも、トークンをファイルサーバーに提示し、ファイルサーバーが許可するプロセスが入る。<br>このとき、ファイルサーバーは、ユーザのトークンと、リソースに設定されているアクセス制御リストを比較して判断する。</p><p name="KiUkd">&nbsp;</p><p name="KiUkd">②の問題点は…<br>１．クラウドの時代となり、個別のユーザ管理となるシステムが増加<br>２．イントラネット認証の限界<br><br>※イントラネット<br>TCP/IPなどのインターネット標準の技術を用いて構築された組織内ネットワークのこと。WAN。<br>※TCP/IP<br>現在のネットワークやインターネットで使われている最も標準的なプロトコル群を組み合わせた通信手段。普段一般的に使用しているLANやインターネットの多くでは同じ種類のプロトコルが利用されている。</p><p name="vQvUF">&nbsp;</p><p name="vQvUF">以上とします。</p><p name="vQvUF"><br>ここまでの内容は、自分の言葉でも、なんとなく人に伝えられるようになりました。</p><p name="vQvUF">&nbsp;</p><p name="vQvUF">こめじるし ※ を付ける基準は、私が、あれっと思って調べたかどうかです。</p><p name="vQvUF"><br>私の基準に従えば、だいたいの初心者に共感をしてもらえるかと思います。<br>ぎりぎりプロトコルはわかる程度でした。笑<br><br>イントラネットは、わかっていたつもりでしたが、うまく日本語で説明できないものですね…。</p><p name="vQvUF">&nbsp;</p><p name="vQvUF">引き続き頑張ります。</p><p name="vQvUF">&nbsp;</p><p name="vQvUF">&nbsp;</p></main>
]]>
</description>
<link>https://ameblo.jp/halhalhal44/entry-12679509418.html</link>
<pubDate>Wed, 09 Jun 2021 07:47:17 +0900</pubDate>
</item>
<item>
<title>ごあいさつ</title>
<description>
<![CDATA[ <p>こんにちは。ひよこです。</p><p>&nbsp;</p><p>好きな食べ物は、さいきんは、ふかし芋です。</p><p>&nbsp;</p><p>なにもできない、知らないまま</p><p>夢だけ背負ってIT企業に入ってしまった新卒2年目です。</p><p>&nbsp;</p><p>ゼロからという言葉の甘えから脱却するためにはじめます。</p><p><br>わからないことだらけの日々ですが、</p><p>どんなに小さな学びも自分のものとなるよう、</p><p>願いと思いをこめてここに記していきたいと思います。</p><p>&nbsp;</p><p>&nbsp;</p><p><a href="https://stat.ameba.jp/user_images/20210609/07/halhalhal44/58/51/j/o1280128014954622412.jpg"><img alt="" height="420" src="https://stat.ameba.jp/user_images/20210609/07/halhalhal44/58/51/j/o1280128014954622412.jpg" width="420"></a></p>
]]>
</description>
<link>https://ameblo.jp/halhalhal44/entry-12679504406.html</link>
<pubDate>Wed, 09 Jun 2021 07:07:30 +0900</pubDate>
</item>
</channel>
</rss>
