Muting the camera shutter in the Iphone 7

April 9, 2017

It appears that it is illegal to turn off the shutter when you take a picture using a digital phone in the US; I have read that the law states that cell phones containing digital cameras must make a sound when taking a picture (need validation) but there are two easy ways to minimize the annoyance of the shutter:

  1. Put your phone in Mute
  2. Lower the volume to the lowest possible settings

There you have it!

 

Some components of the Logon process in RDS/Citrix environments

January 30, 2017

smss.exe – Session Manager subsystem – As the name suggests, this process is in charge of  managing the session creation and logoff

Winlogon – “Winlogon handles interface functions that are independent of authentication policy. It creates the desktops for the window station, implements time-out operations, and provides a set of support functions for the GINA.” source: Microsoft MSDN

userinit.exe ( HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ): it specifies the programs that Winlogon runs when a user logs on. (https://technet.microsoft.com/en-us/library/cc939862.aspx)

mpnotify.exe ( C:\WINDOWS\system32\mpnotify.exe ): is responsible for loading network providers including the single sign on network provider (pnsson.dll) for the ICA client.

These are not the only processes invoked during logon process.

 

Read the rest of this entry »

The three types of caches used by IE 10 and IE 11 on Windows 8 and later and Saved Passwords in IE

January 7, 2017

IE 10 and 11 have thre types of cache to be aware:

#1 AppData\Local\Microsoft\Windows\INetCache (temporary Internet files)

#2 AppData\Local\Microsoft\Windows\WebCache (IE browser cache)

# 3 Password folders

#1 The Temporary Internet Files for Windows 8 and later are located here:

AppData\Local\Microsoft\Windows\INetCache

This folder contains all the temporary Internet files from Microsoft Windows computers. It  contains files – such as images, HTML pages, executable and script files – that Internet Explorer has downloaded from websites visited by the user.

#2 The WebCache is located here: AppData\Local\Microsoft\Windows\WebCache

It contains the browser cache history and it can grow in size very rapidly

To delete the cache history you can use the Ctrl-Shift-Delete to open the browsing history window

For a complete list of items in the cache check this Microsoft  article.

#3 Password folders –  Internet Explorer contains folders related to Saved passwords

These are the folders for the passwords:

AppData\Local\Microsoft\Credentials
Appdata\Roaming\Microsoft\Credentials
Appdata\Roaming\Microsoft\Crypto
Appdata\Roaming\Microsoft\Protect
Appdata\Roaming\Microsoft\SystemCertificates

Licensing Diagnosis in 2012 R2

January 7, 2017

Unlike 2008 R@ RDS servers where the RDS Session Host Configuration contains the Licensing diagnosis screen, on 2012 R2 RDs servers , in order to check RDS licenses you need to issue this command:

%windir%\system32\lsdiag.msc

 

source: Citrix article

Deleting the WebCache database – The IE browser cache

January 7, 2017

How to delete the webcache file:

Read this blog for a clever way of deleting the webcache file Database, the WebCacheV01.dat file located in the %LocalAppData%\Microsoft\Windows\WebCache\ folder

Create a batch file and paste the content below

echo OFF

net stop COMSysApp

taskkill /F /IM dllhost.exe

taskkill /F /IM taskhost.exe

taskkill /F /IM taskhostex.exe

del /Q %LocalAppData%\Microsoft\Windows\WebCache\*.*

net start COMSysApp

echo ON

Save the batchfile as “ClearIECache.cmd” and add it to the logoff script

Side note: The AppData\Local\Microsoft\Windows\INetCache is where the IE temporary files are located

 

Reason: Read on:

 

“…Starting with IE10, IE moves the browser cache to a Jet Blue database(also known as ESC database or .edb file), and the old index.dat memory-mapped file is obsoleted. You may read this blog to learn the benefits of this change, this is not the key topic in our article. With the new cache implementation, the cache files are saved in %LocalAppData%\Microsoft\Windows\WebCache\ folder. And, the cache files will be created when a new user logs on.

Actually, the database is a file named WebCacheV01.dat in the cache folder, and its initial size could be around 20-32MB. The size of this file will keep increasing along with you browse more and more websites. Unfortunately, there’s no way to control the initial size of this database, in another word, the minimal size of this file could be >20MB. Now, let’s suppose there are 1000+ users for this terminal server, then totally >20,000MB space is required for every user’s cache database file at least. In this situation, your C drive space will be probably used up as time goes on.

Then, how to avoid the happening of the subjected issue? Maybe you are thinking about deleting the cache files, right? Exactly, this is the only way to resolve the issue. However, the problem is, you are unable to delete the cache files manually even you are a local admin of this server. Don’t worry, here’s a batch file which can help to delete the cache files. Please save the below contents into ClearIECache.cmd file and try to fun this file.” 

source: AsiaTech: Microsoft APGC Internet Developer Support Team

The Boot Time components of a PVS server

December 27, 2016

Boot time is when you Turn on the target device up to the point where it downloads the bootstrap file. The bootstrap file contains the BOOTSTRAP PROGRAM

But what is a BOOTSTRAP PROGRAM?

A target device initiates the boot process by first loading a bootstrap program. A bootstrap program is a small program that runs before the operating system is loaded. Provisioning Services uses a special bootstrap program that initializes the streaming session between the target device and the Provisioning Server. After this session starts, the operating system begins to be streamed and loaded from the vDisk that was initiated.

There are three ways that a target device may load the bootstrap program.

  • Over the network, via Preboot eXecution Environment (PXE)
  • From a boot device stored on attached media
  • From a BIOS Embedded bootstrap (OEM versions only)

Source: Citrix DOCS – BootStrap Program

BOOT TIME COMPONENTS

TFTP

PXE

TSB

TFTP Explanation:

TFTP Service is a basic TFTP you can see anywhere else – Just sits there with the boot strap file, waits for someone/somebody to request it . When somebody (usually a target device) requests it, it uses the TFTP protocol to deliver the bootstrap file

Now, in order to get the bootstrap file when you perform a PXE booting, you need two pieces of information

  1. The IP Address of the Server or [Server name]
  2. The name of the bootstrap file [filename of the bootstrap file

So in order to do a Network boot via PXE, those two pieces of information have to be provided for, to accomplish that

There a couple ways of doing that:

  1. Using Option 66/67 in your DHCP server. So when you use option 66/67:
    1. a target with PXE enabled, boots up
    2. It will send out a DHCP discover packet
    3. DHCP will respond to that discover packet with the offer that can contain all the normal DHCP information (IP, subnet mask, gateway, DNS, domain, but in addition to that information, it will also provide the IP address and the filename for the boot strap. It will then, with that information in hand go to the TFTP server and download the bootstrap file
  2. Using PXE

PXE explanation

Q. So, do you know what PXE service is used for?

A. It replaces Option 66 and 67

So, in a environment where you don’t want to use Option 66 and 67, you can enable the PXE Service in all your PVS servers. What happens here is the target boots up, and does a DHCP discovery (It will send out a DHCP discovery packet)

PXE services listens on port 67 which is the same port that DHCP listens on. So that discovery goes out and hits the DHCP server and will hit all PXE Services. DHCP will respond with the basic  DHCP information (IP, subnet mask, gateway, DNS, domain). It will NOT have in this case (since it was not configured) the option 66 and 67. However, all the PXE servers will respond with the IP of themselves and the boot strap file name. So when you use PXE services you use both PXE service and TFTP on the same server. The way this works i: if you have multiple PXE services, the first one that gets received by the target devices is the one being used; it  will contact the TFTP server and download the bootstrap

 

More to come:

TSB explanation:

Q.

A.

Using ADSI Edit to validate an object SID such as an user or a computer

December 4, 2016

Scenario

Let’s say you found an object SID but need to validate if that object SID is related to a AD component  Canonical Name (CN) . Example: Domain users have a object SID attribute like:

S-1-5-21-3292383464-3806668890-3618075406-513

Using “ADSI Edit” on your Domain Controller, you can check if the object “Domain Users” have a object SID that matches the attribute above. Note that the “Object SID” and “Object GUID” are not the same thing and don’t have the same numbers, but they are listed next to each other in the attributes table of the object “Domain Users” in the ADSI Edit snap-in console

But in order to use ADSI Edit, you need to register the DLL first by typing on a command prompt:

regsvr32 adsiedit.dll 
Ideally you want to be on the same folder or the DLL is located. Normally if you download
the Support Tools, this is already done for you. But, if not, you need to make sure this
command works properly so you can register the DLL and start the ADSI EDIT snap-in)

On the Domain controller or on the server where you have access to AD Users and Computers, 
after registering the DLL you can start:

Using the ADSI Edit

ADSI Edit (Adsiedit.msc) is an MMC snap-in. You can add the snap-in to any .msc file through the Add/Remove Snap-in menu option in MMC, or just open the Adsiedit.msc file from Windows Explorer. The following figure illustrates the ADSI Edit interface. In the console tree on the left, you can see the major partitions Domain, Configuration, and Schema.

So by typing ADSIEDT.msc on a elevated command prompt you should be able to launch the snap-in

Right click and select Connect to… and take the default value to load the “Default Naming Context”

Something like this: LDAP://DC1.[domain name]/Default naming context where DC1 is the hostname of  the Domain controller

In the Advanced button you can specify the Port Number. When using ADSI Edit Type a port number if you do not want to use the default port for the LDAP or the LDAP Global Catalog protocol. The default LDAP port is 389. The default port for the Global Catalog is 3268.

Review this Microsoft Technet article on ADSI Edit for detailed information on the use of the tool

In my case I  expanded the Domain Name of my domain and expanded the CN=Users folder and located the “Domain Users” object and right click on it and selected the option “Properties”

One of the attributes listed was the object SID. I was able to validate that the object SID I found earlier matched the object SID of the object “Domain Users”

 

Unable to RDP to a 2012 R2 server

December 4, 2016

I have a Citrix Delivery Controller (DDC) and a Server VDA (SVDA)  in my lab, as part of my XenApp 7.11 environment. Both servers are 2012 R2 servers. I have Terminal Services role enabled by default on my SVDA because when you install Citrix software (Virtual deliver Agent or VDA) on a Server 2008 R2 or 2012 R2, the Terminal Services (TS) role is automatically installed, since it is a pre-requisite for the VDA. The DDC doesn’t have the Terminal Services Role installed by default (unless you install the VDA software on it, which is not considered Best Practices by Citrix), but Microsoft allows two RDP connections to a Server even if the Terminal Services role is not installed. Of course it is limited to local or domain administrators. One of the reasons this is possible is to allow either the local admin or the domain admin to install the full blown Terminal Services role if needed. Recently, I have been unable to RDP into the  DDC but had no problems RDP-“ing” to my SVDA.

After checking firewal settings and making sure they were disabled, I tried tel-netting via port 3389 from my SVDA to my DDC and was unable to do so. However, I was  able to telnet from another server to my SVDA via port 3389. So I suspected that my RDP listener on the DDC had an issue.

Sure enough, I compared the RDP listener registry key settings between the SVDA and the DDC. On my DDC there were a few binary values that did not match my SVDA. Obviously some of the values should be different since one server has the TS role installed (SVDA) and the other (DDC) doesn’t, but the vast majority of the binary values on the RDP listener registry  key should be quite similar on both 2012 R2 servers. The registry key for the RDP listener is located here:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

These two keys particularly intrigued me:

fDisableExe -> set to 1 on the working SVDA but set to 0 (zero) on the non-working DDC

User Authentication – set to 1 on the working SVDA but set to 0 (Zero) on the non-working DDC

Solution:

I changed both flags to 1 on the non-working DDC, to mimic the SVDA and VOILÁ, the RDP connection started to work again, MAGICALLY!

Note 1: After changing the two binary values on the registry, I rebooted the DDC for the changes to take effect.

Note 2: I did not test the behavior by only changing one binary value entry due to my own laziness, so it is quite possible that only one binary value change could have done the trick as well. If I were to guess I suspect the User authentication binary value could be the one, but that is only my guess!

Conclusion:

Microsoft installs the RDP listener on all Windows machines by default when the Windows software is installed on a computer. This is for management purposes in case you want to manage the computer remotely.

So you should be able to see RDP listener registry key on all  Windows computers regardless of being a Server or Desktop OS. The RDP listener is not a very popular component and most end users don’t really know much about this component or that it even exists (unless you are an IT administrator). However, when corrupted, modified or customized , it will cause disruptions to a remote connection to the computer, like the disruption I had, so beware!

The only mysteries I did not solve was

  1. How the binary values changed on the DDC (since I’ve never touched that registry key myself before)?, or
  2. If it did not change (which is quite possible as well) what triggered the issue then? and
  3. What roles do those two binary values (User Authentication andfDisableExe)  have?
  4. Why did I decide to choose those two binary values since there were other values that also did not match. Was it my gut, my instinct? or pure luck? or would any value change do it?

These are all answers to be discussed and hypothesis that could be tested and discussed on another blog article . If you know the answer please share!

Additional Tip:

This is a good command to test if the RDP protocol is listening on port 3389, the default RDP port:

Telnet [hostname or ip address or FQDN] 3389 – If you get as an answer the cursor blinking on the top left of the CMD prompt screen, that is a good thing. That means the connection to that computer via RDP is enabled and the RDP protocol is listening on that port. If you get an message: “Connecting to [hostname]…could not open connection to the host, on port 3389: Connect failed” it really means that port 3389 is not opened on the destination host name

During my troubleshooting, telnetting within the server itself  it worked (telnet localhost 3389) but it failed from any other computer telnetting into the DDC

Some IT shops change the default port of RDP from 3389 to another number to prevent  end users from accessing the computer remotely or to prevent intrusions

I hope this helps!

JP

*** === ***

side note:definition of voilá

used when something is being presented or shown to someone

SpeedScreenLatency Reduction Manager Client Side

November 18, 2016

Speed Screen Latency Reduction Manager (SLR) 101:

Make sure to read this full article from  BrianMadden article which has a great explanation of SLR. I pasted most of it further below under “Read More”

The important thing to remember is that Citrix Receiver (latest version 4.5 as of November 18th 2016) has a setting in its ADM tempate that enables SLR at the client level: It is kind of hidden under the “User Experience” – “Client Graphics settings”

keyboard-local-echo-and-mouser-poniter-prediction

Try enabling it a the end point device in case your end users are running Cirtix session on a slow connection remotely

Read the rest of this entry »

SSL and TLS under Citrix

November 13, 2016

 

In  Citrix  environments the theme security is always considered a top priority. As a matter in fact one of the mottos of the company is “We securely Deliver application and data”

Citrix flagship product: XenApp/XenDesktop focuses on delivering applications and desktops securely as this white paper suggests:

“XenApp keeps sensitive corporate information protected in the data center, but employees still need secure access to the XenApp infrastructure. Applications published using XenApp are accessible through Citrix Receiver™—a lightweight client that can be installed on any type of device,”

Citrix has two backend software packages to handle web authentication: Web Interface (5.4 was the latest and last version available) and StoreFront (3.7 is the latest version as of November 2016)

Question:
Web Interface 5.4 — – Is TLS 1.2, 1.1 supported?

“Answer:
No it’s not. Upgrade to StoreFront 3.x.
On page 173 of the product documentation guide for Web Interface 5.4 you will find the following paragraph:

” Transport Layer Security –
Transport Layer Security (TLS) is the latest, standardized version of the SSL protocol. The
Internet Engineering Taskforce (IETF) renamed it TLS when they took over responsibility for
the development of SSL as an open standard. Like SSL, TLS provides server authentication,
encryption of the data stream, and message integrity checks.
Support for TLS Version 1.0 is included in all supported versions of XenApp for Windows and
XenDesktop. Because there are only minor technical differences between SSL Version 3.0
and TLS Version 1.0, the server certificates you use for SSL in your installation also work
with TLS.
Some organizations, including U.S. government organizations, require the use of TLS to
secure data communications. These organizations may also require the use of validated
cryptography, such as Federal Information Processing Standard (FIPS) 140. FIPS is a standard
for cryptography.
Note: The maximum SSL/TLS certificate key size supported by the Web Interface for Java
Application Servers is 2048 bits.”

Here TLS 1.2 or 1.1 is nowhere mentioned, hence upgrade is highly recommended.
Also since WI 5.4 was designed in C# and support for C# has ended by Microsoft nearly two years ago any enhancement request will not be possible

The Wikipedia explanation:

“Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as “SSL”, are cryptographic protocols that provide communications security over a computer network.[1]Several versions of the protocols find widespread use in applications such as web browsing, email, Internet faxing, instant messaging, and voice-over-IP (VoIP). Websites use TLS to secure all communications between their servers and web browsers.”

Why using TLS and not SSL:

The TLS (Transport Layer Security) protocol has superseded SSL. Although many products support both SSL and TLS, and the term “SSL” is often used to describe both, the difference between SSL and TLS is crucial. Use TLS. SSL is no longer secure.

Cryptography in the TLS protocol:

Cryptography in the TLS protocol is selected by a TLS cipher suite, which is negotiated between the client and server. This defines the cryptographic algorithms that are used for the connection.

Cipher suites are named in the form TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. This can be interpreted as follows:

• TLS is the protocol (Transport Layer Security)

• ECDHE_RSA is the key exchange algorithm (Elliptic Curve Diffe-Hellman)

• AES_256_CBC is the cipher (Advanced Encryption Standard, Cipher Block Chaining)

• SHA384 is the (MAC) message authentication code (Secure Hash Algorithm)

Examining the key exchange algorithm, ECDHE indicates that this cipher suite offers forward security. RSA indicates that a RSA digital certifcate must be used.

Examining the cipher, AES_256_CBC indicates that this cipher suite uses a 256-bit key in CBC mode.

Examining the MAC, SHA384 indicates that this cipher suite uses the HMAC-SHA386 algorithm.

The cipher suite does not identify the version of the TLS protocol and many cipher suites are common to different TLS versions. Note: The naming scheme above is the one from the TLS standards. Some implementations, including OpenSSL and Citrix NetScaler, use a slightly different naming scheme for historical reasons. (For example, TLS1.2-ECDHE-RSA-AES-256-CBC-SHA384 corresponds to TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.)

Strong and weak cipher suites

In this context, a weak cipher suite is one that can be attacked successfully now or projected in the next few years. (An attack may be diffcult, but is at least possible.) Advances in technology, tools and techniques may weaken ciphers well before their initially projected lifespan and the known strength of ciphers should be periodically verifed through NIST and other trusted sources.

Cipher suites containing the following algorithms are generally considered weak:

• DES (although 3DES—also known as TripleDES or TDEA—is not generally considered weak)

• RC2

• RC4

Additionally, the so-called ‘export’ or ‘step-down’ cipher suites are weak. These cipher suites limit the length of the signing key to 512 bits, which can be broken by brute force. These weak ‘export’ cipher suites were devised to satisfy export considerations that have not applied for many years. Strong cipher suites can and should be used instead.

Hashing algorithms including the SHA1 and MD5 are also considered weak for signatures in digital certifcates, with SHA-256 being specifed as the minimum standard. The usage of previous algorithms is so weak that public certifcate authorities will no longer issue certifcates that use them. Digital certifcates using MD5 or SHA1 should be replaced. Some platforms, including Microsoft Windows, are already preventing their use.

In summary, for TLS today, the following are considered weak:

algorithm

source: Citrix White Paper on SSL and TLS

Preferred cipher suites AES is a block cipher: every block cipher is used in a particular mode of operation. Three of these modes have been standardized within TLS, as part of the cipher defnition: • AES-CBC (Cipher Block Chaining) • AES-CCM (Counter with Cipher Block Chaining-Message Authentication Code). This mode is rarely used. • AES-GCM (Galois Counter Mode) The CBC mode is more widely supported than GCM, including in TLS version 1.0 and version 1.1. The GCM mode is often preferred to CBC mode, because: • It is higher-performance • It is resistant to side-channel attacks, specifcally padding oracle attacks such as Lucky Thirteen. (However, such attacks against CBC mode can be mitigated in other ways.) • It is resistant to adaptive plaintext attacks, specifcally the BEAST (Browser Exploit Against SSL/TLS) attack. (Again, this attack against CBC mode is mitigated in version TLS 1.1 or in other ways.) Some authorities prefer GCM: others nevertheless still prefer CBC

SSL/TLs in XenApp 7.x:

SSL 7.6:

“Configuring a XenApp or XenDesktop Site to use the Secure Sockets Layer (SSL) security protocol includes the following procedures:

  • Obtain, install, and register a server certificate on all Delivery Controllers, and configure a port with the SSL certificate. For details, see Install SSL server certificates on Controllers.

    Optionally, you can change the ports the Controller uses to listen for HTTP and HTTPS traffic.

  • Enable SSL connections between users and Virtual Delivery Agents (VDAs) by completing the following tasks:
    Requirements and considerations:

    • Enabling SSL connections between users and VDAs is valid only for XenApp 7.6 and XenDesktop 7.6 Sites, plus later supported releases.
    • Configure SSL in the Delivery Groups and on the VDAs after you install components, create a Site, create Machine Catalogs, and create Delivery Groups.
    • To configure SSL in the Delivery Groups, you must have permission to change Controller access rules; a Full Administrator has this permission.
    • To configure SSL on the VDAs, you must be a Windows administrator on the machine where the VDA is installed.
    • If you intend to configure SSL on VDAs that have been upgraded from earlier versions, uninstall any SSL relay software on those machines before upgrading them.
    • The PowerShell script configures SSL on static VDAs; it does not configure SSL on pooled VDAs that are provisioned by Machine Creation Services or Provisioning Services, where the machine image resets on each restart.

For tasks that include working in the Windows registry:

Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.”