NTLM Question

We have 'Send NTLM response only" set on all domain controllers (Windows 2008) and "Send NTLMv2 response only. Refuse NTLM and LM" configured on all member servers. We want to modify the authentication level on DC's to "Send NTLMv2
response only. Refuse NTLM and LM". Do you think we can do this safely as we have many SQL servers and AS 400 servers in our environment.
Can you tell me whats the authentication protocol that domain controller responds with when a member server send a request to the DC in our environment.

Hi Michelle,
For a domain controller, if the LAN Manager authentication level is
Send NTLM response only, it will accept LM, NTLM, and NTLMv2 authentication. If the authentication level is
Send NTLMv2 response only\refuse LM & NTLM, it will refuse LM and NTLM and accept only NTLMv2 authentication.
Regarding LAN Manager authentication level, the following article can be referred to for more information.
LAN Manager authentication level
http://technet.microsoft.com/en-us/library/cc938105.aspx
Best regards,
Frank Shen

Similar Messages

Urgent questions about NTLM authentication

Hi all.
In our customers side, we have this scenario.
One windows 2000 active directory as domain controller - server1
One WAS EP - server2
WAS EP user database is point to the server1.
When end user login in windows domain, user open the IE, write on the WAS EP url, user will login in WAS EP automatically and do not needs to input password.
The problem is now windows AD ldap field - officeName is mapped with WAS EP userid, not windows AD ldap field - userid is mapped with WAS EP userid.
But currently user login in windows domain using their windows AD ldap field - userid and password, not officeName.
How can I implement it ?
When user login in windows domain, the authentication will transfer it to officeName and login in Portal, is this solution can be implemented ?
Thanks a lot.

This may not be the exact answer but may put you in the right direction.
http://help.sap.com/saphelp_nw04/helpdata/en/98/9b2f41893a6e24e10000000a155106/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/0b/d82c4142aef623e10000000a155106/frameset.htm
Regards
Juan

Migration questions from Exchange 2007 to Exchange 2013

Dear Forum Members,
I'd ask just two short questions, regarding a migration from Small Business Server 2008 (Exchange 2007) to 2013. We installed the two Exchange 2013 servers, configured a DAG and updated every single URL (OWA, ECP, AnyWhere, Autodiscover etc.) to be a mail.domain.com
record (DNS round robin, since no HW load balancer :( )
Thankfully, the mail flow between the Internet and the other Exchange 2007 users are still working. Now for those users I've already migrated, if I check outlook connections there are several connections for GUID based servers via the DNS Round Robin
name proxy (the AnyWhere address). But I saw that there are still just one connection (type: Exchange Public Folders) to the old 2007 server. Is it okay? I'm a bit afraid to uninstall it because of this.
And the other thing: Based on what I wrote, do you think I've done it good? Or could I miss any important things? You are much experienced than me in these migrations so I hope that I can get some confirmation/advice here :(
ps: Is it good if I set NTLM authentication for Outlook AnyWhere?
Thank you really much for your help,
Best Regards,
Chris

Hi Chris,
Agree with Hinte, the user will still connect to the exchange 2007 server if there is a public folder database in the old server.
If the old public folders are no longer in use, you can delete the public folder database and create a new one in the exchange 2013 server, you can also consider migrating public folders to Exchange 2013 .
The following articles for your reference:
Use serial migration to migrate public folders to Exchange 2013 from previous versions
Set up public folders in a new organization
Step-by-Step Exchange 2007 to 2013 Migration
>>Is it good if I set NTLM authentication for Outlook AnyWhere?
The Outlook Anywhere authentication method you choose will depend on a few factors in your environment,
I recommend you refer to the following thread to understand how to choose:
https://social.technet.microsoft.com/Forums/exchange/en-US/75f8d6c4-70f4-49e5-ac32-a49dd91b5520/outlook-anywhere-ntlm-for-internal-users-and-basic-for-external-users?forum=exchangesvrclients
Exchange 2013: Configuring Outlook anywhere
Best regards,
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Niko Cheng
TechNet Community Support

Authentication on local SQL Server 2008 R2 Express server fails after Lan Manager authentication level changed to "Send NTLMv2 response only\refuse LM & NTLM"

I'm upgrading my organisation's Active Directory environment and I've created a replica of our environment in a test lab.
One medium-priority application uses a SQL server express installation on the same server that the application itself sits on.
The application itself recently broke after I changed the following setting in group policy:
"Send LM & NTLM - use NTLMv2 session security if negotiated"
to
"Send NTLMv2 response only\refuse LM & NTLM"
The main intent was to determine which applications will break if any - I was very surprised when troubleshooting this particular application to find that the issue was actually with SQL Server express itself.
The errors I get are as follows (note that there are hundreds of them, all the same two):
Log Name:      Application
Source:        MSSQL$SQLEXPRESS
Date:          1/19/2015 2:53:28 PM
Event ID:      18452
Task Category: Logon
Level:         Information
Keywords:      Classic,Audit Failure
User:          N/A
Computer:      APP1.test.dev
Description:
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 127.0.0.1]
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
   <System>
     <Provider Name="MSSQL$SQLEXPRESS" />
     <EventID Qualifiers="49152">18452</EventID>
     <Level>0</Level>
     <Task>4</Task>
     <Keywords>0x90000000000000</Keywords>
     <TimeCreated SystemTime="2015-01-19T22:53:28.000000000Z" />
     <EventRecordID>37088</EventRecordID>
     <Channel>Application</Channel>
     <Computer>APP1.test.dev</Computer>
     <Security />
   </System>
   <EventData>
     <Data> [CLIENT: 127.0.0.1]</Data>
     <Binary>144800000E00000017000000570053004C004400430054004D00540052004D0053005C00530051004C0045005800500052004500530053000000070000006D00610073007400650072000000</Binary>
   </EventData>
</Event>
Log Name:      Application
Source:        MSSQL$SQLEXPRESS
Date:          1/19/2015 2:53:29 PM
Event ID:      17806
Task Category: Logon
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      APP1.test.dev
Description:
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT:
127.0.0.1].
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
   <System>
     <Provider Name="MSSQL$SQLEXPRESS" />
     <EventID Qualifiers="49152">17806</EventID>
     <Level>2</Level>
     <Task>4</Task>
     <Keywords>0x80000000000000</Keywords>
     <TimeCreated SystemTime="2015-01-19T22:53:29.000000000Z" />
     <EventRecordID>37089</EventRecordID>
     <Channel>Application</Channel>
     <Computer>APP1.test.dev</Computer>
     <Security />
   </System>
   <EventData>
     <Data>8009030c</Data>
     <Data>14</Data>
     <Data>AcceptSecurityContext failed. The Windows error code indicates the cause of failure.</Data>
     <Data> [CLIENT: 127.0.0.1]</Data>
     <Binary>8E4500001400000017000000570053004C004400430054004D00540052004D0053005C00530051004C004500580050005200450053005300000000000000</Binary>
   </EventData>
</Event>
All of the documentation that I have followed suggests that the errors are caused by incorrect SPN configuration- I figured that they were never correct and it has always failed over to NTLM in the test environment (I can't look at production - we couldn't
replicate the setup due to special hardware and also RAM considerations), but only NTLMv2 has issues.
So I spent some time troubleshooting this. We have a 2003 forest/domain functional level, so our service accounts can't automatically register the SPN. I delegated the write/read service principle name ACEs in Active Directory. SQL Server
confirms that it is able to register the SPN.
So next I researched more into what is needed for Kerberos to work, and it seems that Kerberos is not used when authenticating with a resource on the same computer:
http://msdn.microsoft.com/en-us/library/ms191153.aspx
In any scenario that the correct username is supplied, "Local connections use NTLM, remote connections use Kerberos". So the above errors are not Kerberos (since it is a local connection it will use NTLM). It makes sense I guess - since
it worked in the past when LM/NTLM were allowed, I don't see how changing the Lan Manager settings would affect Kerberos.
So I guess my question is:
What can I do to fix this? It looks like the SQL server is misconfigured for NTLMv2 (I really doubt it's a problem with the protocol itself...). I have reset the SQL service or the server a number of times. Also - all of my other SQL applications
in the environment work. This specific case where the application is authenticating to a local SQL installation is where I get the failure - works with LAN Manager authentication set to "Send LM & NTLM - use NTLMv2 session security if negotiated",
but not "Send NTLMv2 response only\refuse LM & NTLM".
Note also - this behaviour is identical whether I set the Lan Manager authentication level at the domain or domain controller level in Active Directory - I did initially figure I had set up some kind of mismatch where neither would agree on the authentication
protocol to use but this isn't the case.

Maybe your application doesn't support "Send NTLMv2 response only. Refuse LM & NTLM".
https://support.software.dell.com/zh-cn/foglight/kb/133971

Public-facing on-premises SharePoint with NTLM authentication

I've been searching for authentication best practices for public-facing SharePoint site but I didn't find any useful resources on the issue that is troubling me.
Assume I set up a web application with Classic NTLM authentication. On that web application I enable
Anonymous access. This means that users inside organization's network will be able to authenticate (actually use SSO) using organization's DC. They will be able to access and administer all content. All other anonymous users will be able to see
published content only i.e. content which is permitted to anonymous users.
My question is: Is this kind of setup a security issue because if a potential attacker hacks a WFE then he has direct access to DC?
Is FBA maybe a better solution for public-facing sites? Or maybe use NTLM, but create a separate domain with one-way trust to organization's domain?

There are many variations you can take with this - and really you need to consider more than just your content. For true separation:
I would have a dedicated DC to manage service accounts.
I would break up my DMZ behind firewall contexts with a reverse proxy publishing SharePoint at the edge.
proxy/firewall -- SP Server -- Firewall -- SQL/DC
For true separation you don't want to share any underlying infrastructure with internal either, although in reality logical separation is usually enough.
Now you have to deal with internal user authentication and how to handle that. The first thing is I would have at minimum two webs available, your primary for editing and the extended version for public access.
While a one way trust would work - you still do expose user info out to the public which you may not want. With this configuration you could configure people picker to only select from a particular OU to minimize this.
Another option however is to look at using ADFS between your domains and create the trust there. You would have to configure the farm for claims auth to make this work, but this would eliminate the possibility of probing all the users in AD or the OU you expose.
With the ADFS method when you update documents you user name is still tagged to content - however if you don't populate the user profiles this will be the only information available about any internal user.
You may even want to go a step further and when you extend the public site, use forms authentication but don't provide any users. Then there is no authenticated access from the public URL. And with ADFS/Reverse Proxy may you even be able to configure some pre
authentication for your internal users before they can even reach the internal SharePoint pages.
I would strongly consider moving to SharePoint 2013 and looking at the cross site publishing (2010 and below have the content publishing - but stay away from that, when it works it's great, but when it doesn't it's a PITA to get back in sync). with cross site
publishing you have an editing site and the publishing site pulls from the Search index and the permissions are completely separate.

How to use different (not local) user for NTLM auth in Authenticator?

Hi All,
I use custom authenticator to provide user / passwords to connect to .NET Web Services. I overloaded function getPasswordAuthentication() that returns right user / password combination for the requested URL. It all works perfectly for many kinds of HTTP connections: basic, ntlm, ntlm-v2, through proxy, ssl, etc.
My problem is that during NTLM authentication from Windows computers JVM uses credentials of the currently logged in domain user instead of calling Authenticator to get other user / password provided by the user. In case when local user credentials fail to authenticate, JVM calls my Authenticator but in case authentication is successful it does uses local domain user and never calls my Authenticator. The issue is when this local domain user does not have enough permissions but authenticated correctly there is no way to supply JVM with another user to begin with.
What can I do to force JVM to ignore local domain user and to use Authenticator to collect credentials during NTLM authentication requested by the server in case the software runs on a Windows box with currently logged in domain user?
I am looking for the answer for a long time already but found only questions and suggestions to switch server from NTLM authentication which is not an option for me. From the developer's view it has to be pretty simple change for Sun to do in Java networking API. Is there any way to escalate it to Sun support? Maybe there is some property in some JRE patch level that allows to do this?
Thank you very much!
Mark

Thank you for the reply. I have kind of an opposite problem. I can perfectly connect from Linux computers to Microsoft IIS servers using NTLM or even NTLMv2 authentication. My problem is connecting from Windows client computer joined to the same domain as IIS server with the domain user logged in to this computer. In this case this user account will be used in any HTTP connections I initiate to this IIS server instead of the one that I want to supply in my custom Authenticator.
I have graphical interactive application that connects to IIS Server. When user runs it and connects to IIS server I want to prompt for the user/password regardless whether JRE may correctly authenticate using current user account credentials. The current user may not have enough permissions in IIS application so I want to use different user to login to IIS application.
Thank you anyway,
Mark

Windows NTLM Authentication on SAP 4.6c (Platform AIX)

I am trying to use NCo 2.0 for C# .Net application with Web Service and C# Web UI.
My Users are in AD domain and need to authenticate on IIS via AD (Integrated NTLM)
I need to implement single sign on for SAP integrated application.
As per NCo documentation: I need to set-up trust relationship between IIS and SAP, use this trusted user (DOMAIN\IUSR_SAPPOOL) and send active directory id as external id in connection string. All transaction should run with external user id context.
Can someone help me with following question.
1. Does NTLM trust relationship / authentication on SAP running on AIX? or Do I have to setup kerberos authetication?
2. What SNC library needed for SAP (AIX instance)?
3. How can I configure NTLM authentication on SAP (AIX instance) The NCo 2.0 documents only explains SAP (MS instance) configuration.
What option do I have to get Single Sign On working?
Any help is highly appreciated.
Regards and Thank you in advance.

> Hi Reiner,
> Thank you very much for response, this is helpful
> information.
If you consider an answer as helpfull, please mark it with the button on the left side :-).
> My options are pretty much limited,
> I can't use NTLM since, AIX will not accept trust
> -- NTLM Auth will not work with AIX
> -- Kerberos auth have to have third party tool like
> CyberSafe for SNC trust relationship.
As I wrote, you can use any SNC provider. Especially Secude would be interesting, as it is available on all platforms.
> I planning to try using SSO as mentioned in "Enabling
> Single Sign-On for ASP.NET Applications in Enterprise
> Portal 6"
> Is this approach works with EP 5.0?
This is a completely different approach: In the stuff I was writing to you before I was assuming that IIS would do the authentication. The other approach is that SAP Portal does it. This also works - EP 5.0 should be fine - but it works completely different. E.g. you doesn't need a trusted connection for SSO with MYSAPSSO2 ticket.
> If any one has "sapsecu.dll" please send me at
> [email protected] with same size as stated in
> this document.
This DLL is not allowed to be exported into some countries because it contains strong cryptography. You usually get it via your local SAP subsiduary.
> My SSO ticket did not get created after following
> steps in document, I am suspecting either sapsecu.dll
> or veryfy.pse is wrong?
Did you find a MYSAPSSO2 cookie in the request?

How i can export and distribute setting; network.automatic-ntlm-auth.trusted-uris" to all computers in the network (With Folder Rederiction enabled)?

Hi,
We are about to enable SSO in our environment. As a result, I need to modify the value for user_pref("network.automatic-ntlm-auth.trusted-uris", "my domain");>>prefs.js.
I created a simple .bat file to make the necessary mod and add the line to pref.js. When I run the file it outputs the prefs.js to the same location, not the Mozilla AppData folder. We are a Win7 environment with folder redirection enabled. Therefore, our user's Mozilla AppData folder is located at \\my domain\dfs\XenDesktop\Profiles\username\AppData\Mozilla\Firefox\Profiles\default (random default profile name). My question is what is the best course of action to add this pref. to all PC user's pref.js file? keep in mind the pref.js is located on the hidden network path I included above. I apologize if my question is not easy to understand.

cor-el, thanks for you reply.
Yesterday, prior to my post, I did try the mozilla.cfg method. I read your reply to another FF user's, similar question. Here are my complete steps.
1. created a txt file with the following info: defaultPref("network.automatic-ntlm-auth.trusted-uris", "ngs.org"); // set new default value
2. saved the file as mozilla.cfg
3. dropped the file in C:\Program Files (x86)\Mozilla Firefox
4. Created local-settings.js with the following info:
pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0); // use this to disable the byte-shift
5. dropped the file in C:\Program Files (x86)\Mozilla Firefox\defaults\pref
When I launch Firefox the network.automatic-ntlm-auth.trusted-uris should say ngs.org, but the value is still blank.
Any help is greatly appreciated.

Outlook Negotiate/NTLM authentication credential prompt

Hello everyone,
I have been digging quite a while now for a solution to this but apparently there is not a lot of systems out there utilizing this or having problems with it. Here it comes:
We have a pure (no migration or coex) Exchange 2013 CU7 environment in production with 3 x CAS/MBX Servers (3 sites connected via WAN VPN). Inside our network our outlook clients (2013 SP1+) authenticate via Kerberos (ASA/SPN) to the Exchange Servers and
connect via MAPI over HTTP. Everything working fine!
External is a different Story: We have a Application Request Routing (ARR) machine in our perimeter network that forwards external users to the Exchange Servers and for a reason that I didn't manage to find yet I can't get it to work so that domain joined clients
(notebooks) that are outside the company's LAN would use their cached credentials to try to authenticate outlook against the Exchange Servers. Outlook always prompts the user for her/his password on start up and then connects fine. No problems after that -
PF, OoO, OAB - everything is working. If the user restarts the outlook -> password prompt once again and fine after that. Saving the credentials works but is obviously not the way NTLM/Negotiate is supposed to work.
So here is my progress on this:
I verified my virtual directory settings. Here is how the Mapi virtual directory looks like:
IISAuthenticationMethods          : {Negotiate}
InternalUrl                    : https://mail.domain.com/mapi
InternalAuthenticationMethods : {Negotiate}
ExternalUrl                     : https://mail.domain.com/mapi
ExternalAuthenticationMethods   : {Negotiate}
I've set everything to Negotiate because we don't have legacy Exchange Servers nor legacy mail clients in our network. I tried setting it to NTLM only which made the problem shift. Test clients connect to exchange and are able to view/receive mails but got
the infinite credential prompt and weren't able to access PF, OoO and OAB. Setting it to NTLM and Negotiate produces the same result as Negoiate alone.
Browsing https://autodiscover.domain.com/Autodiscover/Autodiscover.xml with IE (autodiscover URL set in intranet settings) gave the expected error code 600 without prompting for credentials. Even Firefox (network.negotiate-auth.trusted-ris set to domain.com)
is utilizing cached windows credentials and is able to log on to autodiscover and OWA with windows authentication enabled.
When a client has a valid Kerberos ticket cached (cmd -> klist) Outlook uses that ticket successfully even from outside the network but as soon as the ticket is gone (sign out and sign back in) Outlook prompts for user credentials again.
"Show connection status" in Outlook and the HttpMapi log on the CAS both show that Negotiate has been used for the connection. But why the password prompt then?
I read up on IIS ARR and it seems that it just passes through the authentication information when set to "anonymous authentication" which it is.
Now how I understand the auth method Negoiate in Exchange 2013 is that Outlook and the Server try to handshake on the strongest auth mechanism available in the following order: Kerberos -> NTLM -> Password Promt (Basic/NTLM) but in my case this doesn't
apply.
Now I would apprechiate it very much if someone could educate me in how this is supposed to work and if there is a mistake in my configuration or my understanding of the authentication process correct it.
A great day to everyone!
Vasko

I don't have a ton experiencing using something like ARR, but we should do some testing. The first thing I would try is to route around the ARR in the DMZ and connect directly to Exchange from externally. This SHOULD let us know where the problem
lies. If it succeeds (no auth prompts) then the issue is on the ARR and not Exchange. If it fails, then the issue is with the ARR and that needs to be looked at a little more clearly.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread

Truncated POST requests in IE 10 - In Response to NTLM Authentication

In Internet Explorer 10, the browser is incorrectly truncating HTTP POST requests and submitting unsolicited NTLM negotiate headers with a HTTP Content-Length of Zero Bytes. This results in HTTP POST parameters failing to be submitted to the
server.
Assume the following web application with a context root of:
https://w3.someapplication.net/webapplication/
Secure cookies for this site are established at the context root of this application.
To reproduce this issue, a secure session is established at a protection space deeper than the root context of the web app:
https://w3.someapplication.net/webapplication/secure/login
After establishing a secure session with the web application, some client side artifacts are retrieved from a web proxy at a higher protection space:
https://w3.someapplication.net/webapplication/somejs.js
Subsequent HTTP POST requests to a deeper protection space will result in IE incorrectly attempting to pass an unsolicited NTLM negotiate header to the server side, and the HTTP POST request will be truncated with a Zero Content-Length header:
https://w3.someapplicaiton.net/webapplication/submit/form
The result is that the HTTP POST parameters submitted to the last URL will be lost.
This is reproducible against IE6 and IE10. It does not reproduce against IE8, or any non-Microsoft browser which all behave in a sane manner.
My Questions:
Why is IE behaving this way?
What can I do to make IE behave properly? Please don't suggest that I change the entire structure of my company's website to overcome this kind of silly bug in IE.
Is there a planned fix to correct this behavior back to the proper implementation observed in IE8?
Additional details about this problem are documented by an IE Internals blogger at the following url:
http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
Michael

Yes, I have read that blog post in detail. All of the comments from Microsoft on this issue suggest making intrusive changes to the web application side to work around this "optimization". This is not an acceptable answer. This
is clearly a bug in IE. Evidence to support that this is a bug is that the behavior within IE's own browsers is not consistent; IE6 and IE10 will reproduce this issue, IE7 and IE8 will not.
I don't understand your suggestion; "ensure all paths are configured to require authentication". This is not a reasonable expectation for any normal web app. Our application does require authentication on all paths. However, when the first
authentication request goes through, a HTTP Session is established. Any subsequent request to that domain will not and should not be re-authenticated. IE making assumptions about the authentication requirements of a server side application is incorrect.
Further, even if i did re-challenge the browser for credentials on every path, regardless of whether a session is established or not, how would I handle the requirement to serve client side artifacts from a web proxy within that secure domain? Am I expected
to force my web proxy to require an NTLM header to serve up a CSS file? That is just silly.
You also suggested that my application might be incorrectly returning a 401. I can assure you, that is not the case. The flow is this:
Perform a signon to the application and retrieve some client side artifacts required by the splash page
https://w3.myapp.com/some/app/path?query=string
401 + www-negotiate response header
https://w3.myapp.com/some/app/path?query=string
browser provides a ntlm token, user is logged in, session is started
https://w3.myapp.com/some/file.js 200 response code, no challenge from the server side
Splash page is loaded; user submits a POST request
https://w3.myapp.com/some/app/path POST request fails because IE truncates the request and attaches an NTLM negotiate header with Zero Byte content length. This is an unsolicited negotiate header from IE.
Honestly, it really irritates me when people suggest we should change our entire application structure to accommodate IE bugs or "features" that are completely outside of the HTTP spec. I understand RFC4559 states that a browser MAY initiate a request
to a server which includes an unsolicited negotiate header, but it doesn't say anything about truncating the contents of that request.
No other browsers exhibit this behavior, and even the behavior within Microsoft's own product is not consistent. It is insanely frustrating as a web developer trying to deal with all of IE's little nuances.
Is there anyway this can be turned off via a registry entry? Is there any plan to fix this in a future release?

WSA redundancy and WCCP questions

Hello! My customer bought a pair of S370 WSA prior to deployment planning. I need to deploy both of them into existing network and I'd like to ask few questions with somebody who knows how to do it.
1. As I know from manuals, WSA doesn't support any clustering but I'd like to use both of my S370 for redundancy. I'm planning to use WCCP only, no explicit proxy mode will be used. What methods can I use to deploy redundant WCCP cache on pair of WSA? If it possible, I'd prefer to use something like Active\Passive but not load balancing scheme. Does it have Centralized management feature like ESA to share configs between devices?
2. I have fusion router which "mixes" traffic from different vrf. Is it possible to configure router such way that every vrf(which corresponds every interface and different subnets) will be seen with its own ip address in internet or all of them will be using just WSA's address like in explicit proxy mode?
3. When I tried to test my WSA in explicit proxy mode prior to configuring WCCP, I found out that I can use it as a proxy without any authentication, just setting it's address and port in my browser. How can I disable explicit proxy mode or set any authentication(no LDAP or NTLM) to prevent unauthorized access to using my proxy?
I'm newbie with IronPorts so I will appreciate any help including links to manuals

The WCCP protocol allows for automatic detection of all connected devices, both proxies and routers/firewalls/switches. When configuring WCCP with multiple WSAs, they're all in the WCCP cluster, with the router doing the load balancing beween the detected proxies. From what I've seen, you can't configure an active/passive scenario.
As you mentioned , WSAs don't support clustering seen in ESAs. You could use a M-series box to provide central management and reporting for multiple WSAs in your enviromment.
Regarding VRFs: WSAs support IP spoofing, which allows you to send out requests with the client's instead of WSA's external address. You could perform PAT of multiple addresses on the edge router/firewall to send the requests out with a different IP address for each VRF for example.
I don't think you can fully disable the explicit proxy on the WSA. You can set up a firewall rule to prevent direct client access to the proxy ports..
Sent from Cisco Technical Support iPad App

NTLM and ADFS claim treated as different user

Dear All:
Currently our SharePoint is using mix authentication mode (claim mode with two authentcation providers)：
Windows-NTLM & ADFS2.0
The ADFS'a identity store is same as SharePoint's domain, it means we have only a single AD, NTLM authentication provider is used for users who are in office, ADFS authentication provider is used when they are at home. (The same credential)
When users opens SharePoint, it prompts a page to let user to select which authentication provider they want to use (NTLM or ADFS).
The question is when the same user login by using NTLM or ADFS, the user will be treated as a different user
For example:
UserA login by using NTLM, his identity claim looks like: Domain\UserA
UserA login by using ADFS, his identity claim looks like: i:05.t|saml provider|[email protected]
The profile and permissions of this user will be different
Is there a way to treat the user as the same user no matter login by ADFS or NTLM ?
I know if we remove the NTLM authentication provider, only use ADFS can solve this problem, but the client don't want to do this, because：
The SharePoint is upgraded from 2007 (Classic mode) and it has a huge number of existing users, resources, permissions.
After upgraded to the claim mode, SharePoint automatically used the NTLM authentication provider.
If we removed the NTLM authentication provider, the client has to reset all permissions in SharePoint again, for example:
A ListItem's Permission:
1. In SharePoint 2007 Classic Mode:
Domain\UserA -- Full Control
2. After upgraded to SharePoint 2010 and upgraded to Claim Mode, the client didn't need to reset the permission：
Domain\UserA -- Full Control
3. If we remove the NTLM authentication provider, the client have to reset the permission：
i:05.t|saml provider|[email protected] -- Full Control
Any ideas would help,
Thanks a lot!

SharePoint sees the Windows and Claims identities as different, even though they are the are the same user in the same directory store.
I'm troubled by the SAML token though, if it was a claims windows token (i:0.w) I would say you could use Move-SPUser to consolidate them. I've done this
before when during configuration of a farm a user can appear with duplicate entries in the site, one for windows auth (DOMAIN\user) and one for claims (i:0.w#domain\user).
Move-SPUser can merge the SPUser objects together (this was one of the purposes of it's predecesor, the migrateuser stsadm operation). If it was a windows token it works, but because of the ADFS provider it could be strange.
Here's how I would test it out:
Create a new test user (no sense in messing up a real user)
Log test user in to the site with NTLM
Log out test user
Log test user in to the site with ADFS
Log out test user
With an admin account, verify using the method you previously used to determine duplicates that there are indeed two users for this test account (one windows, one SAML).
Move-SPUser (details below)
Verify there is now one user for the test user
Log test user on to the site with NTLM
Log out test user
Log test user on to the site with SAML
Log out
With an admin account, verify again to make sure there is still only one account
For Move-SPUser and windows claims I would usually recommend merging the windows account into the claims. Without knowing what will happen I'd say let's try the same here (merge the windows account into the SAML claim):
$testUser = Get-SPUser -Web "http://sitecollection/or/site" -Identity "DOMAIN\testuser"
Move-SPUser -Identity $testUser -NewAlias "i:05.t|saml provider|[email protected]" -IgnoreSID
Jason Warren
Infrastructure Architect
Habanero Consulting Group
habaneroconsulting.com/blog

NTLM asking for log in

I have installed mod_ntlm version 1.3 and it works except that when I first access an APEX application or the development environment it asks me to login to the server that APEX is running on even though I am logged into the network. Our domain server is different than the APEX server. Is there something in the MOD_NTLM parameters I need to get it to not ask me to log into the APEX server? My NTLM parameters look like this in my marvel.conf:
AuthType NTLM
AuthName "NTLM authentication"
NTLMAuth On
NTLMAuthoritative On
NTLMOfferBasic On
NTLMDomain our domain
require valid-user
Can anyone help! I have looked all over the place and I can't find an answer to this question.
Rick

Rick,
I have no real knowledge of mod_ntlm but I was directed to this site, perhaps this can help you as well
http://wiki.bestpractical.com/view/NtlmAuthentication
GL
Randy

Safari on Mavericks with NTLM Proxy

Hello,
we use a Bluecoat Proxy in our Company with NTLM Authentication.
I login to the Mac (10.9.2) with my AD Account.
The proxy is configured with hostname and port.
Surfing in Firefox and Chrome works without a problem.
If i sniff the traffic for this two browsers i can see that
both browsers use NTMLSSP for authentication to the proxy.
If i try to use safari i does not work.
If i want to open a website the behaviour is always the same.
The blue bar in the address field stops at specific point but then nothing happens.
Even after half an hour i do not get an error message or the website.
There ist just nothing happening anymore.
Has anybody an idea what the problem could be?
Thanks

I have this same issue, and I have posted requesting insight on it here as well. But this has been to no avail.
It seems the proxy breaks only on networked accounts.
If you use a local account the proxy (in my experience) works fine if set up normally as you would.
-----TEMPORARY WORKAROUND-----
This is just something that I have tried that has worked for me, it may not work for you or anyone else.
Our proxy is a windows server set up with TMG2010 and a web proxy address that is different from the DNS name of the server machine.
Normally we enter into the web proxy address which is something like: proxy.mydomain.com
I had the idea to try entering the local network name of the proxy as the proxy server in the network settings, then set up the user name and password boxes as I normally would as well. This actually worked.
Although I am not sure what to take from WHY it works. DNS has no issues, so it seems to me the authentication through HTTP/HTTPS has broke.
I have also read that somewhere else explaining it more in-depth than I feel necessary here but I will link you: http://apple.stackexchange.com/questions/118150/safari-7-cant-connect-to-intrane t-using-http-authentication
I have found the location to toggle the authentication on our TMG2010 server so now I'm just waiting until closing time to test.
---EDIT---
I just realized that most people tackling these issues look at what could be the problem on the MAC OS X side/Client Side….maybe the web server/proxy could use a good update to support more authentication control/methods/error handling…but then again that is what happens when you have two big brands with different architecture and software competing for floor space.

NTLM - anyway to force credential prompt ?

Hi all,
I am using NTLM auth on a website and an applet that is used needs to connect back and retrieve images and issue commands at the users discretion.
I am finding that in some instances, when the applet initializes (and fetches the first images) it will prompt the user to enter the NT authentication credentials, but not in other instances. In the latter case, the applet always obtains and sends the current logged in credentials instead (and subsequently fails to retrieve the right images).
This same applet (since 1.4.2) has been working fine, always prompting the user, however within the last couple months it has stopped doing this reliably.
I think this happenned around the time of 1.5.11 update, however i cannot be sure since in many cases, the account i am testing with exists on all tmachines and the fact that the authentication credentials used were "wrong" is only visible by examining the server logs.
Is there anyway to force the applet to ALWAYS prompt the user for credentials - or failing that use the credentials used by the browser for that same site ?
Thanks in advance.

I don't have a ton experiencing using something like ARR, but we should do some testing. The first thing I would try is to route around the ARR in the DMZ and connect directly to Exchange from externally. This SHOULD let us know where the problem
lies. If it succeeds (no auth prompts) then the issue is on the ARR and not Exchange. If it fails, then the issue is with the ARR and that needs to be looked at a little more clearly.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread

NTLM Question

Similar Messages

Maybe you are looking for