I have an application that is hosted in IIS.
When it is hosted on Machine One, the user name comes through as mynetbios\username.
When it is hosted on Machine Two, the user name comes through as username#mydomain.net.
The same code is running on both machines. Both are running IIS 10.0. Both have authentication set to enable Windows Authentication and disable all the others (including anonymous).
Is there something in IIS that could control how the username comes through?
Domain\User is the "old" logon format, called down-level logon name. Also known by the names SAMAccountName and pre-Windows 2000 logon name.
User#Domain.com is a UPN - User Principal Name. It's the "preferred", newer logon format. It's an Internet-style login name, that should map to the user email name.
There's not really much of a difference. For more information about "User Name Formats", you can refer to this link.
Related
I've been following this guide on deploying an ASP.NET web application with CI. It has all been going smoothly till I got to the Configure Logins and Database Permissions stage. Particularly when entering the login name.
http://www.asp.net/web-forms/overview/deployment/configuring-server-environments-for-web-deployment/configuring-a-database-server-for-web-deploy-publishing
For the life of me I cannot discover what must go in this field
The author supplies the following instruction
Machine accounts take the form [domain name][machine name]$ —for example, FABRIKAM\TESTWEB1$.
Despite scouring the internet I have found very little in regard to discovering the domain name and machine name values to be inserted here. Almost everything I enter results in
Create failed for Login 'HISSAP\matt$'. (Microsoft.SqlServer.Smo)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=13.0.15600.2+((SSMS_Rel).160712-1724)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Create+Login&LinkId=20476
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
Windows NT user or group 'HIAP\matt$' not found. Check the name again. (Microsoft SQL Server, Error: 15401)
Now I know that 'matt' is a user account entered above and not a machine account, but I am at a loss in determining what needs to go into the Login Name for the machine account described above in the tutorial. When I use "Search" next to the field I have many options to select many different accounts, but how am I to know which one to select? The tutorial does not specify.
Could I just use a user account for the machine account? If so which one? If not what should I enter as the machine name?
I think the domain name is HIAP, I tried the computer name for the machine name which is also hiap, I tried different cases, with and without the $ at the end. I also went into IIS and tried the host name in site bindings which is hiapdev. Did not work.
I am remotely connecting to a Windows Server 2012 R2.
Don't try the Search... button in General tab to search machine account. Machine account cannot be searched in Select User or Group dialog box. Please follow below mentioned steps to add a machine account to a SQL Server instance:
Open a new login window.
Click General page in the left navigation pane.
Give input in the Login name field in the format [domainName]\[MachineName]$. In your case it is FABRIKAM\TESTWEB1$
Now go to Server Roles page. Check sysadmin server role as shown below:
Press OK. Now, you can see your machine's account under Security > Logins node.
Credits: Garth Jones
I have the TFS power tools installed, and I can see the shell extensions context menus; however, I can't find a way to bypass the integrated windows authentication and specify a new username per operation. I am using a common username on a server due to some legacy software, and I need to access TFS with a different domain user. Is there an option to do this on the fly?
I expected to receive a prompt when connecting, but I just get an error indicating that the current user doesn't have permissions.
If you want to ALWAYS use a certain user name & password when authenticating to a TFS server then you can use Windows Credentials Manager and add a new Windows Authentication entry. You type in the full server name, domain username, and password. Additionally, you'll want to add the server name into the "Trusted Sites" list in Internet Explorer.
Just remember to edit that entry in the future if you ever need to change it like when the account's password has been updated. You'll be pulling out your hair until you remember that it is in there.
I have using SSRS 2008r2 on Windows2003 server and added Domain Users group as a System Administrator via report manager. However, when I mimic an ordinary user in report manager web interface on my computer(member of the domain) I get;
User 'usera' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed.
if I try with user a on the server by using FQDN, it it shows same error above.
If I type localhost instead, it does work. while using localhost, it I navigate to a folder and while I am in a folder and change the localhost to FQDN, it still works.
There are lots of solutions on the web, like the one on http://skamie.wordpress.com/2010/06/24/ssrs-and-uac/, but it did not work..
Does anyone have any idea?
Many Thanks
Regards
Have you tried right-clicking on IE and select Run as Administrator?
I have to do that from time to time on my development machine so it is sort of first solution that came to mind. Hope it helps.
Additional answer:
So the Domain Users group has System Admin role. You can try adding that group as Browser role or Content Manager role at the root folder.
Is there a way to force sharepoint 2010 to popup the dialog to ask the user for a username and password and not use the computers logged in user, if that user doesn't have access.
We need an internal sharepoint website to not use the windows credentials, since these are computers used by many people. The windows user doesn't have access to the site, so currently it shows an access denied, click here to log in as another user. We would prefer if it just asked for credentials in a more graceful manner.
There is a way to configure Internet Explorer to do this. In Internet Explorer(IE),
Go to Tools
Click Internet Options
Click on the Security tab
Click on the button labeled Custom Level.
Scroll to the very bottom of the list
Select the option labeled Prompt for user name and password.
The default option Automatic logon only in Intranet zone' is what is causing IE to send the credentials to SharePoint. This of course would force everyone to log in on that computer.
Forms Based Authentication is the answer. You can modify the Login page and even where the users credentials (username/password) are stored (e.g. a SQL database rather then AD).
Use browser other than IE to access the SharePoint site from the community computers.
I am guessing you work in a corporate environment, which would mean your computers are probably managed by your IT department and part of your domain. Because they are part of your company's AD (Active Directory), your systadmins Should be able to modify the existing policy (i say existing, because in IE, the defaults for the settings relating to logging on are by default set so that you WOULD have gotten a logon prompt, i am guessing a group policy is already in effect). If it does not exist, have your admins create one.
The setting Jeremy mentions is one option. It could also be that the site is in included in your IE's "Local Intranet Zone". If it is, or, more probable, there is a wildcard *.yourdomainname.yourdomainextension).
Use the setting mentioned by jeremy to override the default logon behavior (automatic logon) associated with sites listed in the intranet zone.
A group policy can be applied to a group of computers or all the computers in the domain. If the policy should be applied to a small group of computers only, put those computers in a separate OU (Organisation Unit) in AD and apply the policy to that OU.
What about creating a new zone, secured with FBA, for those community computers? As long as the users of the community computers are given only URL for the new zone, you should be OK.
You can create 2 registry files to turn this behavior on and off for the Internet Explorer. Use Notepad to paste the values below, ensure that Windows Registry Editor Version 5.00is the first line, and that you're appending 2 blank lines at the end of the file (press 2x Enter).
To turn it on (i.e. always ask for credentials): AlwaysAsk.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\1] "1A00"=dword:00010000
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\1] "1A00"=dword:00010000
To turn it off (automatically use credentials, only ask if necessary): AutomaticLogon.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\1] "1A00"=dword:00020000
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\1] "1A00"=dword:00020000
This is useful for testing, espcecially if you're a developer in a corporate environment where you can't easily change the policy settings on your PC (but you need elevated rights, i.e. you have to run it as Administrator).
Note that the 1st key is for the local machine, the 2nd key is for the current user (currently logged in), which is needed to activate it immediately.
If you need more details about the values, check out this link:
Internet Explorer security zones registry entries for advanced users
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.