Forum Discussion

Mark_Cloutier's avatar
Mark_Cloutier
Icon for Nimbostratus rankNimbostratus
Jul 14, 2015

How to do an AD query sending UPN to AD, and have AD return the "short" name that I can use to authenticate against ldap with

LTM version 11.5.1 HF8

 

I currently have an APM access policy, deployed from Exchange iapp template version 1.4, which I modified to authenticate against LDAP, rather than direct to AD. User enters their short username, same as in AD, and after authenticating to LDAP I have an irule (thanks to my F5 SE!) that prepends the username with the domain for posting to Exchange. This works fine. Now however, I need to support Outlook Mobile, with Active Sync and autodiscover, which sends a user name that is the email address, aka the UPN in AD. I can't use that to authenticate in LDAP, so I need to take that UPN that would be in session.logon.last.username, send it to AD, and get the short name from AD, which I can then use to authenticate to LDAP with, and use the UPN to post to Exchange. As a side benefit, this would also allow Lync to retrieve Exchange info (meetings, saved chats, etc).

 

I'm assuming someone has already encountered and hopefully solved this....

 

APM
design
devops
iApps
microsoft
security

7 Replies

Sort By
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Jul 14, 2015

    Hi Mark, Walter is right, although we've found that the APM LDAP Query action works best for this. You need to set up a query against your AAA server where the search filter is (sAMAccountName=%{session.logon.last.username}) and the required attributes are distinguishedName, sAMAccountName, and userPrincipalName. The searchDN should be the base OU where the users are located.

     

    Then, you use a Variable Assign action to set the required variables:

     

    Variable: session.logon.last.domain

     

    Expression: expr { [string toupper [string map -nocase {,dc= .} [string range [mcget {session.ldap.last.attr.distinguishedName}] [expr [string first ",DC=" [mcget {session.ldap.last.attr.distinguishedName}] 0] +4] end ] ] ]}

     

    Variable: session.logon.last.username

     

    Expression: mcget {session.ldap.last.attr.sAMAccountName}

     

    • Mark_Cloutier's avatar
      Mark_Cloutier
      Icon for Nimbostratus rankNimbostratus
      Jul 14, 2015
      Just to confirm, the AAA server I run this LDAP query against has to be one of the AD servers right? The Oracle Access Manager LDAP server that I use for authentication doesn't know anything about UPN, hence the dilemma. Please be patient with an experienced LTM guy, who is very inexperienced with APM, LDAP and AD :) Mark
  • Joel_Dujsik_394's avatar
    Joel_Dujsik_394
    Historic F5 Account
    Jul 14, 2015
    Think of the objects in the Policy Editor separately, as basically like a flowchart. Each object (policy item) gets some session variables and/or sets some session variables, then evaluates the things in the "branch rules" tab. The session variables are the key. You can set them to whatever you like. Most Policy Items accept session variables as input using a format like %{session.mysessionvariable}. If you want to know what a session variable is set to at a particular point in the Access Policy, the easiest way to do it is to add a "Message Box" object and put your variables in there, like "My Username Is: %{session.logon.last.username}". Then the message will appear to the user. It also acts as a temporary stop, so you can run the Access Policy to the message box then use the sessiondump command to view all available variables while the user's session is sitting there. Branch rules are composed basically of TCL code. "mcget" is our command to retrieve session variable data. The TCL can be very simple like: expr { [mcget "session.logon.last.username"] contains "fred" } This would evaluate to True if the user's name (provided from a logon page usually) contained the string "fred". Or it can be much more complicated, using loops, conditional returns, etc. It's very flexible.
  • Mark_Cloutier's avatar
    Mark_Cloutier
    Icon for Nimbostratus rankNimbostratus
    Jul 16, 2015

    Progress! fumbling my way thru VPE, so now I understand the process of creating the variable assign action, and I have this working successfully using ldap over port 389 to my AD server. I am now attempting to get it to work using ldaps over 636... I followed the same process I used for converting my ldap auth server to ldaps, creating a new AAA server, using a pool, with one address, specifying ldaps, port 636, and then created the virtual server with a server ssl profile to do the encryption. I suspected a cert issue, so I went with the insecure-compatible ssl profile for testing, before I got into the process of getting the cert from our AD team and importing into the LTM. However that made no difference, APM still reports that it is unable to connect to the newly defined LDAP server. A tcpdump shows that the ldaps call goes out the external interface, gets to the AD server passes 2800 bytes of data, and the LTM then sends a Reset to close the connection.... Ideas?

     

  • Mark_Cloutier's avatar
    Mark_Cloutier
    Icon for Nimbostratus rankNimbostratus
    Jul 17, 2015

    problem was ldaps not being setup properly on our UAT AD servers, when I configured prod, it worked as advertised....