Có sự khác biệt nào giữa DOMAIN \ username và username@domain.local không?

Tôi đang cố gắng khắc phục lỗi xác thực tối nghĩa và cần một số thông tin cơ bản.

• Có sự khác biệt nào giữa cách Windows (và các chương trình như Outlook) xử lý DOMAIN\usernamevà username@domain.localkhông?

• Các điều khoản thích hợp cho hai định dạng tên người dùng là gì?

• Chỉnh sửa : Cụ thể, có bất kỳ sự khác biệt nào trong cách Windows xác thực hai định dạng tên người dùng không?

Giả sử bạn có môi trường Active Directory:

Tôi tin rằng định dạng dấu gạch chéo ngược DOMAIN \ USERNAME sẽ tìm kiếm tên miền DOMAIN cho một đối tượng người dùng có Tên tài khoản SAM là USERNAME.

Tên người dùng định dạng UPN tên miền @ sẽ tìm kiếm rừng cho một đối tượng người dùng có Tên nguyên tắc người dùng là tên người dùng @ tên miền.

Bây giờ, thông thường , tài khoản người dùng có Tên tài khoản SAM của USERNAME có UPN là USERNAME @ DOMAIN, do đó, định dạng phải định vị cùng một tài khoản, ít nhất là với điều kiện AD có đầy đủ chức năng. Nếu có vấn đề sao chép hoặc bạn không thể truy cập danh mục toàn cầu, định dạng dấu gạch chéo ngược có thể hoạt động trong trường hợp định dạng UPN sẽ thất bại. Cũng có thể có các điều kiện (bất thường) theo đó áp dụng ngược lại - có lẽ nếu không có bộ điều khiển miền nào có thể đạt được cho miền đích chẳng hạn.

Tuy nhiên: bạn cũng có thể định cấu hình rõ ràng tài khoản người dùng để có UPN có thành phần tên người dùng khác với Tên tài khoản SAM và thành phần tên miền khác với tên miền.

Tab Tài khoản trong Active Directory Users and Computer hiển thị UPN dưới tiêu đề "Tên đăng nhập người dùng" và Tên tài khoản SAM dưới tiêu đề "Tên đăng nhập người dùng (trước Windows 2000)". Vì vậy, nếu bạn gặp rắc rối với những người dùng cụ thể, tôi sẽ kiểm tra xem không có bất kỳ sự khác biệt nào giữa hai giá trị này.

Lưu ý: có thể các tìm kiếm bổ sung được thực hiện nếu tìm kiếm tôi mô tả ở trên không tìm thấy tài khoản người dùng. Ví dụ: có lẽ tên người dùng được chỉ định được chuyển đổi sang định dạng khác (theo cách rõ ràng) để xem liệu điều đó có tạo ra sự trùng khớp hay không. Cũng phải có một số thủ tục để tìm tài khoản trong các miền đáng tin cậy không có trong rừng. Tôi không biết nơi nào / liệu hành vi chính xác được ghi lại.

Chỉ cần xử lý sự cố thêm, các máy khách Windows sẽ mặc định thông tin bộ đệm về các thông tin đăng nhập tương tác thành công, để bạn có thể đăng nhập vào cùng một máy khách ngay cả khi thông tin tài khoản người dùng của bạn trong Active Directory không thể truy cập được.

Tôi có thể được sửa chữa về điều này, nhưng thực sự không có nhiều sự khác biệt.

Tên miền \ Người dùng là định dạng đăng nhập "cũ", được gọi là tên đăng nhập cấp thấp . Còn được biết đến với tên SAMAccountName và tên đăng nhập trước Windows 2000 .

User@Domain.com là UPN - Tên hiệu trưởng người dùng . Đó là "ưa thích", định dạng đăng nhập mới hơn. Đó là tên đăng nhập kiểu Internet, sẽ ánh xạ tới tên email của người dùng. ( Ref. Tại MSDN )

Những lý do để đăng nhập bằng UPN tôi nghĩ phần lớn là mỹ phẩm - theo giả thuyết họ cung cấp cho người dùng trong công ty của bạn một tên duy nhất để đăng nhập vào máy trạm của họ, nơi cũng có thể đóng vai trò là địa chỉ email công ty của họ.

chỉnh sửa: Công phu hơn - một ưu điểm khác của UPN là bạn có thể thiết lập nhiều hơn một UPN hợp lệ để người dùng đăng nhập. Một lần nữa, phần lớn là mỹ phẩm. Nhưng điều quan trọng là không phải tất cả các ứng dụng đều tương thích với UPN và đó có thể là những gì bạn đang trải nghiệm.

chỉnh sửa # 2: Tôi thích câu trả lời của Harry Johnston bên dưới về hai định dạng tìm kiếm hơi khác nhau được thực hiện. Nó có ý nghĩa, và quan trọng nhất là nó thực sự có thể giải thích vấn đề của bạn. :)

Định dạng gạch chéo ( DOMAIN\username) thực sự NetBIOStương đương với tên DNS ( domain.mycompany.local) của tên miền .
Các NetBIOStên được giới hạn ở 15 ký tự và không thể chứa dấu chấm, dấu gạch dưới, vv

Trang này giải thích chi tiết hơn:
* Jeff Schertz, 2012-08-20, Tìm hiểu các định dạng đặt tên thư mục hoạt động (Lưu trữ tại đây .)

Như đã đề cập bởi @ harry-johnston ở trên, nó thực sự chỉ là định dạng tương thích NT4 và Windows 2000 cũ nhưng nó dường như bị mắc kẹt như một định dạng yêu thích (ít loại hơn!). Cuối cùng, hỗ trợ cho định dạng cũ có thể đi từ Windows.

Có lẽ nên cho người dùng thói quen sử dụng định dạng UPN vì nó cũng tránh được các vấn đề khi họ gặp sự cố khi đăng nhập vào PC với tên người dùng của họ và không nhận ra rằng hộp đăng nhập Windows đã được mặc định là cục bộ Tên miền PC (ví dụ pc01\fred) hoặc khi chúng kết nối với các máy chủ máy tính từ xa khác nhau và phải nhớ bao gồm tên miền cũng như tên người dùng của chúng vì Remote Desktop Client có thể lưu trữ một tên miền đã sử dụng trước đó. Bám sát định dạng UPN mỗi lần chỉ khiến cho các cuộc gọi hỗ trợ ít hơn cuối cùng.

Có một sự khác biệt giữa hai người đó, chỉ 99% người dùng sẽ không gặp vấn đề gì với nó. Tôi sẽ cố gắng giải thích sự khác biệt và khi một vấn đề như vậy có thể xảy ra.

Nếu bạn sử dụng tên miền \ tên người dùng khi bạn cố truy cập vào một tệp tin thì DNS trước tiên sẽ giải quyết tên miền và sau đó kiểm tra tên người dùng. Nếu bạn sử dụng tên người dùng @ domain thì nó sẽ trực tiếp kiểm tra xem người dùng có trong ACL (danh sách kiểm soát truy cập) và có quyền truy cập hay không. Vì vậy, vấn đề gì bạn có thể nghĩ ... tốt, hình ảnh này:

1 bộ điều khiển miền có tên DC01 và tất cả các máy khách nhận được dns và nằm trong miền này. Bạn muốn di chuyển và ai đó đã thêm một máy chủ khác có cùng tên. Máy chủ thứ hai cũng sẽ trở thành một DC để SAM cục bộ sẽ không được sử dụng nữa và cũng có chia sẻ tệp.

Khi người dùng sẽ kết nối với máy chủ, họ sẽ được nhắc nhập thông tin đăng nhập. Nếu bạn sử dụng tên miền \ tên người dùng, trước tiên, nó sẽ kiểm tra tên miền hiện tại thay vì sử dụng tên miền mới và chúng tôi đã sử dụng các tài khoản từ tên miền mới trên chia sẻ tệp. Vì vậy, một khi nó đã tìm thấy dc hiện tại và kiểm tra tên người dùng thì không thể tìm thấy. (ngay cả khi tên người dùng và mật khẩu được tìm thấy và chính xác giống như vậy, nó sẽ không hoạt động vì nó sẽ không sử dụng tên người dùng để xác minh nếu nó được cho phép trong ACL nhưng nó sẽ sử dụng SID. Sid sẽ được tạo tại thời gian tạo người dùng trong AD và bạn có 1 thay đổi trong một nghìn tỷ đồng, đó là như nhau, tuyệt vời huh :-P).