Import tool won't work with DOMAIN_LOCATION and NT40_ALIAS column headers

[bradwelch]

Hello,

It seems the Import tool won't work with DOMAIN_LOCATION and NT40_ALIAS column headers in the CSV file. From what I can gather, these two pieces of information will allow subscribers who are logged into a separate domain to be able to access AA without receiving the annoying login boxes. Each time I run the import tool with these two column headers, I receive a runtime error. The same import file minus these headers works fine. Does anybody know if this works?

Considering this is a VM only Unity installation and the users are logging into a separate domain than the Unity server domain, this would make it easier to access Active Assistant. Currently, users must supply login credentials twice when they access AA.

Thanks,

Brad

[bradwelch]

OK, after rebooting the Unity server, the CSV file took. However, the was an error during the import process:

NOTES,NOTES,"FIRST_NAME","LAST_NAME","DTMF_ACCESS_ID","ALIAS","DOMAIN_LOCATION","NT40_ALIAS"

Created Unity account. Unable to update SID history field.,Error Column:0,

Testing,Account,8889,testing,phx-dc,mllamber

It seems the Unity server is trying to contact the DC for the other domain to pull the SID for the supplied alias. Currently, both domains are running AD with their own W2000 DNS. I think the DNS running on the Unity server needs to be updated with a service record for the other domain's DC. Does this make sense?

Thanks,

Brad

[lindborg]

Unsure where you heard that using these two columns for importing users would somehow remove the need for users having to provide login credentials when coming cross domain, but that is not the case. Those columns are for situations where a user has both a Win2K and an NT 4.0 account (i.e. hairy migration scenarios some larger companies use). It doesn't have anything to do with having to authenticate if you're coming from another domain than the one Unity is installed in. If you're users are coming from another domain, they will always have to authenticate at least once (twice if they're coming from an untrusted domain).

With NTLM authentication there is absolutely nothing we can do to prevent this... this is not a Unity related issue (although folks complain to me that Unity needs to be "fixed" for this issue all the time).

Our SA/AA pages require you to have a security token valid in our domain before accessing the web pages (i.e. we don't allow anonymous or clear text access for obvious security reasons). If you're coming from an untrusted domain you'll get hit with a CHAPs login dialog (this is issued by IIS/IE, Unity isn't even in the picture at this point). If the domain is trusted then you proceed through without a login dialog. However, as soon as you hit a web page that contains a media master control (an ActiveX control that uses DCOM to connect to Unity) it'll hit you for a login no matter what you do - trusted domain or not - because DCOM can't use the security token in this case, it needs it's own. Once it has it's token it's good for the rest of that session (i.e. you don't need to continue to log in every time you hit a page with the media master control on it).

Yes, I know this is deeply annoying to some folks. Unity 4.0 will offer an alternative to NTLM that prevents you having to authenticate coming cross domain (it doesn't care about domains in fact). It'll require you setup SSL and a CA to use it safely but you'll have the option of using this instead of NTLM. Until then if you have Unit y and you're users in a seperate domain, you will have to login at least once every time you access the AA.