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.
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.
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:
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.
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
Protocol and Port > AD and AD DS Usage > Type of traffic
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"
Turn User Account Control off
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:
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
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
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
ktab.exe -a dlauser xxx -k activedirectory.keytab
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.
Client Secret- https://account.live.com/developers/applications/create