Category: Okategoriserade

Teams in your Multi-user environment done right!

Microsoft Teams is on the rise, more and more businesses is seeing the potential of Teams and want a piece of the action.

Unfortunately Microsoft Teams is not ideally designed to work on a Multi-user environment like Citrix Xenapp or Microsoft Remote Desktop services. It is entirely installed in the users profile, and its quite big. A clean installation of teams is roughly 600 MB and will quickly grow, and you know what that means… You guessed it: Super long logon time, since logging on to the Multi-user environment often means the profile would be downloaded to Session Host before you are properly logged on, the users will not be happy! And on top of that, the latest recommendation in size per Teams installation is 3 GB…

There is however some rumors indicating there will be releasing a business version soon addressing this very issue! But if you are anything like me, and cant simply wait, there is a solution if you are willing to pay a small price, and you will at the same time have access to tons of other great stuff.

FSLogix Profile Container

FSLogix Profile Container is a great product that basically removes the profile size entirely, is an little agent you install on your Session Hosts and configure with an ADMX, you also need a file share with enough space for some big profiles. FSLogix is in the business of so called filter-drivers, what it does is simply put, lying to Windows. For example, when you install a 32-bit application to your 64-bit Windows System, Windows will use its own filter-driver to get it to work, its the same technology, its efficient and simple. In FSLogix case it is lying to the windows about the profiles, Windows thinks its a local profile, it does not know that in fact, the entire profile is contained in a vhd-file, mounted to the server. Because its a virtual disk that attaches to the server, there is only one SMB handle. It will therefor not be a huge load on the network, which you often sees when you for example roam your profiles.

Install Teams

When you have FSLogix Profile Container in place you can now install teams on your environment.  In early October Microsoft released a new version of Teams with some new features when deploying Teams to all the users in an organization, we are going to use parts of that to install Teams on to our environment!

 

  1. Download the latest version of Teams MSI-file (x64) file here!
  2. If you like to disable Auto-start of Teams use the following install string (otherwise just install without the option):
    This will put an Install file under ”C:\Program Files”, and when a user logon it will automatically install Teams to this user.
  3. You do not need to update the MSI to the latest version, Teams will automatically download and install pending updates on the next logon of the user.

There you go, now your users can benefit from the full experience of Teams in your Multi-user environment, with one exception: if you are using Citrix, you have ”Skype for Business Optimization Pack” to utilize local client resources for best quality of Skype meetings and calls. There is no support for Teams as of for now. It will soon be available though. With that said, I wouldn’t uninstall Skype for business just yet.

Other Great stuff

As mentioned above, there is a lot of benefits using FSLogix Profile Container. For a great period of time, Citrix User Profile Manager has been the best way to reduce the size of the profiles while still have the most important settings saved in your profile. But this is still just a trade-off, you trade off your caches and settings that impact your profile logon, but at the same time still trying to get the best experience for the user, this will sometimes collide and you have to choose between longer logon time or full functionality of a certain application.

With FSLogix Profile Container you no longer need to worry about large profiles, you don´t need to trade off! There are a lot of applications that saves a ton of settings and files in your profile that you now can install without impacting the user experience, this opens up a great deal of opportunities. You can for example install OneNote with it´s (potentially)  gigantic cache, CAD applications with thousands of files in the user profile and so much more.

 

If you find this interesting and would like a trial of FSLogix Profile Container to see if this fits your organizations needs, please contact us. It is easily installed and does not require additional servers or infrastructure!

 




Netscaler: ADFS protected by AAA – How to handle SAML POST requests

A limitation with Netscaler AAA is that it cannot handle FormData sent in a POST request to a Netscaler LB vServer that is protected by a AAA vServer. What happens is that the Form data in the POST will not be included when the user is redirected back to the LB vServer after AAA authentication. This becomes relevant in scenarios where you have a SAML ServiceProvider (SP) that is configured to do a login POST to an SAML IdentityProvider (IDP) and that IDP is protected by Netscaler AAA.

Below is the process flow:
1. User browses to the SAML SP address https://app1.somedomain.com/saml/login, which in this scenario is the URL that initiates the SAML logon process
2. The SP gives the user a SAML request and the user’s browser performs a POST against the IDP URL https://adfs.mycompany.com/adfs/ls/ with this SAML Request as the Form data.
3. The address https://adfs.mycompany.com points to a Netscaler LB vServer which is protected by AAA, so when Netscaler sees the incoming GET request above it will redirect the user to https://aaa.mycompany.com for AAA authentication (we assume the user has not authenticated against this AAA vServer this web session).
4. User performs AAA authentication, and is afterwards redirected back to the original URL https://adfs.mycompany.com/adfs/ls. HOWEVER, the SAML Request Form data is now missing.
5. User will land on https://adfs.mycompany.com/adfs/ls and receive an error message, because the ADFS server doesn’t know how to handle a request that doesn’t have any SAML form data.

 

Important notes:

  • Form Data passed along with a POST to a LB vServer, such as ADFS, that is protected by AAA will be ‘dropped’ when the user is redirected back to the LB vServer after successful AAA authentication. This only applies if the user has not authenticated against the AAA in the current web session (ie the user does not have a NSC_TMAS cookie). We will make use of this later on.
  • Query values included in a POST are not ‘dropped’, so this flaw is limited to Form data only.

 

Solution/work-around:
The easiest solution is to simply ask the SAML SP to use Redirect instead of POST for the SAML authentication process, but if that is not an option (the SAML SP’s backend code or configuration doesn’t support SAML Redirect) then below is a work-around I’ve been using. Basically what you do is that you store the original SP URL, https://app1.somedomain.com/saml/login, in a cookie in the user’s browser and in step 5 the user will be redirected back to this URL again.

Below is the process flow with a work-around implemented for POST:
1. User browses to https://app1.somedomain.com/saml/login, which in this scenario is the url that initiates the SAML logon process
2. The SP gives the user a SAML request and the user’s browser performs a POST against the IDP URL https://adfs.mycompany.com/adfs/ls/ with this SAML Request as the Form data.
3. The address adfs.mycompany.com points to a Netscaler LB vServer which is protected by AAA, so when Netscaler sees the incoming GET request above it will redirect the user to https://aaa.mycompany.com for AAA authentication.
3b. NEW: When the user is redirected to https://aaa.mycompany.com now, a Rewrite policy will trigger that will create a cookie ”ADFSPostCookieURL” for the user, and this cookie will contain the value ”https://app1.somedomain.com/saml/login”.
4. User performs AAA authentication, and is afterwards redirected back to the original URL https://adfs.mycompany.com/adfs/ls.
5. NEW: We have a Responder policy on our ADFS LB vServer that checks if the path is ”/adfs/ls” and if the cookie ”ADFSPostCookieURL” exists, and if both are true then we read the value in cookie ”ADFSPostCookieURL” and Redirects the user to that URL.
6. User is redirected back to https://app1.somedomain.com/saml/login, which will restart the SAML logon process
7. The SP gives the user a new SAML request and the user’s browser again performs a POST against the IDP URL https://adfs.mycompany.com/adfs/ls/ with this SAML Request as the Form data.
8. A key difference now is that the user already has done AAA authentication this web session and thus has a valid AAA cookie, and won’t be redirected to https://aaa.mycompany.com for authentication. The POST against https://adfs.mycompany.com/adfs/ls/ will therefore happen successfully and the ADFS backend server will see the SAML Form data since that has not been dropped by AAA redirect.
9. Assuming the SAML Request ticket is valid, the ADFS server will give the user a SAML Response ticket and redirect the user to https://app1.somedomain.com/myApp and the user is now logged on to this 3rd party site successfully.

 

Takeaways:

  • Our workaround revolves around storing the original url (https://app1.somedomain.com/saml/login) in some way so we can access it later, and requesting a SAML Request ticket twice from our SAML SP because in the second round we will not be bothered by AAA authentication.
  • Above solution is a bit hacky and involves requesting double SAML tickets from the SP, and there are a lot of Redirects involved, but it works well from an end-user perspective and it enables us to support SAML Post in conjunction with AAA.

 

If you have any questions regarding above solution, or ideas on how to handle above scenario in a better way, please contact me at rasmus.kindberg@xenit.se.

 

 

Below is the Netscaler configuration:



Troubleshooting XenMobile

EMM systems are complex, error-prone and sensitive to changes from a lot of manufacturers, thus I’ll dedicate this post to just that: techniques for troubleshooting XenMobile. This is not a ”I have this problem, what could be the solution”-type post, but I’m rather going to outline some of the more useful tools that you can employ to help solve your problems.

XenMobile Analyzer

Easy to miss, but by far the easiest to use and among the more powerful troubleshooting tools. XM analyzer ”simulates” enrolling a device, authentication to both XenMobile and the NetScaler Gateway, browsing to internal URLs with Secure web as well as ShareFile SSO and Secure Mail Auto Discovery. When I’m setting up a new environment or troubleshoot an existing one, I usually start over here since it gives me a nice breakdown of which step fails as well as suggestions for possible fixes. One nice thing is that you can actually schedule reports to run at regular intervals, provided of course you allow enrolls without PIN.

XenMobile Analyzer results

XenMobile Analyzer is available at https://xmanalyzer.xm.citrix.com/ after logging in with your Citrix account.

XenMobile Connectivity Check

Available in the admin console, under Troubleshooting and Support > Diagnostics > XenMobile Connectivity Checks is this test. It is basically trying to reach other servers necessary for XenMobile to work, and allows you to see whether it works or not. It is a simple way to check if your internal firewalls are blocking something important:

XenMobile Connectivity Checks

 

Secure Mail Test Tool

If secure mail is what’s acting up for you, there is actually a dedicated test tool available to use. Much like the XenMobile Analyzer, it runs through a lot of tests and checks where it fails, but the Secure Mail Tool runs on your mobile device allowing you to see the other side of the equation. The only trouble with this tool is that you need to wrap it with the MDX tool in order to use it.

Secure Mail Test Tool

You can find more info about the test tool here: https://support.citrix.com/article/CTX141685

XenMobile Logs

Logs, of course, should hardly need to be mentioned. There are several layers of logs: Debug and User (and admin audit) logs on the appliance, iOS/Android logs on the devices as well as logs from Secure Hub. Make sure to use these to your advantage, and remember that you can change the log levels both when reporting a problem in Secure Hub as well as under Log Settings in the admin UI.

Browsing these logs, however, can be quite a daunting task. I usually start with only the appliance debug log, since you tend to get most of what you need from there. A good start with the debug log would be to check for exceptions, the first row usually gives you the information you need to fix it. Other than that you might need to search the logs for a username or something related to the problems (for example CSR if you’re having trouble enrolling client certificates). If you are able to reproduce the error, make sure you rotate the logs before you reproduce as that’ll leave you with a much shorter log to sift through.

NetScaler AAA log

Most implementations of XenMobile use NetScaler for load balancing and MAM Gateway, and of course a lot of problems could arise here as well. The most basic way to check the NetScaler is to see if it actually accepts your authentication.

To do this, logon to the NetScaler over CLI (PuTTY or other SSH client to the same hostname as the NetScalers, log on with your usual credentials) and run the commands below:

Now you can see the log live, if it’s a well used NetScaler this might be rather busy so you will have to start the logging just before you log on and then stop it afterwards. When you’ve done a logon you’ll get something similar to the image below:

NetScaler aaad.debug log

Here, the top (blurred) rows lists which AD groups the user is in, this is useful to see if the user is actually in that group you connected your delivery policy to. What you want to see is something like the ”sending accept to kernel” lines you can see on the screenshot. This means the user has authenticated to the NetScaler properly. Likewise a ”sending reject” means the user login was not accepted. If you’re lucky, maybe the user was inputting the wrong password all those times?

NetScaler Policy Hits

XenMobile depends heavily upon session policies for XenMobile to work properly, if these policies doesn’t ”hit” for the user you will most certainly see some problems. To check which policies hit when a user logs on, you can check the NetScaler CLI:

Run the commands and then let a user log on and you will get something like the output below.

NetScaler Policy Hits

Do note that this isn’t user specific, all hits occurring during your logging time will be present in the output so you will need to know what you are looking for. If you used the XenMobile Wizard to set up the NetScaler integration, the most important policy you’ll be looking for is the ”PL_OS_YOUR_NSGW_IP”-one i highlighted above, as it is the default name for the policy to apply on a log on from a mobile device. You can also see which LDAP policies apply, and if your certificate policies apply as expected.

 

 

 

 

Also, as a last, more specific tip. If your appliance is failing to boot, just looping on ”starting main app”, make sure that the database is available to the appliance. In my experience this is the problem almost every time.



Ny version av Imprivata OneSign

Xenits partner Imprivata har nyligen släppt version 5.2 av sitt marknadsledande system för Single Sign-On och användarautentisering, OneSign. Den nya versionen innehåller en rad förbättringar men även nya funktioner som kan förenkla vardagen för både IT-personal och slutanvändare.

Stöd för Microsoft Windows 10

Agenten som installeras på klienter stödjer nu officiellt Windows 10, vilket låter företag och organisationer att lämna allt mer åldrande uppsättningar baserat på tidigare versioner av Windows.

Stöd för Microsoft Remote Desktop Service

Utöver Citrix XenApp/XenDesktop och VMware Horizon finns det nu stöd även för Microsoft RDS, både som Remote App och som Remote PC. Alltså kan man nu även i en RDS-miljö få skrivbord och applikationer som automatiskt startar upp och följer med användare när de flyttar mellan arbetsstationer.

Självhantering av lösenord för användare

Tidigare har användare själv kunnat återställa sitt lösenord genom att ge svar på tidigare sparade frågor, mycket på samma sätt som när man glömt sitt lösenord på valfri webbsida. Nu har denna funktionalitet utökats med att även kunna visa vilka komplexitetskrav som gäller för nya lösenord samt möjlighet att låsa upp ett låst domänkonto.

Förbättrad licenshantering på tunna klienter

Tunna klienter som använder sig av Imprivata ProveID och Citrix Fast User Switching kan nu konfigureras så de istället för att starta en session automatiskt först väntar på en inloggning från användare. Detta gör att en oanvänd klient inte länge allokerar en Citrixlicens, utan att det sker först när den börjar användas.

Utökad Kerberos-integration

Integrationen med Kerberos har stärkts i denna version, vilket gör att ingen autentisering längre behöver gå via OneSign, utan att förtroende kan upprättas mot alla enheter som är betrodda av Kerberos.

Enrollment Utility

Det finns nu ett gränssnitt för slutanvändaren där de själva kan managera sina kopplade kort, fingeravtryck och sin PIN-kod utan att behöva blanda in support.

Utöver dessa finns en mängd mindre punkter, såsom stöd för fler kortläsare, starkare kryptering, mer flexibla intervall för synkronisering, stöd för Sophos Safeguard Enterprise 7, samt nya versioner av agenter och programvara från Citrix och VMware.

 

Xenit hjälper gärna till med både uppgraderingar och nyinstallationer av Imprivata OneSign. Vill ni ha mer information eller undrar någonting i övrigt, tveka inte att kontakta oss via e-post eller telefon. Läs även gärna vårt tidigare blogginlägg gällande Imprivata OneSign som ni finner här.

 



Nätverkshantering med open source-produkter

Det finns många produkter för att hantera de olika aspekterna av nätverket i företag. Eftersom jag från början kommer från en värld med bara open source och sedan gått över till Microsoft så var steget att hantera olika aspekter av nätverket med det naturligt.

Det hela började med en produkt och sedan en till, för att underlätta hanteringen. Idag har det blivit ett några fler och har standardiserat stora delar av det för att inte bara använda det hos oss själva utan även för att hjälpa kunder.

Grunden bygger jag på CentOS, nu för tiden version 7. För att hålla grunden så säker som möjligt och ha koll på att allt fungerar använder jag mig av clamav som antivirus, yum-cron för att automatiskt installera säkerhetsuppdateringar och automatiska omstarter en gång i veckan (med cron) för att säkerställa att allt fungerar om något skulle krascha, men även att få in senaste versionen av kernel om den installerats med yum-cron. Jag ser även till att använda SELinux och iptables, för att endast öppna upp det minsta möjliga mot omvärlden.

Några av de produkterna jag använder är:

  • Graylog. Förr i tiden använde vi syslog-ng och gick sedan över till att använda båda i kombination. Nu för tiden kör jag graylog rakt igenom, en helt fantastisk produkt för att samla ihop loggar från hela infrastrukturen. Jag använder den ihop med nxlog på Windows-maskiner för att få in data från Microsoft-infrastruktur och skapar grafer/varningar (streams) för olika typer av roller.
  • RANCiD. Tar backup av all nätverksutrustning (NetScaler, Cisco, HP, Palo Alto och Aruba i dagsläget) och sparar revisioner i GIT. Använder mig av scm-manager för att ha ett grafiskt gränssnitt där jag kan se backuperna och förändringar enkelt.
  • NetDisco. Skapar en överblick av nätverket och gör det enkelt att söka på MAC-adresser samt se vilka portar som är lediga i switcharna.

Framför dessa produkter kör används nginx med ett wildcard och publicerar dem den vägen. Alla webgränssnitt har AD-integration så vi kan använda oss av våra vanliga konton för att komma åt den information vi behöver.

Vi har ett annat verktyg för övervakning, men hade vi inte haft det hade antagligen nagios eller något liknande varit en bra kandidat. Kör även phpIPAM i en uppsättning för att ha kontroll på adresserna i nätverket.

Har du några tips på andra verktyg som skulle passa in med dessa eller några frågor om hur vi konfigurerat något? Lämna gärna en kommentar!