Skip navigation

Blog Posts

Total : 4,720

Blog Posts

1 2 Previous Next

vSphere 7.0 U1 リリースにあわせて、

vSphere with Kubernetes が vSphere with Tanzu になりました。

VMware vSphere with Tanzu リリース ノート


そして、NSX-T なしでも Tanzu Kubernetes クラスタを作成できるようになったので、




vSphere with Tanzu について


このうち、NSX-T ではなく vSphere ネットワーク(vDS)を利用する場合の要件は、


vSphere ネットワークを使用して スーパーバイザー クラスタ を設定するためのシステム要件およびトポロジ



下記にある Quick Start Guide が参考になります。


ちなみに、vSphere 7.0 GA 時点の時と同様に、NSX-T を利用した環境構築も可能です。


vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。(NSX-T あり編)




  1. 前提とするラボ環境の説明。(vSphere 環境の構築については、今回は省略)
  2. HAProxy のデプロイ。
  3. 「ワークロード管理」の有効化。
  4. Tanzu Kubernetes クラスタの作成。




「Ext GW」は各ネットワークのゲートウェイとなるルータです。




vSphere Client での完成イメージは、下記のような感じです。

スーパーバイザー クラスタの名前空間、Tanzu Kubernetes クラスタを作成します。


  • スーパーバイザー クラスタ: wcp-cluster-04
  • スーパーバイザー名前空間: lab-ns-41
  • Tanzu Kubernetes クラスタ: tanzu-cluster-41




  • vCenter Server 7.0 U1、仮想スイッチは vDS 7.0(NSX-T なし)
  • ESXi 7.0 U1
  • ロードバランサは HAProxy



それでは、これからの vSphere with Tanzu 環境構築の前提とする、ラボ環境について説明します。

vSphere の構築については省略していますが、以前に紹介したものと同様にネステッド環境で構築しています。

vSphere with Kubernetes ラボ環境構築。(まとめ)


vCenter 7.0 U1 に、ESXi 7.0 U1 (4台)のクラスタを構築してあります。



(今回の手順には関係しませんが)クラスタには 3台の vCLS VM が自動デプロイされています。



vSphere HA / DRS も有効化してあります。



仮想スイッチは、バージョン 7.0 の分散仮想スイッチ(vDS) です。



vDS には、vSphere with Tanzu で利用する 3種類のネットワークむけに、


  • 管理ネットワーク: DPortGroup-0010-MGMT、VLAN ID 10
  • ワークロード ネットワーク 1(プライマリ): DPortGroup-0021-WL1、VLAN ID 21
  • ワークロード ネットワーク 2: DPortGroup-0022-WL2、VLAN ID 22

そして物理ネットワークも、これらの VLAN での通信ができるように構成ずみです。



データストアには、vCenter の機能によるタグを割り当てずみです。

また、データストアに割り当てたタグを指定した、仮想マシン ストレージ ポリシーも作成ずみです。


vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編


NFS データストアを、クラスタ内の全 ESXi ホストにマウントしてあります。

データストアには、タグ(タグ名は wcp-demo、カテゴリは datastore-category)を割り当ててあります。



データストアに割り当てたタグを指定した、仮想マシン ストレージ ポリシーも作成ずみです。



Tanzu Kubernetes Grid のコンテンツ ライブラリも作成ずみです。


vSphere 7.0 U1 からは、事前作成が必要になりました。

コンテンツ ライブラリは下記のように作成しています。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編


今回は、cl-tkg-01 という名前でコンテンツ ライブラリを作成しています。



Tanzu Kubernetes クラスタのノードとしてデプロイされる、OVF テンプレートがダウンロードされています。

複数の Kubernetes バージョンのものが用意されていることがわかります。




How to set Goal in life and Why it is important to set Goal. What is the change comes in life by setting Goal. Today you will get the answer to every question.


Have you ever traveled When you travel somewhere, you have to take a ticket to where you have to go. If you go to the ticket counter and the ticket receptionist asks you where you want to go and you will say "nowhere", will you be able to go anywhere?


Similarly, if we want to get something in our life or to reach a destination, then we must first set up a goal of our life.


What is Goal?


Before setting the goal, let us know what the goal means. A goal is a predetermined task that a person tries to complete within a certain time frame. Different people set different goals in their life according to their wish, for example, if someone wants to become a cricketer, a singer a dancer or an artist.


Why It is Important to Set a Goal in Life:



Have you ever got a house built? Or ever seen a house being built? When we build a house, complete planning has to be done to get it built. If we do not do planning, then the structure of the house will become crooked.


The same thing applies to life too. If we do not plan about our life or do not set Goal, then our life will also become like a house without a proper structure. When we set goals in life, we know where we have to reach after a certain time and what we have to face to get there.


Psychology also says that people who have goals in their lives have the great enthusiasm in their lives and they are also more intelligent. People who have no goal in life, their lives are very boring and tasteless, they do not have any happiness in their lives and they always complain about their lives and blame others or their luck.


What to Do While Setting a Goal:


Friends, when we build a house, we plan everything where the bedroom should be, where should the kitchen be and in this way we prepare a complete map of the house and then decide how to decorate it. Similarly, while setting goals in our life, we also have to think a lot about various things. Let's see how we should set goals in our life.


Ask yourself some questions:


It is necessary to have a conversation with yourself before setting a goal. In this conversation, you have to ask yourself some questions such as what is the thing that you want to achieve within a set time period. And how long will it take to get that thing and what strategy has to be made, what challenges will come and how to deal with them. All these questions we have to ask ourselves before setting goals.


Create a road map:


The roadmap tells you what you need to do to reach a defined goal and what things you have to face. And you will also have to make a backup plan and if one of your plans fails, then you can switch to another plan. The roadmap will guide you to reach your goal. To create a roadmap, you can take help of someone who has already achieved the goal you want to achieve.


That person will tell you what the person did and what the challenges came to meet that goal and how he / she achieved that goal and you can also make your roadmap by following the same path. You can also take help of internet to create a roadmap.


Create weekly targets:


Small goals help you to reach big goals. If you make small weekly goals, then you will be able to achieve your big goals easily by the prescribed time period. And by setting goals every week, also make sure to observe your performance, for this you can take the help of weekly reports.


Follow the roadmap as much as possible:


The more you follow the roadmap, the greater your chances of being successful. To follow the roadmap successfully, you will have to put your 100% and this will be your biggest test.


Check your performance regularly:


Merely creating a road map and setting targets is not enough. We also have to observe and analyze the work we are doing regularly, which we can do by creating weekly reports. By making weekly reports, we can see if we are following the roadmap and if not, where there is a shortage, how can that deficiency be removed?


Celebrate your Little Achievements:


You can celebrate your small successes, such as giving a treat or a small party to yourself or family or to a best friend. By doing all this, you thicken yourself to achieve more and other people also thicken you.


Read more such articles here:


Read more such articles

How to Set Goal of Life-[No Goals No Success! Must Read]


Know How you can Achieve Anything with Power of Belief !!


[How to Be Successful ] – [3 Amazing LAWS OF SUCCESS]


3 Tips to be Successful in Life -[Your Attitude is Everything ]


How to Achieve Goals-[Has Giving up Become Your Habit?]









/sbin/ntpdate -b -u <ntp server ip>

/sbin/ntpdate -d <ntp server ip>











    48  server <ntp server ip> iburst

    49  trustedkey



実施後は/etc/init.d/ntpd restart でサービスを再起動してください。





iburst設定後や、十分な時間が経過した後でも同期しない場合は、NTPサーバからの情報をNTP Clientが信頼していない場合があります。


# /usr/sbin/ntpdc -c 'showpeer <ntp ip address>'

remote <ntp ip address>, local <ntp ip address>

hmode client, pmode unspec, stratum 2, precision -6

leap 00, refid [], rootdistance 0.03125, rootdispersion 8.30737

ppoll 6, hpoll 6, keyid 0, version 4, association 57089

reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0

timer 0s, flags config, bclient

reference time:      dc0bbd00.3f21a2e7  Tue, Dec 27 2016  1:00:00.246

originate timestamp: dc0c6b35.c3fed202  Tue, Dec 27 2016 13:23:17.765

receive timestamp:   dc0c6b35.c3d4dc75  Tue, Dec 27 2016 13:23:17.764

transmit timestamp:  dc0c6b35.c3bfd0d1  Tue, Dec 27 2016 13:23:17.764

filter delay:  0.00032  0.00032  0.00000  0.00000

               0.00000  0.00000  0.00000  0.00000

filter offset: 0.000801 0.000480 0.000000 0.000000

               0.000000 0.000000 0.000000 0.000000

filter order:  0        1        2        3

               4        5        6        7

offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791



# /usr/sbin/ntpq -classoc

ind assid status  conf reach auth condition  last_event cnt


  1 63674  961a   yes   yes  none  sys.peer    sys_peer  1


# /usr/sbin/ntpq -c "rv 63674"    <<<< rv xxxx のIDは↑のコマンドのassidで確認

associd=63674 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,

srcadr=ntp-sv1.cpsd.local, srcport=123,, dstport=123,

leap=00, stratum=4, precision=-25, rootdelay=350.113, rootdisp=94.040,


reftime=e2b64f76.e5a956e2  Mon, Jul 13 2020  3:11:50.897,

rec=e2b650cc.9a6cec7e  Mon, Jul 13 2020  3:17:32.603, reach=377,

unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,

keyid=0, offset=3.212, delay=0.700, dispersion=19.482, jitter=0.630,


filtdelay=     0.74    0.70    0.74    0.68    0.69    0.73    0.76    0.79,

filtoffset=    3.37    3.21    2.94    2.99    2.91    2.83    2.40    1.89,

filtdisp=      0.00   16.02   32.31   48.08   64.13   79.52   95.43  111.65



このコマンド出力中で注目すべきところは太字で強調したflash のところです。


上の例ではVCSAは0x400 となっており、ESXiでは00 (0x0000)となっています。




#### ヘッダファイル引用
+++++ include/ntp.h
* Define flasher bits (tests 1 through 11 in packet procedure)                                                       
* These reveal the state at the last grumble from the peer and are                                                   
* most handy for diagnosing problems, even if not strictly a state                                                   
* variable in the spec. These are recorded in the peer structure.                                                    
* Packet errors                                                                                                      
#define TEST1           0X0001  /* duplicate packet */
#define TEST2           0x0002  /* bogus packet */
#define TEST3           0x0004  /* protocol unsynchronized */
#define TEST4           0x0008  /* access denied */
#define TEST5           0x0010  /* authentication error */
#define TEST6           0x0020  /* bad synch or stratum */
#define TEST7           0x0040  /* bad header data */
#define TEST8           0x0080  /* autokey error */
#define TEST9           0x0100  /* crypto error */
#define PKT_TEST_MASK   (TEST1 | TEST2 | TEST3 | TEST4 | TEST5 |\
                        TEST6 | TEST7 | TEST8 | TEST9)
* Peer errors                                                                                                        
#define TEST10          0x0200  /* peer bad synch or stratum */
#define TEST11          0x0400  /* peer distance exceeded */
#define TEST12          0x0800  /* peer synchronization loop */
#define TEST13          0x1000  /* peer unreacable */

#define PEER_TEST_MASK  (TEST10 | TEST11 | TEST12 | TEST13)


今回の場合は flash 0x400なので、
TEST11のpeer distance exceededに該当することが分かります。






## /etc/ntp.conf

    48  server <ntp ip address > iburst  <<<< iburst 追記
    49  trustedkey
    51  tos maxdist 30        <<<< 追記



この設定をすれば、少なくともflash 0x400の問題は解消できるはずです。


また、flash codeが正常 (0x00)なのに同期してくれない場合は、messagesログなどにntp デーモンのエラーが吐かれているかもしれませんので確認されることをお勧めします。


(補足)NTPサーバがWindwos OSの場合


おそらく多くの場合はLocalClockDispersion の設定によるものと思われますので、この値が0になっているかを確認されることをお勧めいたします。





VxRail: How to troubleshoot NTP issue in VxRail cluster | Dell US



Miscellaneous Commands and Options

For updates on this blog and other blogs: Follow @SteveIDM


When troubleshooting SAML/OIDC, its extremely useful to have access to your HTTP headers to validate what is being passed from one provider to the next.  This is very straight forward on Windows and MacOS devices but not quite as easy when we need the headers on a mobile device.


There are many tools on the market that can help proxy your mobile traffic. Most people default to Fiddler however I've personally had very little luck with fiddler for this purpose as Fiddler tends to truncate the SAML request thus making it useless for debugging SAML Traffic.  I credit a former colleague of mine, Eugene for introducing me to a tool called MITM Proxy. As the name suggests, its a man in the middle product but useful in troubleshooting.

Please note - This is not an endorsement of this specific tool, its just a tool that I've had success with.  The usual disclaimer with any third party product, please use at your own risk.


Before you start, make sure your Corporate IT department won't block this tool as its quite common. You might see something like this:

Screen Shot 10-15-20 at 09.27 AM.PNG

Getting Started with MITM Proxy

  1. Download MITM Proxy from
  2. Install MITM Proxy as per their instructions.
    Note: Install this proxy on a system that is accessible by your mobile device.
  3. Since running MITM Proxy on Windows 10, I will launch the MITM Proxy UI from the start menu.
    Screen Shot 10-15-20 at 10.36 AM.PNG
  4. If everything goes well, you will see a CMD window displaying the proxy was successfully started and a browser tab open display the debug window.
  5. In my case, it doesn't go well and I get the following error:
    Screen Shot 10-15-20 at 10.40 AM.PNG
    1. This error does not necessarily mean your Corporate IT team is blocking the application (Although I've thought this many times). It most likely means you have a port conflict. Run a netstat and verify that 8080 and 8081 are not being used.
    2. If 8080 is taken, you will need to start this manually in a command window using a free port
      C:\Program Files (x86)\mitmproxy\bin>mitmweb.exe --listen-port 8888
    3. If 8081 is taken, you will need to start this manually in a command window using a free port
      C:\Program Files (x86)\mitmproxy\bin>mitmweb.exe --web-port 8082
      There is a way to make these changes permanent using YAML but I've not figured that out yet.

  6. Hopefully, you now have the application started and you see the console open in a web browser.
    Screen Shot 10-15-20 at 10.49 AM.PNG

    Please Refer to MITM Proxy Troubleshooting for help with any other error to start this application.

Setting up your IOS Device

  1. On your IOS Device, go to your Settings Application
  2. Click on WiFi
  3. Click the "i" beside your WiFi network
    Screen Shot 10-15-20 at 10.58 AM 001.PNG
  4. Click on Configure Proxy at the bottom of the screen
    Screen Shot 10-15-20 at 10.58 AM.PNG
  5. Select Manual
  6. Enter the correct IP Address and Port
    Screen Shot 10-15-20 at 11.00 AM.PNG
  7. Open Safari and verify that you can see traffic in the console by going to any http url ie. (Ignore the connection is not private error).


Installing SSL Certificate for HTTPS Decryption


  1. Open Safari on your mobile device, and go to
    Screen Shot 10-15-20 at 11.26 AM.PNG
  2. Click on the Apple Link to download your profile.
  3. Go to your IOS Profiles and install the downloaded profile.
    Screen Shot 10-15-20 at 11.29 AM.PNG
  4. In the Settings Application, Click on General -> About
    Screen Shot 10-15-20 at 11.32 AM.PNG
  5. Scroll down and click on "Certificate Trust Settings"
  6. Enable Full Trust for the MITM Proxy Certificate
    Screen Shot 10-15-20 at 11.33 AM 001.PNG
  7. You should now see full headers in your web console.
  8. You can use any online SAML Decoder to get full access to the SAML Requests/Responses
    Screen Shot 10-15-20 at 11.36 AM.PNG


How to support Certificate Based Authentication

If you need to perform certificate based authentication, you can not 'intercept' a certificate challenge from the Workspace ONE CAS server. You will need to bypass the Cert Challenge from proxying through MITM

  1. Although you can modify settings on the fly using the UI, its probably easier to add the following switch when starting your MITM Proxy Server:
    mitmweb.exe --web-port 8082 --ignore-hosts "^(cas|cas-aws).*"

Screen Shot 10-15-20 at 12.38 PM.PNG

vSphere 7.0 U1  では「vSphere with Kubernetes」が「vSphere with Tanzu」になり、

製品構成や技術的な面で vSphere 環境で Tanzu Kubernetes Grid による Kubernetes が利用しやすくなりました。

たとえば、NSX-T がなくても Kubernetes が利用できるようになりました。


その一方で、vSphere 7.0 のときと同様の、NSX-T を組み込んだスーパーバイザー クラスタも利用できます。

ただ、スーパーバイザー クラスタを作成する「ワークロード管理」の有効化にも




(若干 vSphere 7.0 からの差分は確認しにくいかなと思います)



なお、おおまかな流れとしては以前に投稿したスーパーバイザー クラスタのラボ構築手順で、

vSphere 7.0 U1 でも環境構築できるはずです。

vSphere with Kubernetes ラボ環境構築。(まとめ)



vSphere や、NSX-T の準備については、vSphere 7.0 時点とほぼ同様です。

ただし、Tanzu Kubernetes Grid(TKG)のコンテンツ ライブラリを、事前に作成しておくようになりました。


vSphere 7.0 時点では、TKG の OVF テンプレートををダウンロードする

コンテンツ ライブラリを、Tanzu Kubernetes Cluster を作成する前に作成する必要がありました。

7.0 U1 では「ワークロード管理」を有効化する前に、コンテンツ ライブラリの準備が必要になります。

コンテンツ ライブラリ未作成の場合は、エラーとなり「ワークロード管理」有効化を開始できません。



そこで、事前準備として TKG のコンテンツ ライブラリを作成しておきます。

これは下記投稿での「コンテンツ ライブラリの準備」にある手順と同様です。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編


ライブラリに含まれる OVF(Kubernetes のバージョン)は増えており、







以前の vSphere 7.0 時点での様子は下記をどうぞ。

vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編


vSphere Client で「メニュー」→「ワークロード管理」を開くと、








「vCenter Server とネットワーク」画面の「ネットワーク スタック オプションを選択します」にて、

「NSX-T」もしくは「vCenter Server Network」を選択します。




「クラスタを選択」の画面は、7.0 と同様に、対象のクラスタを選択します。



ここからは、以前の vSphere 7.0 の頃と同様の情報入力が続きます。




「ストレージ」で、用途ごとに仮想マシン ストレージ ポリシーを選択します。




vSphere 7.0 U1 では、管理とワークロードとで入力画面が明確に分割されました。



「ワークロード ネットワーク」の情報を入力します。



「TKG 構成」は、vSphere 7.0 U1 から追加されました。

事前に作成した、TKG のコンテンツ ライブラリを選択します。

ただし、TKG と同時に Tanzu Kubernetes Cluster が作成されるわけではありません。











Tanzu Kubernetes Cluster の変更点。

Tanzu Kubernetes Cluster(TKC)の作成方法は、vSphere 7.0 と同様です。


vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編


ただし、デフォルトの CNI が Calico から Antrea になりました。

TKC を定義するマニュフェスト(YAML 形式)で CNI を定義していない場合は、Antrea がインストールされます。


例えば、下記のような YAML で TKC を作成してみます。


tkg-cluster-03.yml · GitHub


kind: TanzuKubernetesCluster



  name: tkg-cluster-03



    version: v1.18.5



      count: 1

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp


      count: 1

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp




        cidrBlocks: [""]


        cidrBlocks: [""]


この YAML では、あえて CNI の指定(下記のような)は省略しています。






        name: antrea #or calico



TKC を作成します。

$ kubectl apply -f ./tkg-cluster-03.yml


kubectl vsphere login でログインした後に、作成された TKC を確認すると、

Antrea が利用されていることがわかります。



以上、vSphere 7.0 U1 での「ワークロード管理」有効化の様子でした。

For updates on this blog and other blogs: Follow @SteveIDM


There are many use cases when integrating ADFS with Workspace ONE. In this blog, I'm going to focus on the use case of using Workspace ONE as a claims provider.  The VMware documentation for integrating ADFS and Workspace ONE is quite good. Please reference the VMware Documentation for the official steps on this integration.  My blog is intended to compliment the official  documentation.


In this blog, we will focus on:


Warning - Do NOT Perform any of these steps on a production ADFS Server without testing in a lower environment. Once you add a second claims provider it will impact the experience for your users.

Creating Workspace ONE Access as a Claims Provider

Download Workspace ONE Access Metadata

  1. Log into your Workspace ONE Access Administration Console.
  2. Go to Catalog -> Web Apps
  3. Click on Settings
  4. Click on SAML Metadata
    Screen Shot 10-08-20 at 04.06 PM.PNG
  5. Right-Click and Download your Identity Provider (IdP) Metadata.


Create your Claims Provider Trust

Warning - Do NOT Perform any of these steps on a production ADFS Server without testing in a lower environment. Once you add a second claims provider it will impact the experience for your users.

  1. Launch your ADFS Management Console
  2. Right Click on Claims Provider Trust and click "Add Claims Provider Trust"
    Screen Shot 10-08-20 at 11.25 AM.PNG
  3. Click Start
  4. Select " Import data about the claims provider from a file"
  5. Select the Workspace ONE Metadata file you just downloaded.
  6. Click Next
  7. Select a Display Name that is recognizable to your users. This name will appear on the ADFS Home Realm Discovery Page.
  8. Click Next
  9. Click Next
  10. Click Close


Configure Claim Rules

  1. Right Mouse on the newly created Claims Provider Trust and Click Edit Claims Rules
  2. Click Add Rule
  3. Select "Send Claims Using a Custom Rule" and Click Next
  4. Provide a Rule Name
  5. Paste the following Custom Rule. This rule will transform the incoming claim (Windows Account) and set AD as the source. In using this custom rule, we will not need to modify any existing Relying Parties that are already configured.

    c:[Type == "",

    Properties[""] ==


    => issue(Type = "",

    Issuer = "AD AUTHORITY", OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

    Screen Shot 10-08-20 at 11.47 AM.PNG

  6. Click Finish
  7. Click OK


Configuring the ADFS Application Source in Workspace ONE Access

  1. Download the federation metadata file for the AD FS server by navigating to the URL: https://{ADFSdomain}/FederationMetadata/2007-06/FederationMetadata.xml where {ADFSdomain} is replaced with the fully qualified domain name (FQDN) your AD FS server.
  2. Log into the Workspace ONE Access Admin Console
  3. Select Catalog -> Web Apps
  4. Click the Settings button
  5. Click Application Sources
  6. Click the ADFS Application Source
    Screen Shot 10-08-20 at 03.47 PM.PNG
  7. Click Next
  8. Past the contents of the previously downloaded ADFS Metadata into the URL/XML box. It is recommended you paste the contents rather than pasting the URL.
    Screen Shot 10-08-20 at 03.49 PM.PNG
  9. Click Next
  10. Click Next
  11. Click Save
  12. Click the ADFS Application Source again.
  13. Click the configuration tab
  14. Change the Username Format to Unspecified
  15. Change the Username Value to "${user.domain}\${user.userName}"
    Screen Shot 10-08-20 at 03.53 PM.PNG
  16. Expand Advanced Properties
  17. Set Include Assertion Signature to Yes.
  18. For Signature Algorithm, select SHA256 with RSA.
  19. Change the Digest Algorithm to SHA256
    Screen Shot 10-08-20 at 03.55 PM.PNG
  20. Click Next and Save


Testing the Workspace ONE Claims Provider

  1. Open a Private Browser
  2. Navigate to Service Provider that is using ADFS
    Screen Shot 10-08-20 at 04.09 PM.PNG
  3. Verify that you see the ADFS Home Realm Discovery Page. Note: Your page will look different depending on how many claims providers you have configured.
    Screen Shot 10-08-20 at 04.10 PM.PNG
  4. Select the option for Workspace ONE
  5. Enter your Credentials for Workspace ONE
  6. Verify that Workspace ONE responds with a successful SAML Response. Using a SAML Tracer, you can verify that the NameID is returned in a Domain\username format
    Screen Shot 10-08-20 at 04.14 PM.PNG

Configure Workspace ONE Access as the default Claims Provider for an RP

If you have specific applications where you want to redirect all traffic for that application to Workspace ONE, you can perform the following steps:

  1. On the AD FS server, open a PowerShell session with elevated administrator rights.
  2. Run the following Powershell command

    Set-ADFSRelyingPartyTrust -TargetName "{RP_app}" -ClaimsProviderName "{VMWARE IDENTITY MANAGER CLAIMS PROVIDER}"

    Replace the placeholders in the command as follows.
    Replace {RP_app} with the name of the relying party trust corresponding to the target application.
    Replace {VMWARE IDENTITY MANAGER CLAIMS PROVIDER} with the name of the claims provider trust that you configured for VMware Workspace ONE Access.
    Use the names of the relying party trust and claims provider trust as they appear in the AD FS Management console.



Modifying your Onload.js

Depending on your use case, you may or may not want to do redirect all applications or all platforms for a particular application to Workspace ONE Access. As we saw above, the ADFS Home Realm Discovery page will by default prompt the user to select the claims provider.  Assuming you will not run the previous PowerShell command to default traffic for particular relying party to Workspace ONE Access, we will need to use the onload.js to automate the selection for the users.


We will walk through some of your options in the onload.js. First, lets address some things that you can NOT do:

  • You can not redirect to Workspace ONE Access based on username. Although it may appear that usernames appear in the request, you can not code for this reliably. If you use auto acceleration in Azure AD, you will not get usernames in the request.
  • You can not redirect based on groups.
  • You can not redirect based on network range.
  • You can not redirect based on having an enrolled device in Workspace ONE UEM.


Before we walk through what we can do, lets get started by exporting the current ADFS WebTheme.


  1. Log into the ADFS Server
  2. Run PowerShell as an Administrator
  3. Create a working folder by running the following command

    mkdir c:\myscripts

  4. Export the default ADFS web theme

    Export-AdfsWebTheme –Name "Default" –DirectoryPath c:\myscripts

  5. In PowerShell, create a new AD FS web theme

    New-AdfsWebTheme –Name "VIDM" –SourceName "Default"

  6. Re-import the onload.js into the new Web Theme

    Set-AdfsWebTheme -TargetName VIDM -AdditionalFileResource @{Uri='/adfs/portal/script/onload.js';path="c:\myscripts\script\onload.js"}

  7. Activate the new web theme

    Set-AdfsWebConfig -ActiveThemeName "VIDM"

  8. To save your changes, you will need to restart the AD FS instance

    Restart-Service adfssrv

  9. Open C:\myscripts\script\onload.js in a text editor such as Notepad++
  10. In the next couple section we will go through the possible options that you can make in the onload.js.  Once you make a change, you will need to re-import the onload.js. You do not need to activate or restart ADFS.
    We are going to use the following placeholders in the following sections:
    {AccessTenant} = FQDN of the VMware Workspace ONE Access service ie.
    {AD FS Claims Provider} = 'AD Authority'  Note: For older ADFS environments, you might need to use: 'http://{ADFSdomain}/adfs/services/trust'



Redirecting Mobile Traffic



// redirect mobile traffic to Workspace ONE

if (navigator.userAgent.match(/iPad|iPhone|Android|Windows Phone/i) != null)





HRD.selection(‘AD AUTHORITY’);



Support for IpadOS Devices




if (navigator.userAgent.match(/Macintosh/i) != null)


if(navigator.maxTouchPoints > 2)






HRD.selection(‘AD AUTHORITY’);




Hiding the HRD Selection

// hide HRD selector from user

var hrdui = document.getElementById("bySelection"); = "none";


Applying Conditions to Only Specific Relying PartiesVM

You will need to do some testing to make sure you get the correct values. If you *TEMPORARILLY* add the following code it will help get the correct values:









There are two options to choose from:

Option 1:

if ( window.location.href.indexOf(“urn%3afederation%3aMicrosoftOnline”|“”) != -1 )




Option 2:

if (document.referrer.indexOf("") != -1){





Using ADFS Access Control Policies

If you are you using ADFS Access Control Policies, you might see some errors in the event viewer similar to:


"The caller is not authorized to request a token for the relying party "

"Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity  for relying party trust "


In order to comply with your Access Control Policies, we will need to add a policy to allow requests coming from Workspace ONE.


Here are two approaches that you can use:


Check for 'Federated Authority' in the Claims Request

This approach will not necessarily ensure the claim came from Workspace ONE. It will check if it came from a federated claim provider.

  1. Edit your Access Policy in ADFS
  2. Create a new rule that will permit users for a specific claim in the request.
  3. Select "Account Store" as the the Claim type and "FEDERATED AUTHORITY" as the Claim Value
    Screen Shot 10-09-20 at 09.37 AM 001.PNG
  4. Your Rule would look similar to this:
    Screen Shot 10-09-20 at 09.37 AM.PNG

Check for Specific Claim sent by Workspace ONE Access

In this approach, ADFS will validate a specific claim sent by Workspace ONE Access. There are a few more steps required in this approach.

  1. In Workspace ONE Access, open the Application Source for ADFS (Identity & Access Management -> Catalog -> Web Apps -> Settings)
  2. Click on Configuration and Expand Advanced Configuration
  3. Scroll down to Custom Attribute Mapping
  4. Add the attribute ""
  5. Select the format "Unspecified"
  6. Set the value to something like "WS1"
    Screen Shot 10-09-20 at 09.39 AM.PNG
  7. Click Next, Next, Save
  8. In ADFS, edit the Claim Rules for the Workspace ONE Claims Provider Trust
  9. Add A New Claim Rule
  10. Select "Pass Through or Filter an Incoming Claim"
  11. Provide a Name and Select "Role" as the incoming claim.
    Screen Shot 10-09-20 at 09.43 AM.PNG
  12. Click Finish. You may receive a warning, You can click OK or filter the claim value even further.
  13. Edit your Access Policy in ADFS
  14. Create a new rule that will permit users for a specific claim in the request.
  15. Select "Role" as the the Claim and "WS1" as the Claim Value
    Screen Shot 10-09-20 at 09.39 AM 001.PNG
  16. Your Rule would look similar to:
    Screen Shot 10-09-20 at 09.40 AM.PNG



NSX-T の分散ファイアウォール(DFW)を、VLAN セグメントで使用してみます。


NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)


今回は、vNIC のポートグループを「VLAN セグメント」と「分散ポートグループ」に

それぞれ切りかえて、DFW ルール適用の様子を確認してみます。


今回の DFW ルール。

NSX Manager の「分散ファイアウォール」の画面を確認すると、

ID 3048 の DFW ルールが作成されて、有効になっています。


このルールは、適用先が「分散ファイアウォール (DFW)」となっており、

基本的には NSX 環境内のすべての VM、つまりホスト トランスポート ノード上で

NSX によるセグメントに接続されているすべて VM に適用されます。



ちなみに、今回は DFW ルールの適用される様子を見るだけなので、

通信は遮断しない(アクション: 許可)ルールにしてあります。



「VLAN セグメント」接続の vNIC と DFW ルール。

VM「vm01」の vNIC が、NSX-T による VLAN セグメント「seg-vlan-0006」に接続されています。

この VLAN セグメントは前回の投稿で作成したもので、VLAN ID 6 が設定されています。



それでは、vm01 が起動されている ESXi ホストに SSH 接続して、

vNIC への DFW ルール適用の様子を確認します。

まず に、DFW のルールが作成されている vNIC を確認しておきます。


ESXi に SSH ログインした状態です。

[root@lab-nsx-esxi-21:~] vmware -vl

VMware ESXi 7.0.0 build-16324942

VMware ESXi 7.0 GA


vm01 が起動しています。

この VM の World ID(371855)を記録しておきます。

[root@lab-nsx-esxi-21:~] esxcli network vm list

World ID  Name  Num Ports  Networks

--------  ----  ---------  --------

  371855  vm01          1


summarize-dvfilter で、vm01 の vNIC に適用されている dvfilter を探します。

赤字の部分が、vm01 の vNIC にあたります。

[root@lab-nsx-esxi-21:~] summarize-dvfilter


agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath

agent: vmware-si, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vsip-15945874

agent: vmware-sfw, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vsip-15945874

agent: nsx_bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vdrb-15945874

agent: ESXi-Firewall, refCount: 3, rev: 0x1010000, apiRev: 0x1010000, module: esxfw

agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter



serviceVM: 1, agent vmware-sfw, refCount: 2, rev: 0x4, apiRev: 0x4, capabilities: csum,tso

serviceVM: 2, agent vmware-sfw, refCount: 1, rev: 0x4, apiRev: 0x4, capabilities: csum,tso



world 0 <no world>

port 67108877 vmk0

  vNic slot 0

   name: nic-0-eth4294967295-ESXi-Firewall.0

   agentName: ESXi-Firewall

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failOpen

   serviceVMID: none

   filter source: Invalid

   moduleName: esxfw

port 67108878 vmk1

  vNic slot 0

   name: nic-0-eth4294967295-ESXi-Firewall.0

   agentName: ESXi-Firewall

   state: IOChain Attached

   vmState: Detached

   failurePolicy: failOpen

   serviceVMID: none

   filter source: Invalid

   moduleName: esxfw

world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'

port 67108883 vm01.eth0

  vNic slot 2

   name: nic-371855-eth0-vmware-sfw.2

   agentName: vmware-sfw

   state: IOChain Attached

   vmState: Attached

   failurePolicy: failClosed

   serviceVMID: 1

   filter source: Dynamic Filter Creation

   moduleName: nsxt-vsip-15945874


さきほど確認した、VM の World ID をもとにすると、

vm01 のフィルタの名前を見つけやすいかなと思います。

vm01 の 1つめの vNIC(ゲスト OS の種類に関係なく eth0)のフィルタ名


[root@lab-nsx-esxi-21:~] summarize-dvfilter | grep 371855

world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'

   name: nic-371855-eth0-vmware-sfw.2


そしてフィルタ名を指定して「vsipioctl getrules」コマンドを実行すると、

DFW のルールが実際に設定されている様子がわかります。


さきほど NSX Manager でも確認できた、ID 3048 のルールが表示されており、

vm01 の vNIC に DFW ルールが適用されていることがわかります。

[root@lab-nsx-esxi-21:~] vsipioctl getrules -f nic-371855-eth0-vmware-sfw.2

ruleset mainrs {

  # generation number: 0

  # realization time : 2020-10-07T17:00:19

  # FILTER rules

  rule 3048 at 1 inout protocol any from any to any accept;

  rule 2 at 2 inout protocol any from any to any accept;



ruleset mainrs_L2 {

  # generation number: 0

  # realization time : 2020-10-07T17:00:19

  # FILTER rules

  rule 1 at 1 inout ethertype any stateless from any to any accept;



ちなみに、DFW が適用されていることは nsxcli コマンドでも確認できます。

この ESXi で起動されている VM(の vNIC)が 1つだけなので、Firewall VIF が 1件表示されています。

[root@lab-nsx-esxi-21:~] nsxcli -c "get firewall vifs"

                            Firewall VIFs



VIF count: 1

1   1db50096-f1b8-44a2-8639-8ed6ac641446



「vDS の分散ポートグループ」接続の vNIC と DFW ルール。

続いて、NSX-T の VLAN セグメントと同じ VLAN ID の分散ポートグループを適用して、

DFW ルールの変化を確認してみます。(結果として DFW ルールは消えます)



今回は NSX で利用している vDS に、VLAN セグメントと同様に、

VLAN ID 6 の分散ポートグループ「dvpg-vlan-0006」を作成しました。



vm01 の vNIC のポートグループを、分散ポートグループである「dvpg-vlan-0006」に変更します。






このポートグループ変更より、DFW ルールが即時変更されます。

ESXi で summarize-dvfilter を実行してみると、

vm01 の「nic-371855-eth0-vmware-sfw.2」フィルタは存在したままです。

[root@lab-nsx-esxi-21:~] summarize-dvfilter | grep 371855

world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'

   name: nic-371855-eth0-vmware-sfw.2


しかし、vsipioctl getrules コマンドで確認すると、DFW ルールが消えて「No rules」になりました。

[root@lab-nsx-esxi-21:~] vsipioctl getrules -f nic-371855-eth0-vmware-sfw.2

No rules.


nsxcli コマンドでも 1件表示されていた VIF がなくなり、

Firewall VIF のカウントがゼロになっています。

[root@lab-nsx-esxi-21:~] nsxcli -c "get firewall vifs"

                            Firewall VIFs



VIF count: 0



このように、VM が起動する ESXi が NSX-T のホスト トランスポート ノードとして設定されていたとしても、

vSS の標準ポートグループや vDS の分散ポートグループに接続された vNIC には、DFW ルールが適用されません。

DFW はオーバーレイ ネットワークでなくても使用できますが、

VLAN ネットワークで使用する場合、vNIC には「VLAN セグメント」を割り当てる必要があります。


以上、DFW を VLAN セグメントで使用してみる話でした。

NSX-T の分散ファイアウォール(DFW)は、NSX-T のセグメント(オーバーレイ or VLAN)で機能します。

今回は、VLAN セグメントでも DFW が利用できることを確認してみます。




NSX-T 3.0 のシンプルな DFW ラボを構築する。

特にオーバーレイ ネットワークやルーティング機能などは準備せず、

ただ「VLAN セグメント」が利用できるようになっています。


NSX-T では、VLAN セグメント「seg-vlan-0006」を作成してあります。

まず、NSX Manager の画面から確認しておきます。

セグメントはオーバーレイではなく、VLAN のトランスポート ゾーンに作成し、VLAN ID 6 を設定しています。

つまりこれは NSX-T で作成されたセグメントですが、Geneve のオーバーレイではなく VLAN によるものです。



vCenter(の vSphere Client)で vDS「vds-21」を確認すると、

「seg-vlan-0006」が表示されており、NSX の「N」マークがついています。


ちなみに、dvpg-vlan-0006 という NSX-T に関係しない、VLAN ID 6 の分散ポートグループも別途作成してあります。




VM「vm01」の vNIC に、ポートグループとして NSX-T による VLAN セグメントを割り当てました。

なお、この VM の IP アドレスは です。あとで、このアドレス宛に疎通確認します。



ESXi ホスト「」で仮想スイッチの構成を確認すると、1つの vDS だけが構成されてます。

この vDS は NSX と統合されており、「NSX 仮想スイッチ」となっていることがわかります。




DFW ポリシー / ルールの作成。

NSX Manager で、DFW のポリシーとルールを作成します。


そして、ルールの適用有無が分かりやすいように、すべての通信を許可 / 遮断するためのルールを、1つだけ作成します。



デフォルト作成されるポリシー「Default Layer3 Section 」には、すべての通信を「許可」するルールが設定されているので、












NSX-T の オーバーレイ / VLAN セグメントに接続された VM に適用されます。




そして「発行」をクリックしてポリシー / ルールを保存しておきます。



ルールが保存され、このルールの ID は 3048 が採番されました。

このあと、このルールの設定を変更して、DFW の動作確認をします。



DFW ルールの動作確認。

それでは NSX 外部のマシンから、VLAN セグメントに接続されている vm01 宛に ping で疎通確認をしつつ、

DFW で通信を遮断してみます。


作成した DFW ルール「test-rule-01」のアクションを「許可」→「却下」に変更します。





この時点で vm01 宛に通信できる外部のマシンから ping を実行しつつ、「発行」をクリックします。



DFW のルールが作用して、外部の端末から vm01(への ping が通らなくなりました。



DFW ルール「test-rule-01」のアクションを「却下」→「許可」に戻して、「発行」をクリックすると・・・



外部の端末から、vm01 への ping が通るようになりました。



このように、オーバーレイ セグメントではなく、VLAN セグメントでも、NSX-T の DFW は動作します。

まずは、DFW が動作することの確認でした。


次は、VM の vNIC に「NSX の VLAN セグメント」ではなく「vDS の分散ポートグループ」を割り当てた環境で、

分散ファイアウォール ルールが動作しない様子を確認してみます。


NSX-T には、分散ファイアウォール(DFW)機能があります。

この DFW は、NSX-T の有名な機能であるオーバーレイ ネットワーク(Geneve による)の環境でなくても利用可能です。

そこで今回は、オーバーレイ ネットワークなしのシンプルな DFW ラボ環境を構築してみます。




  • vCenter Server 7.0d / ESXi 7.0
  • NSX-T 3.0
  • NSX の仮想スイッチは、N-VDS ではなく vDS 7.0 を利用(NSX-T 3.0 ~新機能)
  • NSX Edge は無し。オーバーレイ ネットワークも無し。


vCenter / ESXi の仮想スイッチは、分散仮想スイッチ(vDS)のみを構成しています。

vDS のバージョンは 7.0 で作成してあり、アップリンクには ESXi の物理 NIC(vmnic0 と vmnic1)が割り当てられています。



NSX Manager の仮想アプライアンス(VM)は、すでにデプロイしてあります。

OVA ファイルは「nsx-unified-appliance-」です。



なお、NSX-T の設定作業をするためにはライセンスの適用は必須です。

デプロイ直後の NSX Manger の VM を起動して、



NSX Manager での vCenter 登録。

NSX-T に「コンピュート マネージャ」として vCenter を登録します。

これは、NSX-T の仮想スイッチで vDS を利用するために必要です。


「システム」→「ファブリック」→「コンピュート マネージャ」を開き、

「追加」をクリックして「コンピュート マネージャの作成」画面を表示します。


  • vCenter の「名前」(これは任意の文字列)
  • vCenter の「FQDN または IP アドレス」
  • vCenter の、ユーザー名と、パスワード



画面に従って証明書のサムプリントを受け入れると、vCenter がコンピュート マネージャとして登録されます。




「ホスト トランスポート ノード」で vCenter を選択すると、クラスタと ESXi が表示されるようになります。



ただしこの ESXi は、まだ NSX-T むけに準備されていない状態です。


ESXi のホスト トランスポート ノードとしての準備。

ここから ESXi を、NSX-T の「ホスト トランスポート ノード」として準備します。



「トランスポート ノード プロファイル」で、「追加」をクリックします。


「トランスポート ノード プロファイルの追加」画面が表示されるので、


  • プロファイルにつける「名前」を入力。今回は tnp-esxi-vds-01 としています。
  • ノード スイッチの「タイプ」で、「VDS」を選択。
  • ノード スイッチ「名前」では、vCenter と vDS 名を選択。(例での vDS は vds-21)
  • トランスポート ゾーンとして「nsx-vlan-transportzone」を選択。
    (これは、デフォルト作成される VLAN トランスポート ゾーン)
  • アップリンク プロファイルとして「nsx-default-uplink-hostswitch-profile」を選択。




  • uplink-1 → vDS の1つめのアップリンク名(例では dvUplink1)
  • uplink-2 → vDS の2つめのアップリンク名(例では dvUplink2)



これで、VLAN セグメントを利用できるようになる、トランスポート ノード プロファイルが作成されました。



「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」を開き、

クラスタ(ESXi ではなくその上の)を選択して、「NSX の設定」をクリックします。

「NSX のインストール」画面が表示されるので、先ほど作成したトランスポート ノード プロファイルを選択して、




これで少し待つと、クラスタ配下の ESXi が NSX のホスト トランスポート ノードとして設定された状態になります。



NSX-T によるネットワークの準備。

このラボでは DFW だけを利用するため、NSX Edge はデプロイしていません。

そして、ルーティングのための Tier-0 / Tier-1 ゲートウェイや、Geneve のオーバーレイ セグメントも作成しません。

VLAN 接続するための「VLAN セグメント」のみ作成します。


Tier-0 ゲートウェイは、作成しません。



そして Tier-1 ゲートウェイも作成しません。



NSX-T では、vCenter でポートグループとして扱える「セグメント」を作成できます。

そして NSX-T の DFW は、この「セグメント」で作用します。

NSX-T のセグメントには、「オーバーレイ」と「VLAN」の 2種類がありますが、DFW はどちらでも利用できます。

そこで、ここでは「VLAN セグメント」のみを作成します。




  • セグメント名を入力。ここでは seg-vlan-0006。
  • トランスポート ゾーンを選択。デフォルトで作成されている「nsx-vlan-transportzone | VLAN」を選択する。



VLAN ID を入力し、「保存」をクリックします。

今回は、セグメント名からもわかるように VLAN ID 6 のセグメントを作成します。

ちなみに、この VLAN ID は(NSX 外部の)物理スイッチのトランク ポートでも設定しておく必要があります。






これで、VLAN セグメントが作成されました。

ここで作成した、VLAN セグメント「seg-vlan-0006」は、

vCenter の vSphere Client などでは、ポートグループとして VM の vNIC に割り当てられます。



これで、DFW を利用可能な、シンプルな構成のラボが構築できました。


NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)

For updates on this blog and other blogs: Follow @SteveIDM


Workspace ONE Access will soon offer a native integration with DUO. This integration will not require the use of radius and/or the Workspace ONE Access connector.


This blog will outline the steps to setup and configure DUO and Workspace ONE Access.


Please remember, this integration is not yet generally available.


1. Create a Web SDK Application in DUO

  1. In your DUO admin console, go to Dashboard -> Applications -> Protect an Application
    Screen Shot 10-06-20 at 03.08 PM.PNG
  2. In the search box, enter "Web SDK" and Click Protect
    Screen Shot 10-06-20 at 03.18 PM.PNG
  3. Make note of your Integration Key, Secret Key and API Hostname
    Screen Shot 10-06-20 at 03.20 PM.PNG
  4. Scroll down to settings and update the name of this application.
    Screen Shot 10-06-20 at 03.22 PM.PNG
  5. Click Save


2. Enable the Workspace ONE Authentication Method

  1. Log into the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Authentication Methods
    Screen Shot 10-06-20 at 03.26 PM.PNG
  3. Click Edit for "DUO Security"
    Screen Shot 10-06-20 at 03.29 PM.PNG
  4. Enable the Adapter
  5. Paste your Integration Key.
  6. Paste your Secret Key
  7. Paste your API Host Name
  8. Select the correct username format. The only options currently available are username and email address.
  9. Select Save
  10. Your DUO Adapter should be enabled and ready to use.


3. Update your "Built-In" IDP in Workspace ONE Access

  1. In the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Identity Providers
  3. Click on your "Built-In" Identity Provider that is already associated with your user directory.
  4. Scroll down to Authentication Methods and enable DUO Security
    Screen Shot 10-06-20 at 03.42 PM.PNG
  5. Click Save


4. Update your Policies

  1. In the Workspace ONE Administration Console
  2. Go to Identity & Access Management -> Policies
  3. Edit your Default or Application Policy (depending on your requirements)
  4. Add DUO Security as a second factor of authentication.
    Screen Shot 10-06-20 at 03.47 PM.PNG
  5. Click Save
  6. Click Next and Save


Testing the DUO Flow:


  1. Log into your Workspace ONE Access Console (via incognito)
  2. Enter your Username/Password (as an End User)
    Screen Shot 10-06-20 at 03.50 PM.PNG
  3. Click on Start Setup
    Screen Shot 10-06-20 at 03.50 PM 001.PNG
  4. Select your device type and click Continue
    Screen Shot 10-06-20 at 03.51 PM 001.PNG
  5. Select the correct platform for your device and click Continue
    Screen Shot 10-06-20 at 03.52 PM.PNG
  6. Workspace ONE Access will Prompt you to install Duo Mobile. Once you have DUO Mobile Installed, Click "I have DUO Mobile"
    Screen Shot 10-06-20 at 03.53 PM.PNG
  7. In DUO Mobile, click the + sign and scan the barcode
    Screen Shot 10-06-20 at 03.55 PM.PNG
  8. Once activated, you will see a green check mark.
    Screen Shot 10-06-20 at 03.56 PM.PNG
  9. Click Continue
  10. When prompted, select "Send Me a Push"
    Screen Shot 10-06-20 at 03.57 PM.PNG
  11. On your device, click Approve.
    Screen Shot 10-06-20 at 03.58 PM.PNG

For updates on this blog and other blogs: Follow @SteveIDM


I've had quite a few requests lately for assistance setting up SCIM capabilities with OneLogin and Workspace ONE.


In full disclosure, I've set this up in my lab but I've not done full end to end testing of all CRUD capabilities.


The one obvious difference in the setup and configuration with OneLogin over some of our other partners is the ability to support the Authorization Code Grant Flow.  Big Kudos to the OneLogin team.


Lets look at the high level steps:

  1. Create a directory instance in Workspace ONE Access
  2. Create a OneLogin Remote App Access Client.
  3. Configure VMware Workspace ONE application in OneLogin.


Create Directory Instance in Workspace ONE Access

In order to create a directory instance in Workspace ONE Access, we'll need to use the API because the type of directory required for this integration can not currently be done using the Admin Console. In the following steps we'll use Postman to run the necessary API calls.

  1. We will need an Oauth Token in order to use the API.  Please see my other blog on your options on getting an OAuth Token
  2. Open a new tab in Postman, Select POST and the method.
  3. For the URL, enter: https://[TENANTURL]SAAS/jersey/manager/api/connectormanagement/directoryconfigs
    Replace the Tenant URL with your URL
  4. In the Authorization Tab, Select either BEARER Token or OAuth 2.0 depending on the option you chose in Step 1 to get a token. Select or Paste your Token.
  5. In the Headers Tab, Set the Content-Type to "application/"
  6. Click on the Body Tab
  7. Use the following as a sample and Click Send:
    "name":"OneLogin Directory" 
  8. In the Workspace ONE Admin Console, verify that the directory is created and is associated with the correct domain.
    Screen Shot 09-25-20 at 03.03 PM.PNG

Create a OneLogin Remote App Access Client

We will now create a OneLogin Application in Workspace ONE Access which will be used by OneLogin to create/update/delete users in Workspace ONE.

  1. In the Workspace ONE Admin Console, go to Catalog -> Webapps
  2. Click New (Top Left)
  3. Enter a Name ie. OneLogin SCIM
    Screen Shot 09-25-20 at 03.09 PM.PNG
  4. Click Next
  5. On the configuration page, you will need to enter:
    Authentication TypeOpen ID Connect
    Target URLEnter your OneLogin Tenant ie.
    Redirect URL
    Client IDEnter a value for the Client ID: ie. OneLoginSCIM
    Client SecretEnter a value for the Client Secret ie. Test12345
    Show in User PortalNO
    Screen Shot 09-25-20 at 03.11 PM.PNG
  6. Click Next
  7. Click Next for Access Policy
  8. Click Save
  9. Assign the application to your System Domain user
    Screen Shot 09-30-20 at 09.51 AM.PNG


This wizard will create a new remote app access client that will be used by OneLogin. You can see the client which was created by going to Catalog -> Settings -> Remote App Access.


Warning: Do NOT edit the scopes. You will not be able to re-add the Admin scope if you do.

Screen Shot 09-25-20 at 03.20 PM.PNG


Configure VMware Workspace ONE application in OneLogin.


  1. In the OneLogin admin console, search for "VMware Workspace ONE" under Applications
    Screen Shot 09-25-20 at 03.24 PM.PNG
  2. Select and Click Save
  3. Click on Configuration on the left menu
  4. Under SCIM Base URL, enter: https://[tenant]
  5. Under VMware Site, enter your tenant URL. This will be used as the Oauth Authorization Server URL.
  6. Under Client ID, enter the client ID you used in the previous step
  7. Under Client Secret, enter the secret you used in the previous step.
    Screen Shot 09-25-20 at 03.31 PM.PNG
  8. Click Save

    Please don't forget to hit SAVE!

  9. Go back to the Configuration Tab

    Before you Continue, you need to make sure your Policy in Workspace ONE Access will allow you to authenticate using System Domain credentials without using the backdoor.  You will need a policy similar to below. The Password (Local Directory) needs to be a fallback.
    Screen Shot 09-25-20 at 03.42 PM 001.PNG

  10. Under API Connection, Click Authenticate
    Screen Shot 09-25-20 at 03.32 PM.PNG
  11. In the pop up, click VMware Workspace ONE
    Screen Shot 09-25-20 at 03.33 PM.PNG
  12. When prompted to Authenticate, Select System Domain
    Screen Shot 09-25-20 at 03.39 PM.PNG
  13. Enter your Credentials
  14. You should be returned back to the One Login Portal with a Successful Authorization
    Screen Shot 09-25-20 at 03.40 PM.PNG
  15. Click on the Parameters Tab
  16. We will need to map the attributes appropriately that will be sent to Workspace ONE.

    In order to map the attributes correctly, we will need to understand how users are created in in OneLogin. Take a look at your users to ensure all the required attributes are set for all users that will be provisioned to Workspace ONE Access.  Attributes such as Username, External ID and User Principal Name are typically set if you have an external directory server. If you are creating users directly in OneLogin without a directory server you will need to select different attribute mappings.

  17. Map the attributes appropriately:
    VMware Workspace ONE FieldValue
    Distinguished NameDistinguished Name
    Email AddressEmail
    External IDIf ALL users are created in OneLogin from a directory server, select ExternalID
    If some users are created locally in OneLogin, select Internal ID.
    First NameFirst Name
    Last NameLast Name
    Name IDEmail
    SCIM Username

    If ALL users are created in OneLogin from a directory server, select Username

    If some users are created locally in OneLogin (without a username) , select Email

    User DomainEnter value used as the domain when creating the directory in Workspace ONE Access
    Screen Shot 09-25-20 at 03.59 PM.PNG
    User PrincipleName

    If ALL users are created in OneLogin from a directory server, select User Principal Name



    If some users are created locally in OneLogin, select Email

  18. Click Save
  19. Click Provisioning on the left menu, and enable the Provisioning Checkbox.
  20. Click Save
  21. Assign a user the application and verify it successfully provisions
    Screen Shot 09-25-20 at 04.12 PM.PNG

vSphere with Kubernetes のスーパーバイザー クラスタ上に作成した

「Tanzu Kubernetse Cluster」に、kubectl を使用していくつかの方法で接続してみます。



Tanzu Kubernetesクラスタ環境への接続



今回の接続元の環境は Linux です。

スーパーバイザー クラスタの管理プレーンから、kubectl と vSphere プラグインはダウンロードしてあります。

$ cat /etc/system-release

Oracle Linux Server release 7.8

$ kubectl version --short --client

Client Version: v1.17.4-2+a00aae1e6a4a69

$ kubectl vsphere version

kubectl-vsphere: version 0.0.2, build 16232217, change 8039971


Tanzu Kubernetse Cluster のラボは、下記のように構築しています。

vSphere with Kubernetes ラボ環境構築。(まとめ)


kubectl は、スーパーバイザー クラスタの制御プレーンからダウンロードしたものを利用しています。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編


vCenter Server 7.0b で、3ノードの ESXi で スーパーバイザー クラスタを構成しています。

スーパーバイザークラスタ「wcp-cluster-41」の、制御プレーンの IP アドレスは「」です。



Tanzu Kubernetes Cluster(TKC)は、スーパーバイザークラスタの名前空間「lab-ns-03」に作成ずみです。

TKC の名前は「tkg-cluster-41」で、制御プレーンの IP アドレスは「」です。



あらかじめ、vCenter Single Sign-On には、ID ソースとして LDAP サーバを登録ずみです。



ID ソースのドメイン「」からユーザ情報を取得できています。



方法1: vCenter Single Sign-On 認証で接続する。

ここでは、「k8s-infra-user @」という vCenter Single Sigh-On のユーザーで接続してみます。


まず、対象のユーザーには、スーパーバイザー クラスタの名前空間で「権限の追加」が必要です。

そして、kubectl で TKC に接続する際は、スーパーバイザー制御プレーン宛となります。

ちなみに、vCenter の管理者ユーザ(administrator@vsphere.local)であれば、

デフォルトでスーパーバイザー クラスタや TKC にアクセス可能です。



1-1: スーパーバイザー名前空間での権限の追加。

スーパーバイザー クラスタの名前空間「lab-ns-03」の、




ID ソース、ユーザー(またはグループ)、ロールを選択して、「OK」をクリックします。


ロールでは、「編集可能」(edit) または、「表示可能」(view)が選択できます。






1-2: kubectl での接続。

kubectl vsphere login でログインすると、kubeconfig のファイルが生成されます。

デフォルトでは、$HOME/.kube/config というファイル名で作成されますが、

環境変数 KUBECONFIG を設定しておくと、そのパスに生成されます。

$ export KUBECONFIG=$(pwd)/kubeconfig_tkc


kubectl vsphere login では、次のようなオプションを指定します。

  • --server: Tanzu Kubernetes Cluster の制御プレーンではなく、
    スーパーバイザー クラスタの、制御プレーンが持つ IP アドレス(この環境ではを指定します。
  • --tanzu-kubernetes-cluster-namespace: TKC を作成したスーパーバイザー名前空間
  • --tanzu-kubernetes-cluster-name: TKC の名前

$ kubectl vsphere login --insecure-skip-tls-verify --server= --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41



Password: ★パスワードを入力。

Logged in successfully.


You have access to the following contexts:




If the context you wish to use is not in this list, you may need to try

logging in again later, or contact your cluster administrator.


To change context, use `kubectl config use-context <workload name>`



TKC「tkg-cluster-41」と、TKC のスーパーバイザー名前空間「lab-ns-03」と同名のコンテキストが作成されます。

ここでも、TKC  の制御プレーン アドレス「」がわかります。

$ kubectl config get-contexts tkg-cluster-41

CURRENT   NAME             CLUSTER         AUTHINFO                                     NAMESPACE

*         tkg-cluster-41


TKC のノードが表示できました。

$ kubectl --context tkg-cluster-41 get nodes

NAME                                            STATUS   ROLES    AGE    VERSION

tkg-cluster-41-control-plane-vcdpg              Ready    master   153m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   131m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   127m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   131m   v1.17.8+vmware.1



$ kubectl --context tkg-cluster-41 get nodes

Error from server (Forbidden): nodes is forbidden: User "" cannot list resource "nodes" in API group "" at the cluster scope


なお、TKC で Deployment リソースなどで Pod を作成するには、PodSecurityPolicy の設定が必要になったりします。


vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編


方法2: Kubernetes の管理ユーザ(kubernetes-admin)として接続する。

この方法では、TKC を作成してあるスーパーバイザー名前空間「lab-ns-03」に自動作成されている Secret リソースから、kubeconfig の情報を取得します。

これは、あらかじめ kubectl vsphere login でスーパーバイザー クラスタか TKC に接続したうえで取得することになります。


kubernetes-admin の kubeconfig での接続は、直接 TKC の管理プレーン宛を指定します。



2-1: kubernetes-admin ユーザーの kubeconfig の取得。

Secret リソースは、「<Tanzu Kubernetes Cluster の名前>-kubeconfig」となっており、


$ kubectl --context lab-ns-03 get secrets tkg-cluster-41-kubeconfig

NAME                        TYPE     DATA   AGE

tkg-cluster-41-kubeconfig   Opaque   1      167m


JSON パスでの「{.data.value}」に、base64 エンコーディングされた kubeconfig が格納されています。

この内容を、「base64 -d」コマンドでデコードして、ファイルに保存します。

$ kubectl --context lab-ns-03 get secret tkg-cluster-41-kubeconfig -o jsonpath='{.data.value}' | base64 -d > ./kubeconfig_tkg-cluster-41


2-2: 生成した kubeconfig での kubectl 接続。

保存した kubeconfig で、管理ユーザーのコンテキストで TKC に接続できます。

これは、vCenter Single Sign-On の認証とは関係なく接続できるものです。

$ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 config current-context


$ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 get nodes

NAME                                            STATUS   ROLES    AGE    VERSION

tkg-cluster-41-control-plane-vcdpg              Ready    master   155m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   133m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   129m   v1.17.8+vmware.1

tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   133m   v1.17.8+vmware.1


方法3: Kubernetes の ServiceAccount を作成して接続する。

方法1か、方法2の、いずれかで TKC に接続したうえで、TKC の名前空間に ServiceAccount を作成して接続します。

ServiceAccount での TKC への接続も、スーパーバイザー制御プレーンではなく、TKC 制御プレーン宛となります。



3-1: ServiceAccount の作成。

ここからは、ちょうど直前の 方法2 で作成した kubeconfig を利用します。

$ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41

$ kubectl config current-context



この時点では TKC の「default」名前空間を使用していますが、

あらたに「tkg-ns-01」という名前空間を作成して、そこに ServiceAccount で接続できるようにします。

$ kubectl create namespace tkg-ns-01

namespace/tkg-ns-01 created


この時点 tkg-ns-01 名前空間に存在するのは、ServiceAccount(sa) は default のみです。

$ kubectl -n tkg-ns-01 get sa


default   1         43s



$ kubectl -n tkg-ns-01 create sa sa-01

serviceaccount/sa-01 created

$ kubectl -n tkg-ns-01 get sa


default   1         47s

sa-01     1         12s


この ServiceAccount のトークンが格納されている、Secret リソースの名前を確認します。

$ SA_SECRET_NAME=$(kubectl -n tkg-ns-01 get sa sa-01 -o jsonpath='{.secrets[0].name}')




Secret リソースから、トークンを取得します。

$ SA_TOKEN=$(kubectl -n tkg-ns-01 get secrets $SA_SECRET_NAME -o jsonpath='{.data.token}' | base64 -d)



$ kubectl config set-credentials sa-01 --token=$SA_TOKEN

User "sa-01" set.

$ kubectl config set-context ctx-sa-01 --user=sa-01 --cluster=tkg-cluster-41 --namespace=tkg-ns-01

Context "ctx-sa-01" created.


コンテキストを kubeconfig ファイルとして保存しておきます。

$ kubectl config view --minify --context=ctx-sa-01 --raw > ./kubeconfig_ctx-sa-01

$ kubectl config delete-context ctx-sa-01


ServiceAccount で接続する kubeconifg が生成されました。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 config get-contexts


*         ctx-sa-01   tkg-cluster-41   sa-01      tkg-ns-01


3-2: ServiceAccount の権限設定。

作成した ServiceAccount「sa-01」が Kubernetes のリソースを操作できるように、

ClusterRole「edit」を割り当てる RoleBinding を作成しておきます。




kind: RoleBinding



  name: rb-edit-sa-01


  kind: ClusterRole

  name: edit



- kind: ServiceAccount

  name: sa-01


RoleBinding を、TKC の tkg-ns-01 名前空間に作成します。

$ kubectl -n tkg-ns-01 apply -f role-binding-edit.yml created


TKC で Pod を起動できるように、PodSecurityPolicy を割り当てる RoleBinding も作成しておきます。

こちらは、すべての ServiceAccount を指定しています。




kind: RoleBinding



  name: rb-vmware-system-privileged


  kind: ClusterRole

  name: psp:vmware-system-privileged



- kind: Group

  name: system:serviceaccounts



TKC の名前空間に RoleBinding を作成します。

$ kubectl -n tkg-ns-01 apply -f role-binding-psp.yml created


3-3: 生成した kubeconifg での kubectl 接続。

生成した kubeconfig で、Pod の起動ができました。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 run pod-01 --image=gowatana/centos7:httpd --restart=Never

pod/pod-01 created

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 get pods


pod-01   1/1     Running             0          44s


Pod は削除しておきます。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01.txt delete pod pod-01

pod "pod-01" deleted


方法4: TKC 側で vCenter Single Sign-On ユーザーの権限を割り当てる。

あらかじめ、方法1、または方法2の、いずれかの方法で TKC に接続しておきます。

そして方法1 とは異なり、TKC で作成した名前空間に vCenter Single Sigh-On ユーザーの権限を割り当てます。

そのあとの TKC への接続はスーパーバイザー制御プレーン宛となります。



方法4-1: TKC の名前空間への権限の追加。

ここでは、方法2 で生成した kubeconfig を利用して、TKC を操作します。

(方法1 の接続でも同様に操作できます)

$ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41

$ kubectl config current-context



TKC の名前空間「tkg-ns-02」を追加作成します。

あわせて、PSP の RoleBinding(YAML は方法3のものと同様)も作成しておきます。

$ kubectl create namespace tkg-ns-02

namespace/tkg-ns-02 created

$ kubectl -n tkg-ns-02 apply -f role-binding-psp.yml created


RoleBinding の YAML を用意します。


subjects では vCenter Single Sign-On ユーザー(を指定しています。

ちなみに、グループを指定する場合は、「kind: User」を「kind: Group」にします。




kind: RoleBinding



  name: rb-edit-k8s-dev-user


  kind: ClusterRole

  name: edit



- kind: User

  name: #sso:<username>@<domain>



作成した TKC の名前空間「tkg-ns-02」に、RoleBinding を作成します。

$ kubectl -n tkg-ns-02 apply -f role-binding-vcsso.yml created


方法4-2: kubectl での接続。

既存の kubeconfig を上書きしないように、環境変数 KUBECONFIG に、新しい kubeconfig ファイルのパスを指定します。


$ export KUBECONFIG=$(pwd)/kubeconfig_k8s-dev-user


kubectl vsphere login で、スーパーバイザー制御プレーンと TKC に接続します。

$ kubectl vsphere login --insecure-skip-tls-verify --server= --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41



Password: ★パスワードを入力。

Logged in successfully.


You have access to the following contexts:



If the context you wish to use is not in this list, you may need to try

logging in again later, or contact your cluster administrator.


To change context, use `kubectl config use-context <workload name>`




$ kubectl config get-contexts tkg-cluster-41

CURRENT   NAME             CLUSTER         AUTHINFO                                   NAMESPACE

*         tkg-cluster-41


コンテキストを TKC の「tkg-cluster-41」に切り替えて、


$ kubectl config use-context tkg-cluster-41

Switched to context "tkg-cluster-41".

$ kubectl config set-context --current --namespace=tkg-ns-02

Context "tkg-cluster-41" modified.

$ kubectl config get-contexts tkg-cluster-41

CURRENT   NAME             CLUSTER         AUTHINFO                                   NAMESPACE

*         tkg-cluster-41   tkg-ns-02


Pod が起動できました。

$ kubectl run pod-01 --image=gowatana/centos7:httpd --restart=Never

pod/pod-01 created

$ kubectl get pods -n tkg-ns-02


pod-01   1/1     Running   0          10s



vCenter Single Sigh-On ユーザーでリソース作成ができました。

vSphere Client で確認すると、方法1 で使用した「k8s-infra-user」ユーザーのみが追加されています。



vCenter 同梱ではない kubectl の接続。

ちなみに、ここまでの方法に関わらず、kubeconfig が生成できていれば

一般的な Kubernetes 操作ツールでも TKC に(スーパーバイザー クラスタにも)接続することができます。


Kubernetes のドキュメントでおなじみの URL から kubectl をダウンロードします。

$ curl -LO

$ chmod +x ./kubectl


vCenter 同梱の kubectl と、あらたにダウンロードした kubectl(./kubectl でカレント ディレクトリのものを実行)です。

$ kubectl version --short

Client Version: v1.17.4-2+a00aae1e6a4a69

Server Version: v1.17.8+vmware.1

$ ./kubectl version --short

Client Version: v1.17.8

Server Version: v1.17.8+vmware.1


どちらの kubectl でも、普通に TKC を操作できます。

$ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user run pod-01 --image=gowatana/centos7:httpd --restart=Never

pod/pod-01 created

$ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user get pods


pod-01   1/1     Running   0          15s


Tanzu Kubernetes Cluster は、kubectl + vSphere プラグインによる vCenter Single Sign-On の認証だけでなく、

一般的な kubernetes と同様なクラスターへの接続ができます。



以上、いろいろと Tanzu Kubernetes Cluster への接続を試してみる話でした。

1 2 Previous Next


Looking for a blog?

Can't find a specific blog? Try using the Blog page to browse and search blogs.