Skype for Business Call Forwarding and Unified Messaging with Exchange 2013 | Step by Step

If you want to forward calls you can set this in the options of the SFB Client.


So far we are not able to forward calls to our Voicemail in Exchange.  First we had to configure unified messaging on the Exchange Server and then had to activate our exchange account for unified messaging.


But before configuring UM we must configure an Exchange and Skype for Business Partnership so that Skype for Business can access the Exchange Database Engine.

You should configured Autodiscover for Exchange correctly in order to establish the Partnership between SFB and Exchange. SFB and clients must be able to locate the Exchange Server.

First check if Autodiscover is set correct

If not you can set it as following and after a iisreset it will apply immediately.


Check that the FQDN of the Autodiscover URL is correctly listed in the Certificate of the Exchange Server.

Now as Autodiscover works we must configure Oauth in order to establish a secure connection between SFB and Exchange Server.

We had to set in the SFB Shell for Oauth the AutodiscoverUrl of Exchange as follows.

Note that we had to set here not the xml file and must use instead the svc File!


Now we must configure the actual Partnership of Exchange and SFB. Herefore we can use existing Scripts on both sides.

First we configure the Partnership on the Exchange Server.  The Script needs access to the authentication metadata document in json format on the SFB Server. You can test this from the Exchange Server over a browser and the following URL

https://<FQDN SFB Server>/metadata/json/1

You should be able to open a json Files.

If you could open the file you can execute the following script and after this reset the IIS with IISReset

Now the same we had to configure on the SFB Server but instead to use a script we can user here a Cmdlet in the SFB Shell.

First check as before if you can access the authentication metadata document on the Exchange Server under the following URL

If you see the jason file you can excecute the following Cmdlet to configure the Partnership from the SFB site.



You can test if the partner application relationship has been successfully established with the Test-CsExStorageConnectivity Cmdlet


Now after we configured successful the Partnership between SFB and Exchange we can configure the actual Integration of SFB and Exchange UM.

First we have to configure a unified messaging dial plan on the Exchange Server. This is used for accepting unified messaging calls for the users.


The VoIP Security option is Secured  so that both SIP signaling traffic and RTP media traffic will be transmitted between SfB and Exchange using an encrypted TLS communication.

Alternatively you can use the SIP Secured setting which would only encrypt the signaling traffic while all media traffic would be transmitted unencrypted.

Additionally a value of 1 is selected for the number of digits in extension numbers where the last digit are treated as the user’s extension.


Run the following Cmdlet to set the following recommended parameters.


Assign the the UM server to the new UM dial plan and configure support for both TCP and TLS connections with the following cmdlet.  


Now that TLS is enabled for the UM service the Exchange Server certificate needs to be assigned to the service to support TLS communications for signaling and media.

The Thumbprint you can determine with the Get-ExchangeCertificate | fl Cmdlet.


To commit these changes and enable TLS communications on the UM service it needs to be restarted, which can be performed quickly from PowerShell using the following cmdlet.

Restart-Service MSExchangeUM

Of course you can also configure the certificates for the UM services with the GUI


If you above not setup the UMstartupMode to Dual or TLS, you get the following error message:



Next perform the same configuration as above on the UM Call Router service with the following cmdlet.


The UM Call Router service also need to be assigned to the same certificate as the UM service.

Enable-ExchangeCertificate -Server mramail01 -Thumbprint <Thumbprint> -Services “UMCallRouter”

Alternativeley over the GUI as told above.


Just like the UM service the UM Call Router service needs to be restarted to enable the new configuration.

Restart-Service MSExchangeUMCR


When the new UM dial plan was created the Exchange Server will have automatically created a default UM Mailbox Policy.¬† This object will be named with the label ‚ÄėDefault Policy‚ÄĚ appended to the dial plan‚Äôs name (e.g. Stuttgart Default Policy).


The TechNet documentation seems to omit this fact and instructs the creation of another UM mailbox policy.  A simpler approach is to just modify the default object using the following cmdlet.

Get-UMMailboxPolicy | Set-UMMailboxPolicy -AllowedInCountryOrRegionGroups “Anywhere” -MinPINLength “6” -AllowCommonPatterns $true


As only a single policy exists then instead of querying for and entering the name of the default mailbox policy use the Get-UMMailboxPolicy cmdlet to automatically pass the results to the cmdlet as shown above.  Additionally some optional parameters were configured to allow for a different amount of  digit PIN to be defined instead of the default 6 digit length.


To validate that the UM configuration is functional then at least one user account must be enabled for Unified Messaging.  This process can be completed from either the management console or shell.



After entering the number and pin, the user get a confirmation mail with his pin per mail.

Alternatively the same steps can be performed using Exchange PowerShell cmdlets, so a second account configuration using this process is also covered as an example.

  • Using the Exchange Management Shell enter the following cmdlet to perform roughly the same exact configuration on another existing Exchange user.

Enable-UMMailbox -Extensions 1 -SIPResourceIdentifier “” -Identity “braintesting\mrath” -UMMailboxPolicy “Stuttgart Default Policy”

Make sure to enter a unique extension or to omit that parameter if the account’s phone number is already populated with the desired information.  The PIN was not manually set on this account which means Exchange will have automatically assigned a random PIN and then sent an email to the user’s mailbox with that information.


Configure UM IP Gateway

This step is handled by a script which creates the UM IP Gateway and IP Hunt Group as well as grants permissions to Skype for Business Server to read specific UM-related objects in Active Directory.

Make sure to allow for any outstanding AD replication to complete before running this script so that the newly created UM dial plan and any other changes are read by the script in their updated state.¬† If run too soon then sometimes the Dial Plans listed in the last line of the script output will display as ‚Äúnot found‚ÄĚ even though the configuration is correct up to that point.¬† If that happens it is safe to simply re-run the script, even multiple times if needed, as it will identify any previously successful configuration and thus report that no new changes were applied in those cases.

  • Using the Exchange Management Shell execute the ExchUCUtil.ps1 script located in the Exchange Server‚Äôs Scripts directory, as shown in the path below.


cd $exscripts

C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\ExchUCUtil.ps1

Note that if the Skype for Business Front End server shown at the bottom of the script output displays ‚Äú{(not found)}‚ÄĚ for the DialPlans field.¬† The value should be displayed as the UM Dial Plan name (e.g. Stuttgart).¬† As mentioned above this can usually be resolved by going back and re-executing the script after a few minutes have

If this issue appears then repeat the previous step until the results successfully report the expected dial plan as shown below.


To validate the creation of the UM IP Gateway open the Exchange Management Console and then navigate to the Unified Messaging > UM IP Gateways section.  Refresh the page if the new gateway does not appear at first.



Now as Unified Messaging is activated for the user, you are able to forward calls to your Voicemail.




From now calls will be routed to the voicemail and you receive it in your Inbox.




Skype for Business Conferencing | Step by Step

In the menue Conferencing you can configure conferencing rooms. Here for testing I only configured the menue Dial-In Access Number. For basic function this is enough. The other menues gives you more options for fine tuning.

I think these settings are self-explaining, you had to set a free number of your phone number block and a associated region and the languages. Be aware that in the users menue also a region is defined and that they can only access the conference rooms with the same region as they assigned.


In order to join a conference as a leader you must first set your personal pin. You can do this on the dialin site from skype for business.

Login with your credentials and set your pin. The Pin Policy you can set in the Conferencing menue under PIN POLICY.


Now you can join the conference as a leader with your personal pin.

Also after a conferencing room is assigned with the region to your user, you are able to send an invitation with Outlook.

The Logo in the invitation you can configure in the Conferencing Menue under MEETING CONFIGURATION.


Configure Skype for Business Enterprise Voice with a SIP-Trunk (DeutschlandLAN SIP Trunk) and the Office Master Gate from Ferrari electronic AG | Step by Step

Today I want go through the steps to activate enterprise voice on Skype for Business Server  with a SIP Trunk from Telekom, DeutschlandLAN SIP-Trunk.

First we had to add an Mediation Server in the Toplogy Builder from Skype for Business, in this case we add to the single Front End Server the Mediation Server Role.  Right click on Mediation Pools and select New Mediation Pool.

Here put in a FQDN for this pool, in my case I use a single Front End Server and had to put in the FQDN of this Frontend Server. Also select here “This pool has one Server” as we used a single server deployment.¬† Next you have to select the existing Frontend- and Edge Pool.

The Mediation Server is responsible for inbound and outbound calls to the Public Switched Telephone Network (PSTN) and dial-in Conferencing.

The listening ports depends on the SIP Trunk Provider or if you use a Session Border Controller (SBC) like here, you must set the ports configured on the SBC.

Under is a good explanation about the Mediation Server Role.

If you have a single Front End Server Deployment, the server can handle up to 150 calls whereas a standalone Mediation Server can handle up to 1.100 calls.

We deploy here the Mediation Server Role on the single Front End Server, in this case we go to the settings of the Standard Edition Front End Server and select at the left menue the point Mediation Server. Here  select the checkbox for Collocated Mediation Server enabled. The default  Port for encrypted traffic with TLS is 5067. You can also enable only TCP without encryption, default Port here is 5060. This settings depends on your SBC. In my case I use TLS Port 5067.

If you want to deploy a standalone Mediation Server you must right click on Mediation Pools and select new Mediation Pool, here you can add one standalone or multiple servers to the Pool.

Next we have to add a PSTN Gateway through which we route inbound/outbound calls to and from our Skype for Business Server.

You must put in a FQDN for the SBC, it is not possible to enter the ip address of the SBC, so you have to register this FQDN at your internal DNS server.

At this step also the trunk is created for this PSTN Gateway. Here we have to set a name and the ports for this trunk, I used here the FQDN of the SBC but you can use any name you want. The Trunk is the phone line with the sip protocol. And this trunk connects the SFB with the SBC.

The ports are dependent on the setting of the SBC and the
SIP Trunk Provider, in my case Deutschland LAN Sip Trunk from Deutsche Telekom.

Next step is to configure the SBC in your network or of course you can configure the SBC first and than the SFB, it doesn’t matter which sequence!

In my case I use here the Office Master Gateway installation image 4.1 from Ferrari electronics

download link

Version 4.1 supports DeutschlandLAN SIP Trunk

This Image is based on Linux CentOS 6.8

I run this as a hyper-v VM

A good installation guide of the OfficeMaster Gate you will find under

First you have to configure the network setting of the SBC. You can see the actual ip of the SBC appliance from the console when you press i for info

Here I already had set a static IP from my test network. You can set this with the OfficeMasterGate Configuration utility which can run on a different VM in your network.


As you can see in the following figure, I already had intalled an older version and now update to the actual 6.113.1102 version. I get a warning that my installed service OfficeMaster-Syslog must deinstalled and the new version of it reinstalled in order to work with the new version of the configuration utility.

The new version of the  OfficeMaster-Syslog you can download here

With the¬†¬†OfficeMaster-Syslog service you can debug the traffic of the OfficeMasterGate when it doesn’t work as expected and is optional.

You may wonder to see the ISDN protocol in the logs when configured a sip trunk which uses VOIP with the SIP and RTP protocol, the reason is, that ferrari electronics comes from the ISDN world and used on the SBC itself for routing the calls, the ISDN protocol and translates it to VOIP when forwarding the calls to the internal Skype for Business Server and also when it forwards the calls to the SIP Trunk Provider. The benefits are that ferrari can use the existing code but will change this to native VOIP and SIP/RTP protocol in the future and further versions.

Now as we had installed the OfficeMaster Gate configuration utility, we can configure first the network settings of the SBC.

Press the connect button and enter the ip address the Appliance get from the DHCP Server and the password, default is omc  and can be changed over the console menue of the Appliance.

You can put the SBC to your internal network or your perimeter network, he doesn’t need a public IP address assigned directly on the SBC.¬† The SBC established in my case of DeutschlandLAN SIP Trunk a connection from internal to the SBC of the SIP Trunk Provider and only needs allowed traffic outbound. If your Firewall allows all outbound traffic and do not filter the traffic, you don’t have to change the configuration of the DeutschlandLAN SIP Trunk, in this case Registered Mode is per default the best choice. If your Firewall filters outbound traffic and you must allow which traffic can flow outbound, best choice is to change DeutschlandLAN SIP Trunk to Static Mode where the used outbound Ports can be set. You can change this settings in the telefonie center

If your internal SFB Clients not in same Network as the OMG, you should modify the Routing on the OMG and add the Routes to the Client Subnets, otherwise if Media Bypass is enabled, the OMG can’t route traffic to the clients.

Now we have to configure the connection from the SBC to the SIP Trunk Provider, in my case DeutschlandLAN SIP Trunk.

First the OfficeMaster Gate needs to register the Trunk at the SBC of the Provider.

This information you get from your SIP Trunk provider.


The screenshots from Ferrari use for SIP Trunk Registration the TCP protocol on port 5060 instead the secure TLS on port 5061. A documentation from Telekom for the SIP Trunk DeutschlandLAN in combination with Skype for Business is so far not available and the support told me that they had no experience with this combination. They shipped this Trunk with a LANCOM 883 VOIP Router and had only a documentation and experience with this.

After doing a DNS NAPTR Record Lookup on the FQDN of the Registrar, I saw that their was a SRV Record entry with SIPS (SIP over TLS). So I tried to configure as you can see on the screenshots above the registration for this trunk and the voice routing resp. the trunk connection itself over tls and port 5061 (screenshots below) and it works perfect for outbound calls.

Unfortunately it works at the moment with Firmware 4.1.380 (2018-01-05) not for inbound calls over TLS and Port 5061 so far.

Ferrari electronic fixed this problem with the DeutschlandLAN SIP TRUNK and had an internal pre-release demo which works for outbound and inbound calls over TLS and Port 5061. If you need this pre-release demo and can’t wait for the next official release which will include this fix, please contact the hotline of ferrari electronic.

The connection from the Office Master Gate to the internal Mediation Server resp. Skype for Business FrondEnd Server works over TLS and Port 5067 or what tls port you set on the Mediation Server. The only thing to keep in mind that this works is to configure a X.509 Certificate on the Office Master Gate. In my case I also had a internal Microsoft PKI  in my test network and requested a certificate with the CSR from the Office Master Gate here. You can also import a Root Certificate to the Office Master Gate to be sure that he trusts the certificate you configured on the internal Mediation Server.
This root certificate is only for trusting the certificate from the internal Mediation server. The certificate from the Office Master Gate again is only important that your internal Mediation Server can establish a secure tls connection to him.  And of course you should be aware that the Mediation Server trusts the certificate on the Office Master Gate.

You can check the connection over tls from the Office Master Gate to the Mediation Server with the Verify … button in the Certificates menue

Here you can see my tests regarding the DNS NAPTR Records for the SIP Proxy FQDN.

If you do a DNS SRV Lookup on the second NAPTR Record with the TLS SRV Records you can see that for TLS on port 5061 three SRV Records are registered.

Now after a DNS A-Record Lookup on the SRV Record with the lowest priority we get the IP of one of the SBC from Telekom with the SIP registration service on TLS.

Trying to connect to this service with telnet works as you can see

After this you must configure the Calls for the Trunk, here click on Change Setttings …

Here you can see two network adapter symbols at the top, normally they named PCM 1 an PCM 2 and comes from the history of ferrari and their relation to the ISDN world. I changed this for a better understanding to Lync and SIP, because the first adpater is connected to the internal Skype for Business Server and the second adapter is connected to the SIP Trunk Provider. So calls to and from Skype for Business traverse to the first adapter and calls from and to the PSTN traverse to the second adapter.

For each Adapter you have to add two call  processing rules, incoming and outgoing rules.

Let’s do this for the first Adapter PCM 1 in my case labeled Lync which is responsible for the connection from the OfficeMaster Gate to the Skype for Business Server.

We need to add a rule for calls from ISDN (calls from the PSTN resp. SIP Trunk Provider which converted to the ISDN protocoll from the OfficeMaster Gate)
This calls we route here to the internal Skype for Business Mediation Server resp. the Mediation Server Role.

Protocol and Port must be the same as configured on the Mediation Server.

Next we must add a rule for Calls to ISDN,  these are VOIP SIP Calls from the internal Skype for Business Server which were converted to ISDN from the OfficeMasterGate and here terminated for further routing to the SIP Trunk Provider for which the second adapter is responsible.

Here you must enter the IP Address from the Skype for Business Mediation Server or Role.

After this we come to the configuration of the second adapter PCM 2 or in my case labeled SIP.

We must also configure here two call rules, one for calls from the OfficeMaster Gate which are converted  into ISDN to the SIP Trunk Provider and reconverted in VOIP SIP and one for all incoming Calls from the SIP Trunk Provider which first must converted from the OfficeMaster Gate into  ISDN protocol.

First rule is for calls from the OMG to the SIP Trunk Provider. Since OMG Version 4.1 you can select the DeutschlandLAN SIP Trunk 1TR118 Profile, on which all parameter configured for this trunk or many other SIP Trunk Provider Profiles. In my case I need the DeutschlandLAN SIP Trunk Profile. As we use TLS as discussed above we need to set the protocol to TLS and the port to 5061. The FQDN of the registrar is

The second rule are for all incoming calls from the SIP Trunk Provider. Here you had only to select the Provider Profile in my case the DeutschlandLAN SIP Trun which also set the correct paramters for the incoming VOIP calls.

Now after configuring the SBC and the connection with Skype for Business Server, we have to switch to the SFB Control Panel to configure the rest.

First we need to enable the users for Enterprise Voice.  You can enable this in the Users menue.

Also you need to enter the telephone number and the extension number in Germany the MSN (Multible Subscriber Number) number. in the E.164 format

Skype for Business Server needs to know how to route calls outside to the PSTN. Therefore we go to the Voice Routing menue in the control panel.

You can edit the Global Dial Plan or create a separate Dial Plan which I prefer. In case of multiple office locations you can create here for each location a separate Dial Plan and the corresponding normalization rules.

In my test environment I only had one SIP Trunk with two lines and one phone number block so I only need one Dial Plan for the location in Stuttgart.

At this location I created 5 normalization rules, the first for international calls outside germany, the second for calls within germany, the third for calls within Stuttgart so you do not have to dial the area code +49 711, the fourth rule are for calls within the company at this location and the last rule do not normalize the dialed number.


Pattern to match:  ^00(\d{2}\d+)$


Pattern to match:  ^0(\d{3}\d+)$

Ortskennzahl Stuttgart

Pattern to match:  ^(\d{3}\d+)$

Intern Stuttgart

Pattern to match:  ^(\d{1})$

Keep All

Pattern to match:  ^(\d+)$

We also need to modify the Global Voice Policy or create a separate one as I did. If you want to allow different features or PSTN Usages for different locations or users, you can create more Policies.

I named it like the SIP Trunk.

As you can see I created one PSTN usage record and named it “Allow all Calls” and so I added all created Routes to this so that all users are allowed to use all routes. Over these PSTN usages you can control which routes the users can use or are allowed to.¬† Before you can add here the routes you must first create them, you will see this at the next step.

The Routes are created automatically from the Associated Normalization Rules you added to the Dial Plan Policy.

Route for Interne Durchwahl Stuttgart

Route for Ortskennzahl Stuttgart

Route for National

Route for International

Next step is to configure in Voice Routing the register Trunk Configuration, here we can set some further options for the SIP Trunk.

Don’t forget to select the configured Voice Policy and Dial Plan Policy in the steps before for the users who should use this policy and should be able to make calls to the PSTN.

Now Users are able to call from Skype for Business to the PSTN Public Switched Telephone Network and get calls from.

I will describe all the settings and options more in detail the next weeks and also the normalization rules to translate the dialed numbers from the users into correct E.164 numbers.

Links SIP TRUNK Deutsche Telekom / QSC

SFTP / SSH Server unter Windows einrichten mit Cygwin | Step by Step

Als erstes m√ľssen wir Cygwin herunterladen und auf dem Windows System installieren.



INFOs √ľber Cygwin

Mit Cygwin [ňąs…™…°w…™n] lassen sich Programme, die √ľblicherweise unter POSIX-Systemen wie GNU/Linux, BSD und Unix laufen, auf Microsoft Windows portieren. Es ist eine Kompatibilit√§tsschicht, die die Unix-API f√ľr verschiedene Versionen von Microsoft Windows zur Verf√ľgung stellt, auf deren Basis eine Vielzahl von Programmen aus der Unix-Welt unter Microsoft Windows √ľbersetzt werden k√∂nnen.

Mittels Cygwin portierte Programme laufen unter Windows NT, Windows 2000, Windows XP, Windows Vista, Windows Server 2003 und seit Version 1.7 auch unter Windows 7 und Windows Server 2008. Berichten zufolge ist f√ľr einen erfolgreichen Betrieb unter Windows 8 eine manuelle Korrektur der Konfiguration erforderlich. In √§lteren Versionen laufen auch Programme unter Windows 9x.

Cygwin wurde urspr√ľnglich von der Firma Cygnus Solutions programmiert und seit deren √úbernahme durch die Softwarefirma Red Hat erfolgt dort die Weiterentwicklung.









Hier die Kategorie NET auswählen


Paket openssh (bin) auswählen




Nach der Installation können wir die Cygwin Konsole starten


Mit ssh-host-config starten wir die Konfiguration des Systems

  • Should privilege seperation be used? yes
  • new local account ‘sshd’ ? yes
  • Do you want to install sshd as a service ? yes
  • Enter the value of CYGWIN for the daemon: [] ntsec


  • Do you want to use a different name ? no
  • Create new privileged user account ‘cyg_server’ ? yes
  • Passwort vergeben


  • sshd Dienst starten mit¬† net start sshd


Cygwin und der SSH Dienst ist nun fertig installiert und gestartet.


Alternativ können wir die Cygwin Shell auch innerhalb der Windows Command Shell
ausf√ľhren. Hierzu einfach in der Windows Command Shell ins Cygwin bin Verzeichnis wechseln und sich √ľber ssh username@hostname anmelden.



Im angelegten Cygwin Verzeichnis und hier im etc Verzeichnis befindet sich die Datei passwd. In dieser werden unter Unix die Benutzer gespeichert. Wenn wir diese Datei öffnen, sehen wir, dass bei der Installation von Cygwin schon die lokalen Benutzer vom Windows System in diese Datei importiert wurden.


Wenn wir nun nachtr√§glich unter Windows einen Benutzer anlegen der ebenfalls in der Cygwin Umgebung berechtigt werden soll, so m√ľssen wir diesen noch hinzuf√ľgen.

Im folgenden Beispiel wollen wir einen User f√ľr den SFTP Zugriff anlegen der sich sp√§ter dann per SFTP auf eine Netzwerkfreigabe auf dem Windows System verbinden kann.

Zuerst auf dem Windows System einen Benutzer erstellen



Anschließend eine Netzwerkfreigabe auf dem Windows System einrichten und dem angelegten Benutzer Schreib- und Leserechte auf diese Freigabe vergeben.

Als erstes m√ľssen wir nun unter Cygwin den lokal angelegten Windows User sftp01 in die passwd Datei importieren mit

  • mkpasswd -u sftp01 -l >> /etc/passwd
    (-u f√ľr User | -l f√ľr lokalen Benutzer | -d f√ľr Dom√§nen Benutzer | >> f√ľr Eintrag in passwd Datei erg√§nzen | > f√ľr passwd Datei √ľberschreiben)

Wir könnten auch alternativ mit

  • mkpasswd -l > /etc/passwd
    (alle angelegten Benutzer auf dem Windows System in die passwd Datei importieren und die vorhandenen Eintr√§ge √ľberschreiben)
  • mkgroup -l > /etc/group
    (alle lokalen Gruppen im Windows System in die Gruppendatei unter Cygwin bzw. Unix importieren und die vorhandene √ľberschreiben)


Anschließend können wir uns mit dem angelegten User per ssh an der Konsole anmelden.

  • ssh sftp01@brainweb01


Da wir beim ersten Login den √∂ffentlichen Schl√ľssel vom Cygwin OpenSSH Paket noch nicht auf unserem Rechner abgelegt haben, erscheint die Meldung, dass die Identiti√§t des Servers unbekannt ist.

Zum erfolgreichen Verbinden m√ľssen wir hier mit yes best√§tigen.

Anschlie√üend wird das home Verzeichnis f√ľr den User erstellt.


Ab sofort ist es m√∂glich von einem entfernten Rechner √ľber putty sich direkt per ssh auf die Cygwin Unix Shell zu verbinden.


Auch per SFTP kann ich mich ab sofort mit dem System verbinden.


In diesem Beispiel verwenden ich den FTP Client FileZilla. Als Protokoll hier das SFTP Protokoll auswählen. Je nach Version von Cygwin, openssl, FileZilla kann es vorkommen, dass der Zugriff
auf Windows UNC Shares mit FileZilla Probleme bereitet und dieser anstelle auf die
UNC Pfade mit //Share versucht auf Unix Pfade mit /Share zuzugreifen. Mit WinSCP oder SecureFX hatte ich hier noch keine Probleme.

Bei POSIX-konformen Betriebssystemen wird der UNC Pfad mit //Share ansellte von Share angegeben. Es funktioniert jedoch auch im Windows UNC Format, jedoch erscheint folgende Meldung nach dem Login wenn das Home Verzeichnis auf ein Windows UNC Share verweist:



Beim Zugriff werden wir nun immer mit dem angelegten Home Verzeichnis verbunden. M√∂chten wir aber mit einer Netzwerkfreigabe verbunden werden, so m√ľssen wir die passwd Datei im Verzeichnis /etc noch anpassen.

Hier suchen wir die Zeile mit unserem angelegten Benutzer und √ľberschreiben am Ende den Pfad
des Homeverzeichnis mit dem UNC Pfad (POSIX-konform) der gew√ľnschten Netzwerkfreigabe.


sftp01:unused:1013:513:sftp01,U-BRAINWEB01sftp01,S-1-5-21-357073478-4224919887-655416145-1013://brainweb01/FTP ROOT


Im folgenden werden noch die benötigten Schritte zur Authentifizierung ohne Kennwort und mit Public und Private Key beschrieben.

Als erstes m√ľssen wie die Schl√ľsselpaare erzeugen. Hierzu mit dem angemeldeten User
der sp√§ter auch f√ľr den Zugriff verwendet wird folgenden Befehl ausf√ľhren:


Jetzt wird jeweils gefragt was f√ľr Schl√ľssel (also RSA, DSA, usw. verschiedene Verschl√ľsselungsverfahren) angelegt werden sollen.


Im Homeverzeichnis sollte jetzt ein .ssh Ordner zu finden sein, wo die Schl√ľsselpaare abgelegt sind! Der .ssh Ordner ist ein versteckter Ordner und kann mit dem Listbefehl ls ‚Äďla angezeigt werden!

Dann kann man √ľber cd .ssh in den Ordner wechseln und mit ls ‚Äďl die Schl√ľsselpaare anzeigen lassen. Da wir jedoch unser Home Verzeichnis auf eine Windows Freigabe gesetzt haben, finden wir den .ssh Ordner mit den Schl√ľsselpaaren in dieser Freigabe.



Die *.pub sind die Public Keys welche in der authorized_keys Datei aufgef√ľhrt werden und dadurch Zugriff auf den Server bzw. dieses Verzeichnisses √ľber die dort aufgelisteten Schl√ľssel erm√∂glichen.

Die Dateien ohne *.pub sind die privaten Keys welche f√ľr die Verbindung der Clients f√ľr den Zugriff auf das System verwendet werden.

Wenn wir also die RSA Verschl√ľsselung verwenden m√∂chte, dann m√ľssen wir die Datei id_rsa auf den Client kopieren und f√ľr die Verbindung verwenden.

Wenn nun Jemand Zugriff auf den Server ben√∂tigt und jedoch sein eigenes Schl√ľsselpaar verwenden m√∂chte, so muss lediglich der eigene √∂ffentliche Schl√ľssel in die Datei authorized_keys erg√§nzt werden.


F√ľr die Verwendung in Putty muss der Key erst noch mit PuttyGen konvertiert werden.



Anschlie√üend kann der Schl√ľssel dann f√ľr die Authentifizierung verwendet werden.


Logging des SSHD (OpenSSH Daemon) Subsystem SFTP aktivieren

Zuerst m√ľssen wir das Paket syslog-ng im Zweig Admin nachtr√§glich installieren √ľber das Cygwin Setup.


Nach der Installation die Cygwin Konsole als Admin ausf√ľhren und die Konfiguration √ľber den Befehl: /bin/syslog-ng-config ausf√ľhren.


Abfrage ob syslog-ng als Dienst installiert werden soll mit yes beantworten und danach den
Dienst mit net start syslog-ng starten.

Damit SFTP (Subsystem sftp)¬† Ereignisse protokolliert m√ľssen noch folgende √Ąnderungen in der Datei /etc/sshd_config vorgenommen werden:


Unter sind die verschiedenen Level  erläutert.

Abschließend noch den Logging Daemon neu starten mit cygrunsrv -S syslog-ng und den SSHD Dienst neu starten mit:

net stop sshd

net start sshd

Ab sofort protokolliert das Subsystem SFTP alles in der Datei /var/log/messages



Verwenden eines Dom√§nen Account als Service Account f√ľr den CYGWIN sshd Dienst

Als erstes einen Dom√§nen Account¬† erstellen, bsp. DOM√ĄNE\svcCygwin. Dieses Konto muss in die lokale Administrator Gruppe des Servers auf dem Cygwin l√§uft.

Anschlie√üend diesen User wieder √ľber mkpasswd und mkgroup in Cygwin importieren.

mkpasswd -u svcCygwin -d >> /etc/passwd

(nicht im Format DOM√ĄNE\username sondern nur den username!!!!, in der PASSWD wird die Dom√§ne dann automatisch durch den Schalter -d hinzugef√ľgt, generell in der Cygwin Shell nur den username dann f√ľr den Dom√§nenuser immer angeben!)

mkgroup -l > /etc/group

In der Local Security Policy des Servers auf dem Cygwin läuft folgende Berechtigungen dem Domänen Account svcCygwin gewähren.

Adjust memory quotas for a process

  Act as part of the operating system (SeTcbPrivilege)
  Create a token object               (SeCreateTokenPrivilege)
  Replace a process level token       (SeAssignPrimaryTokenPrivilege)


Anschlie√üend m√ľssen wir noch den Besitz folgender Verzeichnisse und Dateien f√ľr den neuen Dom√§nen Service Account svcCygwin √ľbernehmen

$ cygrunsrv --stop sshd
$ chown [domain_user] /var/log/sshd.log
$ chown -R [domain_user] /var/empty
$ chown [domain_user] /etc/ssh*

Zuletzt noch in der Dienste Konsole unter Windows dem Dienst CYGWIN sshd den neuen Domänen Service Account als Logon Account hinterlegen und fertig.


Setting up a Cygwin OpenSSH Server for Windows Domains on a TADDM Gateway Server
Cygwin wieder deinstallieren

  1. Alle Cygrun Dienste stoppen und deinstallieren √ľber die cygrunsrv.exe im /bin Verzeichnis von Cygwincygwin_remove
  2. Alle Cygwin Prozesse beenden
  3. Löschen des Cygwin root Verzeichnis
  4. Löschen aller Cygwin shortcuts
  5. L√∂schen des Registry Schl√ľssels SoftwareCygwin





WLAN RADIUS Authentifizierung einrichten unter Windows Server 2012 | WPA2-Enterprise | Step by Step


  • der RADIUS Server unter Windows ab Version 2008 wird √ľber die Serverrolle Network Policy and Access Services bereitgestellt.






  • die gew√ľnschten WLAN Access Points die per RADIUS die User authentifizieren sollen, erg√§nzen und ein gemeinsames Passwort (Shared Secret) eintragen, mit dem der Server und der Access Point ihre Kommunikation sichern. Das Shared Secret muss auf dem RADIUS Server und dem Access Point identisch sein.



Protected Extensible Authentication Protocol, Protected EAP, or simply PEAP (pronounced peep), is a method to securely transmit authentication information, including passwords, over wireless LANs. It was jointly developed by Microsoft, RSA Security and Cisco. It is an IETF open standard.

PEAP is not an encryption protocol; as with other EAP types it only authenticates a client into a network.

PEAP uses only server-side public key certificates to authenticate clients by creating an encrypted SSL/TLS tunnel between the client and the authentication server, which protects the ensuing exchange of authentication information from casual inspection.

PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication.



  • die Windows Gruppen die Zugriff auf das Netzwerk per WLAN haben sollen hinzuf√ľgen





  • der Assistent erzeugt hier eine Connection Request Policy, hier muss nichts weiter eingestellt werden.


  • ebenfalls erzeugt der Assistent eine Network Policy, hier muss noch in den Eigenschaften im Register Constraints bei den Authentication Methods f√ľr das EAP (PEAP) Protokoll ein Zertifikat ausgew√§hlt werden. Dieses m√ľssen wir zuerst erstellen wie im Weiteren gezeigt wird.


  • Im Register Conditions k√∂nnen wir noch die User, die Zugriff auf das WLAN erhalten sollen berechtigenadd_groups_users01
  • PEAP uses only server-side public key certificates to authenticate clients by creating an encrypted SSL/TLS tunnel between the client and the authentication server, which protects the ensuing exchange of authentication information from casual inspection.
  • f√ľr den RADIUS Server muss noch ein Zertifikat erstellt werden, dieses kann √ľber die Active Directory Certificate Services (AD CS) erstellt werden.


  • auf dem Server auf dem die Active Directory Certificate Services (AD CS) installiert sind eine neue Zertifikatsvorlage erstellen.


  • hier die vorhandene Zertifikatsvorlage Computer duplizieren und anpassen



  • Register Sicherheit / Security


  • Register Sicherheit / Security


  • Register Antragstellername / Subject Name

23_register_Antragstellername(Subject Name)

  • in der Konsole Zertifizierungsstelle (PKI) das neue Zertifikat welches in der MMC Konsole (Zertifikatsvorlage) erstellt wurde f√ľr die PKI aktivieren.




  • auf dem RADIUS Server das neue Zertifikat anfordern und hier die neu erstellte Zertifikatsvorlage auw√§hlen. Das Zertifikat im lokalen Computerkonto anfordern!




  • unter DETAILS lediglich im Register Extensions bei Include Symmetric algorithm diese Erweiterung aktivieren.




  • hier das neu erstellte Zertifikat ausw√§hlen



Soweit ist die Installation und Konfiguration vom RADIUS Server abgeschlossen. Es muss nun nur noch bei den WLAN Access Points unter Sicherheit der Modus WPA2 oder WPA2 Enterprise je nach Modell ausgewählt werden, die IP Adresse des Radius Servers und ein Shared Secret ausgewählt werden. Der Radius Standard UDP Port 1812 sollte schon eingetragen sein.


Bei der Anmeldung der Clients wird nun unter Windows 7 standardmäßig das Windows Benutzerkonto zur Anmeldung herangezogen und bei Windows 8 erscheint eine Eingabemaske mit Benutzername/Passwort und eine Checkbox bei der nach Aktivierung ebenfalls das Windows Benutzerkonto zur Anmeldung verwendet wird.

Ist es bei Windows 7 gew√ľnscht diese standardm√§√üige Verwendung des Windows Benutzerkontos zu deaktivieren und einen Login Dialog zu haben so kann dies in den Eigenschaften der WLAN Verbindung konfiguriert werden.

  • Register Sicherheit unter Eigenschaften der WLAN Verbindung
  • Einstellungen der Netzwerkauthentifizierung Microsoft: Gesch√ľtztes EAP(PEAP)
  • Konfigurieren bei Authentifizierungsmethode EAP-MSCHAP v2
  • hier den Haken entfernen damit nicht mehr die Windows Anmeldedaten f√ľr die RADIUS Authentifizierung verwendet werden.