回答:
Active Directory環境があると仮定します。
バックスラッシュ形式のDOMAIN \ USERNAMEは、SAMアカウント名がUSERNAMEであるユーザーオブジェクトのドメインDOMAINを検索すると考えています。
UPN形式のusername @ domainは、ユーザープリンシパル名がusername @ domainであるユーザーオブジェクトをフォレストで検索します。
現在、通常、SAMアカウント名がUSERNAMEであるユーザーアカウントのUPNはUSERNAME @ DOMAINであるため、少なくともADが完全に機能していれば、どちらの形式でも同じアカウントを見つける必要があります。レプリケーションの問題がある場合、またはグローバルカタログに到達できない場合、UPN形式が失敗する場合にバックスラッシュ形式が機能する可能性があります。また、逆が適用される（異常な）条件もあります。たとえば、ターゲットドメインのドメインコントローラに到達できない場合などです。
ただし、ユーザーアカウントを明示的に設定して、ユーザー名コンポーネントがSAMアカウント名と異なり、ドメインコンポーネントがドメイン名と異なるUPNを持つようにすることもできます。
[Active Directoryユーザーとコンピューター]の[アカウント]タブには、[ユーザーログオン名]という見出しの下にUPNと[ユーザーログオン名（Windows 2000以前）]という見出しの下にSAMアカウント名が表示されます。そのため、特定のユーザーで問題が発生している場合は、これら2つの値に矛盾がないことを確認します。
注：上記の検索でユーザーアカウントが見つからない場合、追加の検索が行われる可能性があります。たとえば、指定されたユーザー名が（明らかな方法で）他の形式に変換され、一致するかどうかを確認します。また、フォレスト内にない信頼されたドメイン内のアカウントを見つけるための手順も必要です。正確な動作がどこで文書化されているかはわかりません。
トラブルシューティングをさらに複雑にするために、Windowsクライアントは、成功した対話型ログオンに関する情報をデフォルトでキャッシュするため、Active Directoryのユーザーアカウント情報にアクセスできない場合でも、同じクライアントにログインできます。
私はこれについて訂正されるかもしれませんが、実際には大きな違いはありません。
Domain \ Userは、ダウンレベルログオン名と呼ばれる「古い」ログオン形式です。SAMAccountNameおよびpre-Windows 2000 logon nameという名前でも知られています。
User@Domain.comはUPN- ユーザープリンシパル名です。これは、「優先」された新しいログオン形式です。これはインターネット形式のログイン名であり、ユーザーの電子メール名にマップする必要があります。（MSDNの参照）
私が思うにUPNでログインする理由はほとんど表面的なものです-会社のメールアドレスとしても機能するワークステーションにログオンするための単一の名前を会社のユーザーに仮定的に与えます。
編集：詳細な設定-UPNのもう1つの利点は、ユーザーがログオンするために複数の有効なUPNをセットアップできることです。繰り返しますが、主に化粧品です。しかし重要なことは、すべてのアプリケーションがUPNと互換性があるわけではなく、それがあなたが経験していることかもしれないということです。
編集＃2：実行されるわずかに異なる2つの検索形式について、以下のハリージョンストンの回答が好きです。それは理にかなっており、最も重要なことは実際にあなたの問題を説明するかもしれません。:)
スラッシュ形式（DOMAIN\username）は、実際NetBIOSにはドメインのDNS名（domain.mycompany.local）と同等です。名前は15文字に制限されており、ドット、アンダースコアなど含めることはできませんNetBIOS
このページでは、より詳細に説明します。
* Jeff Schertz、2012-08-20、Active Directoryの命名形式について（ここにアーカイブされています。）
上記の@ harry-johnstonで述べたように、それは本当に古いNT4およびWindows 2000互換のフォーマットですが、お気に入りのフォーマットとしてはまっているようです（入力するのはやめましょう！）。最終的に、レガシーフォーマットのサポートはWindowsから行われる可能性があります。
ユーザーをユーザー名でPCにログインする際に問題が発生し、Windowsログインボックスがデフォルトになっていることに気付かないという問題も回避できるため、ユーザーをUPN形式を使用する習慣にすることをお勧めします。pc01\fredリモートデスクトップクライアントが以前に使用した別のドメイン名をキャッシュする可能性があるため、PCドメイン（例：）または別のリモートデスクトップホストに接続し、ドメインとユーザー名を含める必要がある場合。毎回UPN形式に固執すると、最終的にサポートの呼び出しが少なくなります。
Host\usernameもちろん、ADのないドメインはありません）
これら2つの間に明確な違いがあり、99％のユーザーのみが問題を抱えることはありません。違いとそのような問題がいつ発生するかを説明しようとします。
fileshareにアクセスするときにdomain \ usernameを使用すると、DNSは最初にドメインを解決してからユーザー名を確認します。username @ domainを使用すると、ユーザーがACL（アクセス制御リスト）にアクセスしているかどうかが直接確認されます。だからあなたが考えるかもしれないことは何が問題なのか...まあ、これを想像してください：
DC01という名前の1つのドメインコントローラーとすべてのクライアントがDNSを取得し、このドメインに属します。移行したいが、誰かが同じ名前の別のサーバーを追加した。後者のサーバーもDCになるため、ローカルSAMはもう使用されず、ファイル共有もあります。
ユーザーがサーバーに接続すると、資格情報の入力が求められます。domain \ usernameを使用する場合、新しいドメインを使用する代わりに現在のドメインを最初に確認し、ファイル共有上の新しいドメインのアカウントを使用します。そのため、現在のDCを見つけてユーザー名を確認しても、それは見つかりません。（ユーザー名とパスワードが見つかり、まったく同じであっても、ACLで許可されているかどうかを確認するためにユーザー名を使用せず、SIDを使用するため、機能しません。sidはADでのユーザー作成時間と1兆分の1の変化があり、それが同じであるということです。