Microsoft Stream :プレイリストとアクセス権限

4日ほど前に Microsoft Stream ( on SharePoint ) に動画を整理できる「プレイリスト」の機能が追加された記事を書きました。

Microsoft Stream :動画を整理できるプレイリストが使えるようになった

あ、まず先に訂正をしなければいけない部分があって(上の記事は訂正済)、記事を書いている時はプレイリストの保存先は「 Microsoft 365 グループ が表示される」と書いていましたが、よく見たら間違いでした。正しくは「 SharePoint サイト が表示される」でした。 ちょっとスクロールすればコミュニケーションサイトも表示されていたんですよね。適当に確認しちゃダメですねぇ。

話を戻して、この記事の最下部に今後の予告みたいに、プレイリストに保存した動画ファイルのアクセス権はどうなるのか?を試したいって書いていたんだけど、今回はそれを取り上げてみます。

“Microsoft Stream :プレイリストとアクセス権限” の続きを読む

Microsoft Teams :チャットのスケジュール送信に添付したファイルのアクセス権限は?

※あくまでも僕が自分の環境で実際に試してみた結果をベースにしています。

Microsoft Teams のチャットでメッセージをスケジュール送信できるようになったのが先月2022年12月です。

Microsoft Teams :チャットのメッセージをスケジュール送信できるようになった

さて、この記事には書いていないけど、この機能で気になる点がありました。それを今回は試してみたいと思います。何かというとスケジュール送信を設定したメッセージにファイルを添付している場合は、ファイルのアクセス権限がどうなっているのか?という点です。メッセージが送信されるまでは添付したファイルは他ユーザーが表示できるのか?どんなアクセス許可の設定がされているのか?

なぜ気になったのか?というと、実は Microsoft 365 管理センターのメッセージセンターのこの機能アップデートについての該当メッセージにちょっと記載があるんです。

▼「(更新済み)Teams チャットの送信をスケジュールする」から一部抜粋引用

「インライン画像と添付ファイルは、メッセージが配信された後にのみチャット内の他のユーザーがアクセスできます。」という事です。つまりスケジュール設定されたメッセージに添付したファイルは配信前には他ユーザーはアクセスできないという事ですよね。ただし、そもそもメッセージセンターのメッセージは英語を機械翻訳で日本語にしているので、細かいニュアンスが正しく翻訳されていない可能性もあります。なので実際に試してみます。

“Microsoft Teams :チャットのスケジュール送信に添付したファイルのアクセス権限は?” の続きを読む

Microsoft Teams :ライブ コンポーネントの気になるアクセス権限・共有

※ この記事で本ブログの投稿数が998件。1000件まであと少し!


Microsoft Teams のチャットで利用できる(展開中)ようになったライブ コンポーネントについて、記事を分けてシリーズ化している第3弾。アクセス権限・共有について。第2弾の記事でデータの保存先が OneDrive だという事がわかったので、結果的にはチャットの添付ファイルと同じなんですけど、一応触りながら確認してみます。

▼ライブコンポーネントの下書き状態

送信する前の下書き状態の時に、黄色い矢印の先にある部分。これが共有リンクの設定です。クリックすると、

▼リンクの設定画面が表示されます

“Microsoft Teams :ライブ コンポーネントの気になるアクセス権限・共有” の続きを読む

Microsoft Flow : SharePoint のアクセス権限を操作するアクションが追加された( 権限追加 編 )

前回の記事では権限削除をするアクションについて触れてみました。

Microsoft Flow : SharePoint のアクセス権限を操作するアクションが追加された!( 権限削除 編 )

今回は一度アクセス権限が削除されたアイテムに続いて権限追加をするアクションを試したいと思います。

“Microsoft Flow : SharePoint のアクセス権限を操作するアクションが追加された( 権限追加 編 )” の続きを読む

Microsoft Flow : SharePoint のアクセス権限を操作するアクションが追加された!( 権限削除 編 )

▼ついに来たこのアクション!「 Stop sharing an item or a folder 」

▼さらに!「 Grant access to an item or a folder 」

まだ日本語訳されていないところが初々しいですね。そのうち翻訳されて「あれ?あのアクション消えたぞ」ってなると思いますが、そういう時は冷静に全アクションを見渡しましょう。日本語になっているハズです。

「 Stop sharing an item or a folder 」は自動翻訳では「アイテムまたはフォルダの共有を停止する」となります。

「 Grant access to an item or a folder 」は自動翻訳では「アイテムまたはフォルダへのアクセス権を付与する」となります。

つまり、1つ目はアクセス権の削除で、2つ目はアクセス権の付与となります。今までこれを実現させるには「SharePoint に HTTP 要求を送信します」アクションを使って難しい事をしないと実現できませんでした。少なくとも非エンジニアにとっては敷居の高い方法です。それが今回のアクションの追加で気軽にアクセス権限が操作できるようになりました。今回はまず1つ目の「 Stop sharing an item or a folder 」を試してみます。

“Microsoft Flow : SharePoint のアクセス権限を操作するアクションが追加された!( 権限削除 編 )” の続きを読む

SharePoint アンケートリストのアクセス権限で注意すべきポイント

↑実際起きたらおそろしい…

SharePoint のアンケートリストは簡易的にアンケートを実施するには手頃なので、アプリの中では割と利用頻度の高い部類かと思います。ただし、色々注意すべきポイントがあるので過去に記事にしてきました。

今回も(仮想の)トラブル事例を元に注意すべきポイントを書いていきたいと思います。

アンケート用のサイトがあったとします。詳細には以下のような設定です。

  • 全就労者対象や、(職種別など)組織を跨った対象にアンケートを開催したい要望が多いので、全社ポータルの配下にアンケート用サブサイトを作成した。
    (もしくは別途サイトコレクションでも可。つまりアンケートに特化したサイトがあるという事。)
  • アンケートサイト自体の管理は運営部門がおこなっているが、アンケートの作成・集計などの代行は行わない。
  • アンケート開催要望があると、希望者が自由にアンケートリストを作成できるよう「デザイン」権限をサイトに対して付与し、「アンケート作成者」と呼ぶ。
  • アンケート作成者は、永続的にアンケートを開催できるように、一度付与したデザイン権限は基本的に削除しない。
  • アンケートサイト全体には、全就労者に投稿権限を付与し、アンケートに回答ができるようにしている。
  • アンケート作成者には、マニュアルを付与し、自由に利用してもらう。
  • アンケートリストの詳細設定で、読み取りアクセス権を「ユーザー本人が作成した回答」に変更する事を必須とする。
    (もしくはその設定を施したカスタムリストテンプレートからアンケートを作成させるようにする。)

このような方法で運営をスタートし、アンケートリストの細かい不満は聞くものの、結構重宝され、運営する事数年経過…。最近とあるウワサを耳にしました。

「アンケートサイトは、回答内容が見放題らしいぞ!」
「○○さんの趣味は意外にもクラッシックバレエらしいぞ!アンケートサイトの回答に書いてあった。」
などなど。

このようなウワサが耳に入ってきたので、運営部門は徹底的に調べたところ、以下の事が判明しました。

  • 回答者は自分の回答以外は閲覧できない。(想定内)
  • アンケート作成者は、自分の管理するアンケートについては、集計するために全回答を閲覧できる。(想定内)
  • アンケート作成者は、自分が管理するアンケートに関わらず、アンケートサイト内全てのアンケートについて、全回答を閲覧できる!(想定外)

こんな感じです。
つまり、ひとたびアンケート作成者になりサイトに対してデザイン権限を付与されれば、読み取りアクセス権を適切に設定したところで、全ての回答が閲覧できてしまうんです。また、恐ろしい事に、アンケートリストの設定では、デフォルトで回答が検索対象なので、検索から他人の回答にたどり着いてしまう場合もあります。

上述のウワサについては、回答内容が見放題なのはアンケート作成者だし、○○さんの趣味がクラッシックバレエなのを見てウワサを流したのもアンケート作成者の誰かという事です。

人としてのモラルの問題でもありますが、秘密は垣間見たくなるのもこれまた人なので、やはりシステム的に制御しないとダメそうですよね。

これ、実はリストの詳細設定のアイテムごとの権限のところに、注意事項として記載されているんですよね。非常に見落としがちですが。

こうやって穴が存在している事に気がつかずに何年も運営されているなんて事は、ありえ…なくはないですよね。特にサイト管理者は往々にして自身にフルコントロール権限が付与されている事からも、各権限の挙動を検証しないで実装しがちで、気がつかない場合が多いです。

さて、今回の場合は、どのような対策をすれば解決されるでしょうか。これまた解答ではなく、考察とさせていただきます。

チェックアウトの取り消し権限というのはつまり…アクセス許可レベルの中でも「リストの動作を無視」という項目に該当すると思います。「デザイン」アクセス許可レベルではここがチェックされていました。

この項目をチェックから外したらどうでしょうか?これがダメなんですよね。
このチェックを外してしまうと、アンケート作成者は自分の管理するアンケートすら全回答が閲覧できなくなるので、スプレッドシートに保存をしても権限不足で集計ができません。

▼チェックを外した状態で自分のアンケートリストを見ると、本当は回答があるのに表示されません。

▼この状態でスプレッドシートに保存をしても、集計はされません。

こうなるとアクセス権限をサイト単位ではなくアンケートリスト単位で設定するしかなさそうです。そうなると結局サイト管理者の手間が増えます。
なぜかというと、アンケートリスト単位でアクセス権限を設定する場合、その設定はアンケート作成者では行えず、サイト管理者が行うしかないからです。

そもそも機微な情報を取得する目的でアンケートを開催する際には、たとえ社内であっても気軽にやれるものではない意識付けにもなるのかなとは思います。ポジティブに考えれば。

ただ、中には機微な情報ではないフランクな目的のアンケートもあるので、それも同じセキュリティレベル(手間)で運営しなくても良いかもしれません。そういう意味では、セキュリティレベルで運営方法を分岐させる方法もアリかもしれません。つまり、機微情報を含まないアンケートは今まで通りアンケート作成者が自由に作成・集計できるものとし、機微情報を含むアンケートの場合は、サイト管理者が個別の権限設定を施したアンケートリストを提供する。これなら機微情報を含むアンケートのみサイト管理者の手間が増えるだけなので、まだマシなのかなと思います。機微情報の有無を判断するのが難しい時もあるし、面倒だから機微情報が含まれているのに含まれていない方で実施されてしまう可能性もありますが、こうなるとさすがにモラルの問題かと思います。

このようにあくまでも一例ですが、このようなトラブルにつながりかねないという事と、解決方法も一つではなく様々な角度から検討し、最適解を探し出す必要があります。

アンケートはアンケートサイトではなく、各部門サイトやチームサイトの管理人に任せている場合も、その中のアンケートリストは、属しているサイトでデザイン権限以上のユーザーであれば、やはり他人の回答を見る事が可能だし。

とはいえ、Office 365 も色々なアプリやサービスが増え、ユーザーにとって色々な選択肢が増えたはいいけど、中には管理者が管理しきれないところもあり、アクセス権限を厳密・厳格に行う事は難しく、やはり利用者のITリテラシーやモラルにかかってくるのかなぁ?なんてスッキリしない感じで今回も〆させていただきます。

SharePoint ページ右上の歯車メニューが権限レベルに応じて表示・非表示をCSSで実現する方法

SharePoint2007からよくあるサイト管理者からの要望に、「『サイト コンテンツ』を閲覧者や投稿者に見られたくない。」があります。

SharePoint2013ではサイドリンクバーの「サイト コンテンツ」へのリンクは削除できるようになりました。ただし、ページ右上の歯車アイコンをクリックすると、権限がフルコントロールだろうが閲覧だろうが表示されるメニュー内には依然として「サイト コンテンツ」は表示されています。

ここを非表示にするためだけに、マスターページをカスタマイズするのは嫌ですよね。僕は嫌です。そこでCSSを用いて非表示にします。SharePointをCSSでカスタマイズする際におそらく最も利用されるであろうdisplay:none;の登場です。

.ms-siteactions-normal { display:none; }

これをCSSファイルにして、対象ページにスクリプトエディターWebパーツなどを配置してCSSファイルのリンクを記述するか、対象がサイトであれば代替CSSで設定すればOKです。(発行機能が非アクティブ状態で代替CSSファイルを設定したい場合は、ググると情報が出てきます。)

これでサイト コンテンツへのリンクは非表示になったので、直接URLを叩かない限りは見られる事はなくなります。

と、ここまでは他にも紹介しているブログなどはあります。しかし、この方法には弱点があります。閲覧者や投稿者だけでなく、フルコントロール権限であっても非表示になってしまうので、サイト管理者がサイトの設定を行う導線まで奪ってしまうのです。

では、閲覧者や投稿者は非表示にし、フルコントロールは表示させる方法が、CSSと標準機能のみで実現できるでしょうか?
答えは「できます!」
ヒントは「全員非表示、フルコン復活」です。

■方法

CSSファイルを置くライブラリの権限を設定すれば可能です。

【1】まずは全員非表示
これはすでに上で紹介した方法で非表示にします。ここまでは同じです。

【2】フルコンのみ表示復活
・新規に表示復活用ライブラリを作成
・権限の継承を中止
・フルコン以外の権限設定を削除
・ライブラリに以下の内容のCSSファイルをアップ。

.ms-siteactions-normal { display:inline-block; }

【3-1】適用(対象がページの場合)
対象ページにスクリプトエディターWebパーツなどを追加し、2個のCSSファイルのリンクを記述。
※この場合、【2】でアップしたCSSファイルのリンクを必ず【1】のCSSファイルのリンクよりも下に記述してください。(!importantでもOKですが、ムダに使いたくないので。)

【3-2】適用(対象がサイトの場合)
代替CSSの設定は1ファイルのみなので@importを使い2個のCSSファイルのインポートを記述した3個目のCSSファイルを作成し、【1】の時にアップしたライブラリにアップし、代替CSSの設定で適用。
※同じく、@importの記述では記述の順番に気をつけてください。

以上です。
若干複雑ですが、マスターページをイジるよりはマシかと思います。また、この方法を使えば、歯車メニューのみならず、様々な場所で「閲覧・投稿ユーザーのみ表示させたくない」が実現できます。もちろん「閲覧のみ表示させたくない」などのバリエーションも可能ですね。

このようにSharePointを利活用する場合、基本機能ではかゆいところに手が届かない場面が多々ありますが、その際に難しい開発やカスタマイズを行いリスクが伴うよりは、このように基本機能とリスクや難易度が低い方法の組み合わせをパズルのように考える事で、実現できてしまうケースもあり、ここがまたSharePointの楽しいところでもあるのかなと思います。

SharePoint サイトのホームページ(トップページ)をサイト管理者以外に触られたくない

SharePointを運営していると、サイト管理者からよくある問い合わせがあります。「トップページがサイト管理者以外の人にチェックアウトされる事がよくある。」アクセス権限設定は問題なく、チェックアウトした本人に確認すると身に覚えがないとの事。
この場合、「チェックアウトしている人はそのサイトに対して投稿権限が付与されていませんか?」と聞き返せばほぼ100%「そうです。」と返答が来ます。つまり、ページも(チームサイトの場合)「サイトのページ」というライブラリの1アイテムなので、サイトに対して投稿権限があれば編集ができてしまう事。

一般的な考えとしては、サイトのトップページはサイト管理者しかイジれないと思ってしまいがちです。サイト管理者も投稿者もその仕組みを知らずに、投稿者が興味本位または操作ミスでページを編集モードにしてしまい、自然とチェックアウトされたままになっている状態。

さて、この場合、そういうものだと説明すると必ず「なんとかなりませんか?」と言われます。この場合も対応は以下の通りです。

【1】サイト内でホームページ以外でページの利用をしない場合
●「サイトのページ」ライブラリの権限設定を変更
・権限の継承を中止
・サイト管理者以外のSharePointグループおよびユーザーを閲覧権限に変更

【2】サイト内でホームページ以外でページの利用がされている場合
●「サイトのページ」ライブラリ内の「ホーム」ページの権限設定を変更
・権限の継承を中止
・サイト管理者以外のSharePointグループおよびユーザーを閲覧権限に変更

これで投稿権限ユーザーもホームページに対しては閲覧権限になるので、チェックアウトをされてしまう事がなくなります。

ただし、権限の継承を中止した事の注意点としては、サイトの権限を変更した場合は、忘れずに継承を中止した箇所も同じ設定にしましょう。意外とこれを失念して、サイトに新規ユーザーに権限を付与したのに、ホームページに権限を付与し忘れているからアクセスできないなんてトラブルもあります。

ちなみに問い合わせが来てから解決するまで、これを説明するのも相手次第では結構対応が大変になります。説明を求められたり、打ち合わせの席を設けられたり。

SharePointを導入する(している)企業のIT部門や運営部門は、やはり利用者への教育は必要だと思います。

SharePoint でアクセス権限を付与する際に気をつけたい事 ~電子メール招待状~

SharePointでは何をする・させるにしても権限付与の作業が必要ですよね。ユーザーに直接アクセス許可を付与したり、SharePointグループにユーザーを追加したり。ユーザーだけでなくセキュリティグループなどを追加したり。

その中の注意点は色々ありますが、今回注目する点は招待状メールの送信機能です。文字通り、権限が付与されると該当ユーザーに招待状メールが届く機能ですが、権限付与画面で送信するかしないかのチェックボックスがあります。初期値はチェックされた状態、つまり招待状メールが送信される状態です。これがなかなか怖い。

TPOで送信するかしないかをチェックボックスで選べば良いだけなのですが、使い方を間違えるとスパムメール的にもなってしまいますし、管理者に問い合わせが殺到するような事にもなりかねないです。初期値がチェックされた状態なので、ウッカリも多いです。

これ、SharePoint2007では、付与する前に目に見えるところにチェックボックスがあったんですよね(SharePoint2010もそうだったような気がしますが、記憶が…)。試した事がないのでわからないけど、「NT AUTHORITY\Authenticated Users」に権限を付与する際に、このチェックボックスがチェックされた状態で権限を付与したら…いわゆる全従業員にメールが送信されてしまうんでしょうかね。そしたら従業員数が多い会社ほど事故ですよね。怖いんでいつもこの作業をする場合は慎重にチェックが外れている事を確認して付与していました。

で、これは個人的は元に戻してもらいたいと思っているのですが、SharePoint2013ではこのチェックボックスがかなり気がつかないところにあるんですよね。というより隠されているんです。SharePoint2013に触れはじめた時は、メール招待状の機能自体がなくなったのかな?と思うくらい。でも、まだ存在するんですよね。しかもチェックされた状態は変わらず、余計事故が起きやすい状態で。

161226_01
具体的には左下にひっそりと「オプションの表示」というテキストがあり、これがリンクテキストだという事すらなかなか気がつかず、これをクリックすると展開され、その中にチェックボックスがあるんですよね。

161226_02
わざわざ、初期値がチェックされた状態で。これはトラップ??と思うくらい。

さて、それではどうしたら少しでも事故やトラブルが防げるのか?ググると同じように初期値がチェックされた状態を危惧する声もあり、初期値ではチェックが外れているように設定で変更できないか?という問い合わせもあり、サイトコレクションの設定やサーバーの全体管理からは変更できず、サーバー内のとあるファイルをイジる解決方法があるのですが、Microsoftのサポート対象外になってしまうという点からも、ちょっと厳しいのではと思います。

あとは必殺「運用でカバー」ですよね。

まずは、利用者に招待状メールを周知させる方法。つまり、送信されてしまった後を考える事。そうすれば少なくともサーバー管理者への問い合わせは減るのかなと思いますが、若干ネガティブな対策です。

次に、アクセス権限を設定できるサイト管理者などへの教育・周知という方法。つまり、送信される前を考える事。ただし、サイト管理者が多いほど、ヒューマンエラーの確率が増えますね。ホント、ウッカリ失念してしまいがちなので。

次に、アクセス権限の設定はサーバー管理者が掌握する方法。つまり、権限管理自体を特定多数(不特定多数)に管理させない事。実際にアクセス権限の問題はかなり多岐に渡るトラブルや問題にもなるので、サイト管理者にアクセス権限の設定ができないアクセス許可レベルを付与している会社も、少なくはないと思います。これにより一極集中してしまったサーバー管理者の作業は大変になりますが、より把握している者が作業をすることにより、ヒューマンエラーの確率はサイト管理者にアクセス権限管理を委譲するよりは、減ると思います。

Microsoftのサポート対象外になってしまっても構わない場合は、設定レベルでチェックを初期値では外す方法が理想なのかもしれないです。(サーバーの全体管理やサイトコレクションの管理で容易に設定できれば良いのですけどね。)それ以外の場合は、各環境に合わせ、上述のようないわゆる運用でカバーをしていくしかないっぽいです。

ちなみに僕は今までおよそ何千何万回も設定をしてきましたが、一度もこれで事故やクレームはありませんでした。実際運営していると招待状メールが必要な事は全くありませんでした。例えばとある部署が自部署のサイトを公開する際には、だいたいサイト管理者か部署の部長さんあたりが自分から部内や周知したい人たちにメールをしたり、社内ポータルの掲示板に掲載したりする場合がほとんどでしたからね。

なので、とにかくチェックを外すクセを徹底的につけていました。