Active Directoryによる集中管理を可能にするGP。NTのシステム・ポリシーとの違いを明らかにし、GPオブジェクトの内部を探ってみよう。 前回は、「グループ・ポリシー」を理解する準備として、その前身である「システム・ポリシー」について解説した。システム・ポリシーとは、簡単にいえば、コンピュータのレジストリ設定を統一管理するためのメカニズムであり、例えばユーザーのデスクトップ環境を変更/統一したり、Webブラウザの設定を変更したりできる。だが、システム・ポリシーではレジストリの設定しか操作することができないし、階層的な管理ができない、デフォルト設定に戻すのが困難、用意されているテンプレート機能が不足など、機能的に不十分な点も少なくない。特に、大規模な組織では、システム・ポリシーでは十分に管理することが困難である。 このような問題を解決するため、Active Directoryでは
Cryptographic Services(Crypt API)の診断情報の構成と確認 certutilなどで証明機関の構成や発行された証明書の整合性を検査しても問題ないが、 一部のクライアントで接続が失敗するようなケースでは Cryptographic Services(Crypt API)のログを調査することで解決するケースがある。 ■Crypt APIログの有効化 イベントビューアでツリーを展開し、CAPI2からOperationalのプロパティを開く 「ログを有効にする」にチェックを付ける 証明書ストアを操作するプログラムが動作するとログが出力されるようになる ■Crypt API詳細ログの有効化 前述のCrypt APIログの有効化に加えてレジストリを変更することで より詳細なログを出力させることができる レジストリエディタで以下の値を追加 キー名: HKEY_LOCAL_MA
前回はDNSサーバがレコード情報を格納する前方参照ゾーンと逆引き参照ゾーンについて、設定変更の手順と内容を解説した。今回はさらに階層をひとつ上げて、DNSサーバそのものの設定変更について取り上げる。 ここで必要とする機能は実質的に、DNSフォワーダに限られるだろう。これは、LAN内部でActive Directoryと組み合わせてDNSサーバを運用している場合に、さらにインターネット向けの名前解決を可能にするための機能である。 DNSフォワーダの設定 LANでActive Directoryを構築して、DNSサーバを組み合わせて運用している場合、クライアントPCのDNSサーバアドレスは、LAN内で稼働しているWindowsサーバ上のDNSサーバになる。ところが、そのDNSサーバはLAN上で稼働しているホストに関するレコードしか持っていないから、インターネット側の名前解決はできない。 そこで
認可と認証技術 OAuth 1.0、OAuth 2.0 および OpenID Connect に関するスライドをアップしました。 アプリ開発で知っておきたい認証技術 - OAuth 1.0 + OAuth 2.0 + OpenID Connect - from Naoki Nagazumi www.slideshare.net 開発している Web アプリで、OAuth 1.0 や OAuth 2.0 および OpenID Connect の認可と認証技術を組み込んだ時に、あれこれ調査して知り得た技術をまとめたものです。 130ページくらいの力作です!ぜひご覧ください。 デモ これのデモはこちらにあります AuthsDemo デモのソースコードはこちらです。 GitHub - ngzm/auths-demo: This is a demo program with using OAuth
またもやTomcatでハマってしまったので、ちょっとまとめておこうと思う。Tomcatでのwarファイルの扱いと、コンテキストパスと、自動デプロイについて。 Tomcatのデプロイとwarファイル Tomcatではアプリケーションをデプロイするには、warファイルという、Webアプリケーションに必要なclassファイル・jarファイル・jspファイルやWEB-INF/xmlファイルなどをまとめてひとかたまりにしたファイルを配置してデプロイする。 このwarファイルは実質はただのzipファイルであるため、unzipコマンドで展開して中身を覗いてみることもできる。 $ file struts2-showcase.war struts2-showcase.war: Zip archive data, at least v1.0 to extract $ unzip struts2-showcas
NOTE: 本記事はすでに内容が古く、今読んでも役に立つ度合いはほぼないです。 本記事は、先日社内勉強会のために準備した、Webサービスのリアルタイム通信周りのまとめシリーズ の1つを転載して公開するものです。 まだまだわかっていないことが多いので、ぜひぜひ間違っている点などにご指摘いただければと思い公開します。 ぜひぜひ優しくマサカリをいただけると泣いて喜びます! 目次 目次 はじめに プロトコルと手法 前世代のやり方であるComet について Polling 系 Streaming 系 過渡期といわれてる手法 将来有望といわれてる手法 Polling メリット デメリット 向いているシーン Long Polling (Comet) Polling の発展版 メリット デメリット LongPolling 自体は双方向通信ではない 接続が閉じられるケース 向いているシーン Server S
これはちゃんとチェックしておかないとなぁ。 Deprecated Linux networking commands and their replacements « Doug Vitale Tech Blog ==== この記事で詳しく説明する非推奨のLinuxネットワークコマンドは:arp, ifconfig, iptunnel, iwconfig, nameif, netstat, route である。iwconfig以外の コマンドは、net-toolsパッケージという、数年間メンテナンスされていないパッケージに含まれている。これらのユーティリティによって提供される機能は、新しいipコマンドを主に使うiproute2 スイートで再提供され、改善され続けている。iproute2ソフトウェアのコードとドキュメントは、Kernel.orgとLinux Foundationで見ることができ
最近「Tera Term(テラターム)を使用して、サーバに接続しようとしているんですが、うまく繋がらないんです!」って質問を数多く受けるんです。 原因の多くが、サーバ側の設定(アクセス制限)で接続出来ない場合が多いみたいですが、中にはSSH認証(ユーザ名・パスフレーズ入力画面)までは表示されるけど、「ユーザ名」「パスフレーズ」を入力し「OK」ボタンを押しても何も動かないといった、何となく微妙なパターンもあるみたいです。 そこでここでは「SSH接続トラブルシューティング」と銘うって、TeraTermを使用してサーバへ接続できないであろう6パターンを用意し、それぞれがどんな表示・動作になるのかを実験&纏めてみました。 今回、以下の環境でテストを実施しています。 接続先サーバ:さくらのVPS CentOS6.4 64bit openssh-server-5.3p1 クライアント:Windows7
インフラエンジニアの多分、華形のお仕事の1つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
TCP/IP関連のトラブルシューティングを行う場合に、必ずといってよいほど使うコマンドとして「netstat」コマンドがある(実行ファイル名はnetstat.exe)。このコマンドは、主にTCPの通信状態を調べるためには必須であり、ぜひともその使い方をマスターしておきたい。 netstatの基本――通信中のTCPコネクションの調査 netstatコマンドの最も基本的な使い方は、通信中のTCPコネクション(TCP接続)の状態を表示させることである。このコマンドを実行すると、ローカルPCのTCP/IPプロトコルスタック上において、現在アクティブになっているTCP通信の状態を表示できる。 ●「TCP」とは? 「コネクション」とは? TCPとは、2つのアプリケーション間で、信頼性のある通信路(コネクション)を開設し、お互いにデータなどをやりとりするための機能である。通信するアプリケーションは、同一
なんですかこれは! New attack bypasses HTTPS protection on Macs, Windows, and Linux DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって? Web Proxy Autodiscovery ですって? チョットニホンゴデオネガイシマス ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。 Authorization Request & Response が漏れる response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 /
そうなると、当然出てくる疑問があります。 「ママ、もしかしたらオンプレミスの Active Directory っていらなくなるんじゃない?」 「うーん、どうなのかしら?」 「だってさ、OpenID Connect もしゃべれないのよ!」 「そうね。Authorization Code Grant も Public Client だけだしねぇ。」 「そうそう! こんなんじゃ、誰もオンプレミスで OAuth 2.0 なんて使わないじゃない!」 「今晩、パパに相談してみようかしら」 おっしゃるとおり、Windows Server 2012 R2 では Azure AD のように OpenID Connect がサポートされていませんし、 OAuth 2.0 のグラントタイプも Authorization Code Grant for Public Client のみです。 このまま放置すると、
1. SQL SERVER FOR SHAREPOINT指南 December 13th 2014 Mayumi Mitaki Advanced Solution Co,Ltd Manager 2. 自己紹介 SharePoint歴 2007年 以前 某SIerグループ会社に所属。 Windows Server OS,SQL Server の製品評価、 サポート、導入案件を担当。 2007年 SharePoint2007に初めて触る。 2007製品評価、サポートを担当。 Windows Server,MSFC,SQL Serverの導入構築 も継続。 2008年 2009年 2007製品評価、サポート、構築案件のリーダーを担当 する。 OS,MSFC,SQL,SharePointをまとめて設計、構築す るチームとして案件を手掛ける。 2010年 2011年 2007に加えて、2010製品評
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く