Gallery

Gallery.

Microsoft

Microsoft

Visit https://account.live.com/developers/applications/index Click on Create application Enter an Application name, then click on I accept button Go to API Settings tab Enter a Redirect URL Click Save Go to App Settings tab to get Client ID and Client Secret

Note: Microsoft does not consider localhost or 127.0.0.1 to be a valid URL. As a workaround for local development add 127.0.0.1 mylocalwebsite.net to /etc/hosts file and specify mylocalwebsite.net as your Redirect URL in the API Settings tab.

Visit Live Connect App Management.

Click on Create application Enter an Application name, then click on I accept button Go to API Settings tab Enter a Redirect URL Click Save Go to App Settings tab to get Client ID and Client Secret

Note: Microsoft does not consider localhost or 127.0.0.1 to be a valid URL. As a workaround for local development add 127.0.0.1 mylocalwebsite.net to /etc/hosts file and specify mylocalwebsite.net as your Redirect URL on API Settings tab.

Integration with Microsoft Security

We have developed mulituser+kerberos authentication on top and we want to integrate with Active Directory (on-premise + in-azure) to ease the user experience and also to reuse the authentication towards other Azure services (publishing to OneNote, calling a AzureML job…).

I have attached to this mail the 4 scenarii we discussed:

  1. SPNEGO with Notebook in-Azure and AD on-premise.
  2. OpenID Connect / OAuth2 with Notebook in-Azure and Azure Active Directory (extensible to on-site AD).
  3. Same as Scenario 2 but with the connection with Azure Active Directory ensure on-site AD implemented with a VPN
  4. SPNEGO with all (Notebook + AD) on-premise.

Same authentication for Microsoft Live and Office 365

Active Directory (AD)

About

Active Directory implements Kerberos for Authentication and LDAP for Authorization.

To access AD from Linux:

The process for the most part consists of allowing delegation for the security context of the service doing the authentication and configuring the service principal names.

AD supports LDAP and you can program against it.

Ports

Restricting RPC to a specific port

RPC traffic is used over a dynamic port range as described in the previous section, “Default dynamic port range.” To restrict RPC traffic to a specific port, see article 224196 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=133489). Communication to Domain Controllers

The following table lists the port requirements for establishing DC to DC communication in all versions of Windows Sever beginning with Windows Server 2003.

Additional ports are required for communication between a read-only domain controller (RODC) and a writeable DC.

Active Directory Explorer v1.44

Use “Bridged Adapter” as network configuration in your Virtualbox images.

If you really want to use NAT option

sudo usermod -a -G vboxusers $USER
groups $USER
id
VBoxManage modifyvm "Windows Server 2012" --natpf1 delete "LDAP"
VBoxManage modifyvm "Windows Server 2012" --natpf1 "LDAP,tcp,,3389,,389"

Create a Keytab

Step 1

Turn User Account Control off

Step 2

Create a user account within the Active Directory Users and Computers console by clicking Start → Administrative Tools → Active Directory Users and Computers → $Domain_Name (example.com in this scenario) → Users, then right-click in the right panel and select New → User.

Fill information for the user account, then click Next to move to the Create Password form.

Enter a password for the user account. For example, the username as “dla” with password as “aA@123456” will be used later. Since this account is acting as a service account, select User cannot change password and Password never expires, then click Next. You need to remember this password to use later.

Verify the user settings, and select Finish.

Configure the new user account to comply with the Kerberos protocol as follows:

Step 3. Configuring the Service Principal Name (SPN) for eXo Platform server

The setspn command is used to create a service principal for the user previously created. A service principal complies with the rule: serviceclass/host.

Because the web application is communicating via the HTTP protocol, HTTP is the service class.

The host is fully qualified domain name (FQDN) of the eXo Platform server.

The FQDN of the eXo Platform server in this case is server.example.com.

To add a Service Principal, use the commands that comply with the formats:

setspn -a HTTP/$hostname dlauser (that is, setspn -a HTTP/localhost dlauser)
setspn -a HTTP/$fully-qualified-host-name $username (that is, setspn -a HTTP/localhost.net dlauser)

Tip: Run the following command to see the SPN that you created.

setspn -l dlauser

Step 4. Creating the Kerberos Keytab file used by SPNEGO

In this step, the ktpass is used to generate the keytab file by mapping the service principal to the user account created previously.

This file will then be stored in the eXo Platform server (on Machine 2).

Create the keytab file for the eXo Platform server running in an Windows 2008 domain environment that complies with the format:

ktpass.exe /princ HTTP/$fully-qualified-domain-name@realm-name /pass "$password" /mapuser "$username" /out $hostname.keytab /ptype KRB5_NT_PRINCIPAL /kvno 0 /crypto RC4-HMAC-NT.

In this scenario, the command will be:

ktpass.exe /princ HTTP/server.example.com@EXAMPLE.COM /pass "aA@123456" /mapuser "EXAMPLE\exoadmin" /out server.keytab /ptype KRB5_NT_PRINCIPAL /kvno 0 /crypto RC4-HMAC-NT
ktpass.exe /princ HTTP/localhost@DATALAYER.IO /mapuser dlauser@DATALAYER.IO /pass xxx /ptype KRB5_NT_PRINCIPAL /out activedirectory.keytab
ktpass.exe /princ HTTP/localhost@DATALAYER.IO /mapuser test@DATALAYER.IO /pass xxx /ptype KRB5_NT_PRINCIPAL /out activedirectory.keytab

/crypto AES128-SHA1

In this step, the $hostname.keytab file (that is, server.keytab) will be generated.

Transfer the activedirectory.keytab to a linux machine and check it.

sudo chown datalayer:datalayer activedirectory.keytab
sudo chmod 400 activedirectory.keytab
sudo mv activedirectory.keytab /etc/security/keytabs
klist -ket /etc/security/keytabs/activedirectory.keytab
kdestroy
kinit -kt /etc/security/keytabs/activedirectory.keytab HTTP/localhost@DATALAYER.IO
klist -e

Or…

ktab.exe -a dlauser xxx -k activedirectory.keytab

Azure Active Directory (AAD)

Kerberos and LDAP will work in on-premise or hybrid cloud/vpn scenarios.

Depending on the scenario it may be feasible to consider AAD and oAuth2.

Applications

Login

Services

= https://portal.office.com

1. Azure

2. Windows Live

3. Model 2

API

Outlook

OneDrive

OneNote

Bing