admin – matrixpost Blog

20. January 20183. February 2018

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 https://autodiscover.braintesting.de/autodiscover/metadata/json/1

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 “marcus.rath@braintesting.de” -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.

Links/Source:

http://blog.schertz.name/2015/09/exchange-and-skype-for-business-integration/

http://blog.schertz.name/2015/10/skype-for-business-and-exchange-um-integration/

http://cloudexchangers.com/skypeforbusinessoauthwitho365/

20. January 20183. February 2018

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.

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.

17. December 20175. April 2019

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 https://windowsitpro.com/lync/demystifying-mediation-server-role-lync-server-2013 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

https://www.ferrari-electronic.de/produkte/officemaster-gate.

download link

https://www.ferrari-electronic.de/downloads.html

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

https://www.youtube.com/watch?v=sWciI0hX1pg

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.

download

https://www.ferrari-electronic.de/downloads/files/320002/6.1.3/Setup-OfficeMaster-Gate-Config-6.13.1102.exe

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 https://www.ferrari-electronic.de/downloads/files/320003/6.12/Setup-OfficeMaster-Syslog-Service-6.12.1061.exe

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 https://telefoniecenter.t-online.de/fcc

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.

fig. https://www.ferrari-electronic.de/downloads/files/102004/2016/DE_QS_1TR118_w.pdf

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 reg.sip-trunk.telekom.de.

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

https://en.wikipedia.org/wiki/E.164

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.

International

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

National

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

http://netzpalaver.de/2017/08/08/palaver-mit-telekom-deutschland-zu-sip-trunks/

http://faq.bintec-elmeg.com/index.php?title=Grundlegende_Informationen_zu_STUN_und_NAT_bei_SIP-Anschl%C3%BCssen_der_Deutschen_Telekom_(DeutschlandLAN)&mobileaction=toggle_view_desktop

https://www.qsc.de/assets/documents/rlch2015/extranet/produktegk/IA-IPfonie_extended_link-2013-4-1712.pdf

2. May 20139. January 2018

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

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

Quelle: https://cygwin.com/setup.exe

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.

https://www.redhat.com/services/custom/cygwin/

Quelle: https://de.wikipedia.org/wiki/Cygwin

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.

Beispiel:

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:

ssh-user-config

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 https://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/sshd_config.5?query=sshd_config 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)

https://cygwin.com/faq/

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.

Links

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

Alle Cygrun Dienste stoppen und deinstallieren über die cygrunsrv.exe im /bin Verzeichnis von Cygwin
Alle Cygwin Prozesse beenden
Löschen des Cygwin root Verzeichnis
Löschen aller Cygwin shortcuts
Löschen des Registry Schlüssels SoftwareCygwin

27. April 20139. January 2018

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.

Quelle: https://wiki.freeradius.org/protocol/EAP-PEAP

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 berechtigen

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

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.

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.