Hi, we have in our environment around 200 DP globally.  I'm troubleshooting issue with DP Authentication when trying to install applications.  For background all our workstations are joined in Active Directory "NA" Domain, users are located in different domains depending on the region EU = Europe; NA = North America etc....

Our DP's are configured the standard way as recommend by Microsoft and we have also setup Network access account that can be used during OSD.  We have not enabled the "Anonymous login" and don't want to do this either.

Scenario 1

I'm located in Europe, with my workstation I try to install application and checking the logs, I'm redirected to DP in Europe based on boundary setup, and installation completes just fine.  Checking IIS logs I can see that I'm authentication using my DOmain\workstation name  (ex.  na\cnu12324-x7$)

Scenario 2

On the same workstation I've updated my hosts file and point my DP to US Based distribution point. I try to install application, and that fails, checking my logs I see Access Denied error, checking the server I can see incorrect/unknown user account.   (Just to be sure, I've tested the installation from workstation located in the US and obviously then it works, and if I check the IIS logs, I can see that I'm authenticating using my computer name)

I like to understand how the authentication works, and why for some reason if I try to use DP in another region my applicaton installation fails.  I've done the necessary checks

- Confirm DP's are configured identical

- I'm able to access the content on both DP's using network access account.

If I try to do the same with DP located in Europe it does work and my application downloads/installs correctly.

The way IIS authentication suppose to work for SCCM is (Got the info from this Forum)

- anonymous login

- computer account

- network access account

We like to use this option to quickly test if applicatoni does install correctly from DP, before we have to do any "Redistribute" of content.

Any help would be appreciated.

What OS are your clients? There is a known auth issue with Win7 that affects untrusted ConfigMgr clients like those in alternate forests: http://support.microsoft.com/kb/2522623

Jason, All these workstations are in the same forest, we only have 1 forest but with multiple domains based on regions. Like I said already earlier the workstations are all joined in the same domain,its only users that are in multiple domains. What is more puzzling is when I check the client logs I can see that its trying to use the network access account but still not working, find it even strange it has to use it as workstation is joined in the domain so no need to use that account.

OK, taking a step back. Have you tested with a real client that should use the NA DP based on boundaries instead of trying to manipulate name resolution?

Jason,

If I have clients in the same region as the DP's are located it works just fine.  I even checked EventViewer on the DP and this what I see for failed client:

Subject:
 Security ID:  NULL SID
 Account Name:  -
 Account Domain:  -
 Logon ID:  0x0

Logon Type:   3

Failure Information:
 Failure Reason:  Unknown user name or bad password.
 Status:   0xc000006d
 Sub Status:  0xc000006a

Same server but now client located in NA, installing application

Logon Type: 3

New Logon:

Security ID: NA\CND0200TF1-X7$

Account Name: CND0200TF1-X7$

Account Domain: NA

Logon ID: 0x3514869a

Logon GUID: {77d4786d-be5f-ed2b-aa7c-edfc3c738243}

Process Information:

Process ID: 0x0

Process Name: -

Network Information:

Workstation Name:

Source Network Address: 155.118.59.241

Source Port: 60165

almost looks like the computer name is not correctly send for authentication.

so, you're only having issues when manually manipulate name resolution?

no, I have issues for any user that is trying to install applications from Distribution point in another region.  We should only use these DP's in case of fail over, but like I've explained before I need this to work for troubleshooting also.  I can make it work if I enable the "Anonymous" but don't really want to do this, I like to understand what the real issue is for this.

What I like to understand is where does the userID come into play when authenticating against Distribution Point.  From what I have read so far all authentication should happen based on the computer name, flow is anonymous; Domain\Computer Name; Network Access Account (last one will only be used if computer is not joined to Active Directory).

I've enabled some Fall Back trace logs on my IIS server, and they show for the failed attempt that UserName/Pwd is blank, so it does not get transferred correctly.   To be clear nothing is wrong with the DP's the application install fine for users in the same region, it has nothing to do with these specific applications.

I hope my explenation makes any sense, but I'm looking at this for few days, still puzzled about this. 

maybe to add, or make it even more confusion I can perfectly browse to any of these URL's with my userID using IE or any other browser for that matter with integrated login,  so the cross domain authentication for users is working as expected.  This makes the issue so annoying as the SCCM App install should only be using the computer name to authenticate however in our scenario it does matter in which domain the UserID reside to be able to install application.

Scenario's I've tested (all our computers/IIS Servers are joined to the same domain "NA")

User Domain           IIS Server region            Status

Europe                    Europe                           Application installation works fine

Europe                    Americas                        Failed, with authentication error and access denied

same is true with user testing from other domains.

                   

So, all workstations and all servers are part of the NA domain?

Jason That is correct. It's only users that are in different domains Ap. ->. Asia pacific Eu. ->. Europe Na. -> north america La. ->. Latin america

Yes, I know this is an old post, but Im trying to clean them up. Did you solve this problem, if so what was the solution?

Since no one has answer this post, I recommend opening  a support case with CSS as they can work with you to solve this problem.