Build ADFS lab to evaluate the result of claim rule transformation

Sounds like there is not a good utility or log which can tell the claim rule transformation result in ADFS. I followed the instruction in "How to Build Your ADFS Lab on Server 2012, Part2: Web SSO" and built my own lab in which I use DualShield as SAML IDP. Please read the details in this link, and see how to test the result of claim rule transformation in an example "Integrate DualShield with UltiPro"

Integrate DualShield with UltiPro

Ultipro utilizes ADFS2 to accept SAML from IdP, and it requires UPN as one of the issued identities. Please read the details in this link.

SAML Authentication on F5 Big-IP (Part 5)

It is time to have a conclusion on this subject.

F5 support team finally lost interest, they didn't reply my question any more, because I was only a trial user I think. I had to put this issue aside for weeks.

Once I thought I had insightful understanding on SAML, especially the XML signature, I decided to review this issue again by myself.

When my eyes rested on the attribute WantAssertionsSigned in F5 BigIP metadata,

I immediately realized I got the answer! IDP sent a SAML response which signed the signature on the whole response, however F5 BigIP appliance specified to expect the signature on assertion part of the response.

After modifying the response (calculate the signature to assertion part), it worked!

I blushed with embarrassment at that time, as SAML authentication on F5 BigIP did work (at least it accepted signature on assertion, not sure it accepts the signature on response). However F5 error message "Digest of SignedInfo mismatch" puzzled everyone.

If we look at the response again, now it is very obvious that the signature was on Response (instead of Assertion, just compare the value of Reference URI with the _IDs)!

Silly me! but could F5 error message become more intuitive?

Password Pass-over In NetScaler

NetScaler supports SAML authentication, and you can pass over the username from IDP to NetScaler through SAML response (see the details in this link). This is very useful when you want to single sign on XenApp, it will pre-fill the username field in CWI login.

Ideally it would be perfect if we could pass over the password as well.

Citrix mentioned the SAML response generated by NetScaler Gateway virtual server could contain password. The vpn SAML profile can have a parameter called "sendpassword". Please see the details in How to Configure SAML SSO Authentication between NetScaler Gateway and Load Balancing Virtual Servers. It implies NetScaler supports the password pass-over, internally at least.

I was very curious if the third-party IDP could take the advantage, so I dug into NetScaler module.

The SAML response generated by NetScaler itself contains password attribute.

<saml2:Attribute Name="password" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:type="xs:string">the encrypted password</saml2:AttributeValue></saml2:Attribute>

How is the password encrypted? If the third-party IDP follows the rule, it may be able to pass over the password!

The password is actually scrambled by vpn_global_key, which is initialized randomly during system boots up.

ns_sslvpn_copy_passwd(char* srcpass, char* dstpass, unsigned int len)

{

for (int  i = 0; i < len; ++i )

dstpass[i] = srcpass[i] ^ vpn_global_key[i];

}

In ns_aaa_saml_auth, the password (if it exists) is restored.

if ( (unsigned int)(len - 1) <= 0x7E )

{

ns_sslvpn_copy_passwd(src, dst, len);

}

Unfortunately, I don't think there is a way to transmit the vpn_global_key over SAML Request which is the only way the IDP get the information from NetScaler, so my conclusion is, currently it is impossible for the third-party IDP to pass over a valid password value to NetScaler.

MSI Major Upgrade by Wix

Wix provides an element MajorUpgrade to make a major upgrade a little bit easier, You still need to pay a lot of attention on the sequence and conditions on custom actions, if you have any.

In MSI, upgrade actually contains two parts: uninstall and install. Which one is done first. it is decided by the attribute Schedule. For instance, if Schedule = afterInstallValidate, this scheduling removes the installed product entirely before installing the upgrade product. While Schedule = afterInstallExecute, it installs the upgrade product "on top of" the installed product then lets RemoveExistingProducts uninstall any components that don't also exist in the upgrade product.

If you have any custom action, for example, retain data file during upgrade, register and start service after installation, stop service and unregister service before uninstallation, inevitably you want to utilize some built-in properties like “Installed”, “UPGRADINGPRODUCTCODE”, “REMOVE”,“REINSTALL”. On StackOverflow, there is a good summary which I copied it here.

As I pointed out earlier, an upgrade consists of two phases, you may wonder, are these property values are same in two phases? Unfortunately, the listed values under “Upgrade” actually apply to the uninstall phase of upgrade. The install phase of upgrade has same values on this properties as a new install, which means you can’t tell the difference with these properties between a new install and the install part of upgrade. I would suggest you writing a vbscript type custom action to check something else directly.

Assume you have installed a product with version1.msi, now you are going to upgrade it with version2.msi. Remember, the install part of upgrade will use version2.msi, but the uninstall part of upgrade will use version1.msi which was saved somewhere when you first installed it.

Read more...

Lync Lab in ESXi

Recently I set up an on-premises Lync server lab with ESXi. Something learned from the experiment are.

• Before installation, carefully read Microsoft Lync Server 2013 Protocol Workloads Poster. Apart from the network diagram, also try to fully understand the DNS Configuration and Certificate Requirements.
• SIP domain can be different from AD domain. In my example, AD domain = nanoart.local, but SIP domain = nanoart.co.uk.

• The server certificate for Lync Edge server external NIC must have CRL Distribution Points . If using my OpenSSL shell script in previous blog, enable the line,

crlDistributionPoints = URI:https://$CN/crlempty.crl

You need a physical machine as ESXi host, install 5 VMs. 1: Domain Controller, 2: Lync 2013 Standard Server Edition, 3: Lync 2013 Edge server, 4: TMG 2010, 5: DNS server.

Apart from it, you also need a desktop test machine, one wireless AP and a mobile phone.

Here is my lab's network diagram.

This is the external DNS configuration.

Read more at ....

Cisco ACS 5.4 in ESXi

There are some tutorials on Internet which teach you how to apply the cracked licenses onto ACS 5.2. I found they are still valid for ACS 5.4. The procedure is quite same apart from that you need to remove GRUB password protection in ACS 5.4.

Read more at the link.

OpenSSL to generate certificate in single shell script

Are you looking for a Linux shell script which can generate a certificate? Ideally, you only need to give a parameter, for web site certificate, which is its FQDN. You don't care other information, and you are fed up with the interaction which asks you input Country, Organization etc. In that case, here it is.

I use certificates quite a lot. Recently I was asked to set up Microsoft Lync server(s). The certificates on Lync Reverse Proxy and Lync Edge server must have SANs (subject alternative name). It drove me to write such a shell script.

You are encouraged to change the configuration part in the shell script, for instance, key length (2048 by default), key password (PFX password, = "changeit"), how long the generated certificate will be valid(10 years)?

You can run this script without any parameter to see its usage

# ./certgen.sh
Usage:
  certgen ca
  certgen client
  certgen server []

First of all, you need to create CA certificate. Just run "certgen ca", it will create two files, cacert.crt and cakey.pem. Back up these two files, you are going to use this CA to sign the server/client certificates afterwards.

Now you can generate a server certificate, for instance, run the following command,

./certgen.sh server fruit.myorchard.local DNS:apple.myorchard.local,DNS:cherry.myorchard.local

You are expected to see the result

Generating ca_config.cnf
generating server cert for:fruit.myorchard.local
Generating a 2048 bit RSA private key
.........................................................+++
.....................................................................................................................................................................................................................+++
writing new private key to 'fruit.myorchard.local.key'
-----
Using configuration from ca_config.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 4 (0x4)
        Validity
            Not Before: Mar 12 11:44:40 2014 GMT
            Not After : Mar  9 11:44:40 2024 GMT
        Subject:
            countryName               = GB
            stateOrProvinceName       = BUCKS
            localityName              = LONDON
            organizationName          = YOURCOMPANY.COM
            organizationalUnitName    = R&D
            commonName                = fruit.myorchard.local
            emailAddress              = support@yourcompany.com
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage:
                Digital Signature, Key Encipherment, Data Encipherment
            X509v3 Subject Alternative Name:
                DNS:fruit.myorchard.local, DNS:apple.myorchard.local, DNS:cherry.myorchard.local
Certificate is to be certified until Mar  9 11:44:40 2024 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated
Generated files: key: fruit.myorchard.local.key , cert: fruit.myorchard.local.crt

If you see "failed to update database TXT_DB error number 2", it is very likely you have already generated the certificate with the same FQDN. You need to edit the index.txt file to remove the related entry.

See more at this link.

Reference

Generating Self-Signed Test Certificates Using One Single Shell Script 

Encode/Decode Citrix Password in NFuseProtocol

In Citrix NFuseProtocol, password is encoded, not the one you typed. If you capture the traffic between Citrix  Receiver and PNAgent (Now it is called XenApp Service) web site, you will see the typical post data.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"><NFuseProtocol version="4.6">
    <RequestReconnectSessionData>
        <Credentials>
            <UserName>administrator</UserName>
            <Password encoding="ctx1">NFHALEBBMHGCLEBBMDGGKMAJNOHLLKBP</Password>
            <Domain type="NT">CONTOSO</Domain>
        </Credentials>
        <ClientName>REMLAPTOP</ClientName>
        <ClientName>REMLAPTOP</ClientName>
        <ServerType>win32</ServerType>
        <ClientType>ica30</ClientType>
        <SessionType>disconnected</SessionType>
        <SessionType>active</SessionType>
    </RequestReconnectSessionData>
</NFuseProtocol>


Ever wonder what is the original password of the encoded one "NFHALEBBMHGCLEBBMDGGKMAJNOHLLKBP"?

Here is the tool you can try.

For encode, do

citrixpassword.exe encode "password"

It will output the result

hash password = NFHALEBBMHGCLEBBMDGGKMAJNOHLLKBP .

For decode, do

citrixpassword.exe decode NFHALEBBMHGCLEBBMDGGKMAJNOHLLKBP

The result will be,

original password = password .

Don't ask me to publish the source code, I think it is not wise to do that. However the algorithm is very simple, just some XOR operations. You can work it out easily by disassembling my tool.


Reference

Encoding and Decoding Citrix Passwords

Mac OSX Authorization Rights and Rules.

Before Mavericks (OSX 10.9),  right and rule are separated in authorization database, which is the file /etc/authorization.

The API AuthorizationRightGet/Set/Remove can only operate on rights. If you want to manipulate the rules, you have to modify the file  /etc/authorization  directly.

On Mavericks, the file is deprecated.  Apple’s engineers have chosen to mix rights and rules in this single table. Now the API can operate on the rule as well as on the right. The security binary (the command security authorizationdb read/write ) also succeeds on read/write rules.

It is an improvement, although now I can't easily tell which is right, which is rule.

Read more...

References

Authbuddy

Authorization Rights and Mavericks

Modifying the OS X Mavericks Authorization Database