1 Reply Latest reply on Jul 7, 2017 2:46 AM by michael.odriscoll

    Workspace token authentication

    bezkarl Apprentice

      Hi,

       

      I am in process of testing Workspaces for possible future implementation.

       

      I have successfully configured token login following Step by Step: How to configure Workspaces(BridgeIT) to logon with Token Only policy . A selection of test users can login with their sAMAccountName, and the network login on their accounts is set to domain\sAMAccountName.

       

      However, for the majority of existing users of Self-service and Webdesk the network login is set as the object Distinguished Name (DN) so for any Workspace implementation I would need to change this to domain\sAMAccountName. This could be probably be done by a database script as one-off change, but for future imports I will need amending the import mapping. I understand you can have more than one network login set so in my initial attempts I have set a spare Active Directory extensionattribute to domain\sAMAccountName and mapped to Network Login:

       

      The result of this is that the it appends the new mapping to the end of object Distinguished Name for a new network login which is undesired. If I add the sAMAccountName as an additional mapping it correctly imports this as a new login. Is the difference in behaviour due the extensionattributes being different in some way?

       

      My understanding of IIS Windows authentication in this token only configuration is that it prefixes the domain to the sAMAccountName, which is why the network login needs to be domain\sAMAccountName in Service Desk for the user lookup to match. Does anyone know if it is possible to stop IIS prefixing the domain?

       

      Has anyone had similar issues trying to configure Workspace authentication?

       

      Kind regards,

       

      Karl