RE: [ActiveDir] Shared Access in win xp
Client OS (wxp w2k) and w2k3 web edition only accept 10 SMB connections. For more smb connection you need w2k/w2k3 server editions. It is all about licensing/pricing, otherwise people would use WXP as their file/print server. Jorge -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: 3/5/2005 3:37 AM Subject: [ActiveDir] Shared Access in win xp Hi all. Is there any way to sharing folder in Windows XP Professional For more than 10users in a Peer to Peer network or Workgroup enviornment. I mean is it possible to access that folder by 15 or 20 people at the same point of time. Thanks! Rakesh Jakhar _ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain membership? Otherwise, I don't see how you are going to get any of the options to work. You would instead need duplicate synchronized accounts in ADAM with the internal AD users' passwords to make it work and then you are getting in password capture and stuff (icky). We use IPSEC to do domain membership in the DMZ and it works pretty well for us (although it is a bit of a PITA). Another thing I can think of is perhaps using LDAP bind (simple or SASL or both) over SSL/LDAP and putting ADAM inside the DMZ. Then, you poke a hole in the firewall for port 636 between these two IP addresses. Eric will probably weigh in this as well. Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 10:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
If I understand what you are asking Rick, I don't think you can do any bind BUT a SASL bind for a local Windows user in ADAM. I expect this would work fine with a machine not in a domain otherwise that would be very limited in usefulness. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 11:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
Ok, now you made me have to go and test it! This doesn't make sense to me. Report back shortly. I could be completely wrong but I think that would limit usefulness a little too much. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 11:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain membership? Otherwise, I don't see how you are going to get any of the options to work. You would instead need duplicate synchronized accounts in ADAM with the internal AD users' passwords to make it work and then you are getting in password capture and stuff (icky). We use IPSEC to do domain membership in the DMZ and it works pretty well for us (although it is a bit of a PITA). Another thing I can think of is perhaps using LDAP bind (simple or SASL or both) over SSL/LDAP and putting ADAM inside the DMZ. Then, you poke a hole in the firewall for port 636 between these two IP addresses. Eric will probably weigh in this as well. Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 10:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
I wouldn't use SASL for this myself. I don't believe I'd want my customer data in the windows SAM as that could run into scalability issues (that's why we went with AD in a distributed fashion vs. local SAM right?) From your description, a simple bind is the way to go. You'll want to secure the transmission of course and lock down which machines can gain access to the server/port hosting the ADAM instance. For what it's worth, this would be the same as in the case of using SunLDAP or OpenLDAP because they are just doing a bind to an identity store and then possibly looking at the group membership for authorization purposes. My $0.04 anyway, al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 11:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
Joe, Thanks for the feedback. This is pretty much what I had concluded, after doing some testing last night after this bugged me to the point that I couldn't go to bed. IPSec is an option, but I won't get it past InfoSec. They flat refuse to allow domain-direct communications to the DMZ (or from, more correctly). Let me elaborate for a minute: We have a three layer DMZ, our external (Public DMZ), the middle layer (Private DMZ), and the internal network. By policy, incoming communications can only communicate one layer at a time. So, in the solution that I've proposed - The Portal Web server sits in the Public DMZ and ADAM sits in the Private. Getting firewall and / or IPSec set up for 389 / 686 traffic is not an issue. Setting up traffic from ADAM to the internal, specifically DCs is not an issue (please - don't ask how that's different than a domain member sitting in the DMZ - I've suffered aneurysms trying to convince InfoSec that the difference is semantics). One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Thanks much! -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain membership? Otherwise, I don't see how you are going to get any of the options to work. You would instead need duplicate synchronized accounts in ADAM with the internal AD users' passwords to make it work and then you are getting in password capture and stuff (icky). We use IPSEC to do domain membership in the DMZ and it works pretty well for us (although it is a bit of a PITA). Another thing I can think of is perhaps using LDAP bind (simple or SASL or both) over SSL/LDAP and putting ADAM inside the DMZ. Then, you poke a hole in the firewall for port 636 between these two IP addresses. Eric will probably weigh in this as well. Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 10:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info :
RE: [ActiveDir] ADAM - Clarification
Nuts! I had to go back and read the part about the internal users also gaining access with internal credentials. So to me this screams multiple instances of a directory 1 for internal and one for external users. The internal users DB would use SASL bind techniques and would have to be able to talk to the AD for authentication. The external users would only use simple bind techniques. Saying that, I haven't tried it, but I'm wondering if you could mix and match: some that are AD proxy objects (I know you said it's out, but..) and some that are not. What would the messy code look like then? Another option is to use password synchronization. The downside is that you would be putting passwords for internal resources into the DMZ under the current concept. The identity store is not the important factor here; the solution requirements and your security policy are what will likely drive this to some sort of unique solution. ADAM is just a lot easier and more integrated to work with than the other identity stores. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Sunday, March 06, 2005 11:28 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification I wouldn't use SASL for this myself. I don't believe I'd want my customer data in the windows SAM as that could run into scalability issues (that's why we went with AD in a distributed fashion vs. local SAM right?) From your description, a simple bind is the way to go. You'll want to secure the transmission of course and lock down which machines can gain access to the server/port hosting the ADAM instance. For what it's worth, this would be the same as in the case of using SunLDAP or OpenLDAP because they are just doing a bind to an identity store and then possibly looking at the group membership for authorization purposes. My $0.04 anyway, al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 11:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
Al, Thanks for the feedback. In reality, I don't think that the code, etc. for ADAM SecPrinc vs. AD related will be that bad. If the account is supposed to exist, then the user object is going to have to be in ADAM one way or the other. So, check first for a user object with a password in ADAM. Fail that, check for a userProxy object. Succeed and on to AD for AuthN (with the SID and Password in tow) or fail with the username does not exist or incorrect password message (or something equally ambiguous). However, I could be horribly wrong (Like _that's_ never happened before) -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Sunday, March 06, 2005 10:40 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Nuts! I had to go back and read the part about the internal users also gaining access with internal credentials. So to me this screams multiple instances of a directory 1 for internal and one for external users. The internal users DB would use SASL bind techniques and would have to be able to talk to the AD for authentication. The external users would only use simple bind techniques. Saying that, I haven't tried it, but I'm wondering if you could mix and match: some that are AD proxy objects (I know you said it's out, but..) and some that are not. What would the messy code look like then? Another option is to use password synchronization. The downside is that you would be putting passwords for internal resources into the DMZ under the current concept. The identity store is not the important factor here; the solution requirements and your security policy are what will likely drive this to some sort of unique solution. ADAM is just a lot easier and more integrated to work with than the other identity stores. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Sunday, March 06, 2005 11:28 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification I wouldn't use SASL for this myself. I don't believe I'd want my customer data in the windows SAM as that could run into scalability issues (that's why we went with AD in a distributed fashion vs. local SAM right?) From your description, a simple bind is the way to go. You'll want to secure the transmission of course and lock down which machines can gain access to the server/port hosting the ADAM instance. For what it's worth, this would be the same as in the case of using SunLDAP or OpenLDAP because they are just doing a bind to an identity store and then possibly looking at the group membership for authorization purposes. My $0.04 anyway, al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 11:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive:
RE: [ActiveDir] ADAM - Clarification
Oh wait a minute, I came back and reread Rick's original post again and thenJoeK's post again.JoeK do you mean you need domain membership for the SASL auth of the AD users or SASL auth for both AD and the local users? I initially read it as SASL bind for local users.If for the AD users, I think you would fall down before the actual bind time... You couldn't really add the user to ADAM in the first place without hacking in an FSP with an unresolvable SID (unresolvable that is to the ADAM Instance as it wouldn't know where to go to resolve the SID unless you could code in a resolver). Plus when you hit it with an Auth, even if it didn't use LogonUser in the background, how would it know where to go if you say specify RickDom\King and there is no trust to RickDom? ADAM can't assume that RickDom is rickdom.com or anything else so it has no place to even start to make DNS lookups. I guess it could do a WINS lookup of RICKDOM, translate to an IP, connect to the IP and go from there but man that would be a train wreck of possible issues.Anyway, I tested out the scenario of local users and SASL bind to local users seems to work fine. Here is the quick summary of it, if you want the full details of what I did, I can email that as well. 2k38500 is a standalone K3 Server that shares a network, a DNS Server, a WINS Server, and the domain zone. Even changing the domain zone it still works. It bothers me that you can't seem to do a simple bind to a local Windows user. F:\adfind -h 2k38500 -b OU=Users,DC=adam,DC=joeware2,DC=net -dn -u localuser -up LocalUserPassword AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005 Using server: 2k38500.joe.comDirectory: Active Directory Application Mode dn:OU=users,DC=adam,DC=joeware2,DC=netdn:CN=adamuser,OU=users,DC=adam,DC=joeware2,DC=net 2 Objects returned No. Time Source SPort Destination DPort Protocol Info 8 0.006691 fastmofo.joe.com 3401 2k38500.joe.com ldap LDAP MsgId=3 Bind Request, DN=(null) Frame 8 (134 bytes on wire, 134 bytes captured)Ethernet II, Src: 00:0c:6e:74:3a:27, Dst: 00:06:25:43:c6:e0Internet Protocol, Src Addr: fastmofo.joe.com (192.168.0.102), Dst Addr: 2k38500.joe.com (192.168.0.110)Transmission Control Protocol, Src Port: 3401 (3401), Dst Port: ldap (389), Seq: 351, Ack: 1898, Len: 80Lightweight Directory Access Protocol, Bind Request Message Id: 3 Message Type: Bind Request (0x00) Message Length: 65 Response In: 9 Version: 3 DN: (null) Auth Type: SASL (0x03) Mechanism: GSS-SPNEGO GSS-API Token GSS-API Unknown header (cls=1, con=0, tag=14) 00 06 25 43 c6 e0 00 0c 6e 74 3a 27 08 00 45 00 ..%Cnt:'..E.0010 00 78 d4 9f 40 00 80 06 a3 bb c0 a8 00 66 c0 a8 [EMAIL PROTECTED]..0020 00 6e 0d 49 01 85 2c 61 93 45 e4 5a 17 ed 50 18 .n.I..,a.E.Z..P.0030 ff ff 82 8f 00 00 30 84 00 00 00 4a 02 01 03 60 ..0J...`0040 84 00 00 00 41 02 01 03 04 00 a3 84 00 00 00 36 A..60050 04 0a 47 53 53 2d 53 50 4e 45 47 4f 04 28 4e 54 ..GSS-SPNEGO.(NT0060 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 00 00 LMSSP...0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 01 0080 28 0a 00 00 00 0f (. No. Time Source SPort Destination DPort Protocol Info 9 0.007756 2k38500.joe.com ldap fastmofo.joe.com 3401 LDAP MsgId=3 Bind Result, saslBindInProgress Frame 9 (258 bytes on wire, 258 bytes captured)Ethernet II, Src: 00:06:25:43:c6:e0, Dst: 00:0c:6e:74:3a:27Internet Protocol, Src Addr: 2k38500.joe.com (192.168.0.110), Dst Addr: fastmofo.joe.com (192.168.0.102)Transmission Control Protocol, Src Port: ldap (389), Dst Port: 3401 (3401), Seq: 1898, Ack: 431, Len: 204Lightweight Directory Access Protocol, Bind Result Message Id: 3 Message Type: Bind Result (0x01) Message Length: 189 Response To: 8 Time: 0.001065000 seconds Result Code: saslBindInProgress (0x0e) Matched DN: (null) Error Message: (null) GSS-API Token GSS-API Unknown header (cls=1, con=0, tag=14) 00 0c 6e 74 3a 27 00 06 25 43 c6 e0 08 00 45 00 ..nt:'..%CE.0010 00 f4 b4 11 40 00 80 06 c3 cd c0 a8 00 6e c0 a8 [EMAIL PROTECTED]..0020 00 66 01 85 0d 49 e4 5a 17 ed 2c 61 93 95 50 18 .f...I.Z..,a..P.0030 42 c2 e2 d4 00 00 30 84 00 00 00 c6 02 01 03 61 B.0a0040 84 00 00 00 bd 0a 01 0e 04 00 04 00 87 82 00 b2 0050 4e 54 4c 4d 53 53 50 00 02 00 00 00 0e 00 0e 00 NTLMSSP.0060 38 00 00 00 15 82 8a e2 17 08 c7 17 8c c5 dd cf 8...0070 00 00 00 00 00 00 00 00 6c 00 6c 00 46 00 00 00 l.l.F...0080 05 02 ce 0e 00 00 00 0f 32 00 4b 00 33 00 38 00 2.K.3.8.0090 35 00 30 00 30 00 02 00 0e 00 32 00 4b 00 33 00 5.0.0.2.K.3.00a0 38 00 35 00 30 00 30 00 01 00 0e 00 32 00 4b 00 8.5.0.0.2.K.00b0 33 00 38 00 35 00 30 00 30 00 04 00 1e 00 32 00 3.8.5.0.0.2.00c0 6b 00 33 00 38 00 35 00 30 00 30 00 2e 00 6a 00 k.3.8.5.0.0...j.00d0 6f 00 65 00 2e 00 63 00 6f 00 6d 00 03 00 1e 00 o.e...c.o.m.00e0 32 00 6b 00 33 00 38
RE: [ActiveDir] ADAM - Clarification
Scale could be an issue. However I would say for many companies, being able to handle 60,000-80,000 users in that way would be more than sufficient. Actually I think towards the end of NT they had even published info on how to get up to 100k into NT4. I ran solid on NT4 with a couple of 80K+ user domains. Scared the crap out of me but worked. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Sunday, March 06, 2005 11:28 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification I wouldn't use SASL for this myself. I don't believe I'd want my customer data in the windows SAM as that could run into scalability issues (that's why we went with AD in a distributed fashion vs. local SAM right?) From your description, a simple bind is the way to go. You'll want to secure the transmission of course and lock down which machines can gain access to the server/port hosting the ADAM instance. For what it's worth, this would be the same as in the case of using SunLDAP or OpenLDAP because they are just doing a bind to an identity store and then possibly looking at the group membership for authorization purposes. My $0.04 anyway, al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 11:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Talk to for what? If it isn't a member, it don't give a hoot about any domains. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 11:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Joe, Thanks for the feedback. This is pretty much what I had concluded, after doing some testing last night after this bugged me to the point that I couldn't go to bed. IPSec is an option, but I won't get it past InfoSec. They flat refuse to allow domain-direct communications to the DMZ (or from, more correctly). Let me elaborate for a minute: We have a three layer DMZ, our external (Public DMZ), the middle layer (Private DMZ), and the internal network. By policy, incoming communications can only communicate one layer at a time. So, in the solution that I've proposed - The Portal Web server sits in the Public DMZ and ADAM sits in the Private. Getting firewall and / or IPSec set up for 389 / 686 traffic is not an issue. Setting up traffic from ADAM to the internal, specifically DCs is not an issue (please - don't ask how that's different than a domain member sitting in the DMZ - I've suffered aneurysms trying to convince InfoSec that the difference is semantics). One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Thanks much! -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain membership? Otherwise, I don't see how you are going to get any of the options to work. You would instead need duplicate synchronized accounts in ADAM with the internal AD users' passwords to make it work and then you are getting in password capture and stuff (icky). We use IPSEC to do domain membership in the DMZ and it works pretty well for us (although it is a bit of a PITA). Another thing I can think of is perhaps using LDAP bind (simple or SASL or both) over SSL/LDAP and putting ADAM inside the DMZ. Then, you poke a hole in the firewall for port 636 between these two IP addresses. Eric will probably weigh in this as well. Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 10:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers. And, I've read thoroughly the Tech Refs and some other words from Joe Kaplan on the subject. I also took a look at ~Eric's blog for a post or two, which were helpful. The problem - to the point - is this. The Portal web server, where the LDAP AuthN calls come from is in the external perimeter. There are four options that are indicated in the docs: # Anonymous bind (no password) # Simple LDAP bind (ADAM security principal with password) # SASL binding (Windows security principal in local computer or AD) # Bind redirection (security principal is in ADAM, but has a reference to an AD security principal) Bind redirection (userProxy) has a domain membership requirement for the machine on which ADAM resides. Given that the security requirements won't allow this, this one is out. However, I can't seem to find anything that indicates the requirements for SASL bind. Is this an option? The bottom line is that I want to use ADAM, but have run into this brick wall. What options do I have, as I've exhausted the resources that I have at my disposal, at this point in time at least :) Rick Kingslan MCSE, MCSA, MCT, CISSP Microsoft MVP: Windows Server / Directory Services Windows Server / Rights Management Windows Security (Affiliate) Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food List info : http://www.activedir.org/List.aspx List FAQ:
[ActiveDir] Traveling Users Unable to Authenticate to AD
Statement of Problem: Laptop users from MYCO (on Active Directory) traveling to OTHERCO (on Novell NDS but not AD) are unable to authenticate to MYCO.US.PARENT.COM Active Directory. Required Result: To enable laptop users from MYCO traveling to OTHERCO to authenticate to MYCO.US.PARENT.COM Active Directory, get their mapped drives, access to file shares, etc. over the WAN. Background Information: Overseas parent company does not allow delegation/forwarding from/to their UNIX BIND 9.2 DNS servers to W2k3 Active Directory DNS; Parent company (not on Active Directory) is authoritative for DNS root zone: PARENT.COM. Neither name server records nor SOA records are allowed to be populated in any of the parent company-hosted DNS zones; Parent company is also authoritative 1st level DNS zone: US.PARENT.COM (this zone is hosted overseas); Our companys dual-authoritative AD-integrated and UNIX DNS zone: MYCO.US.PARENT.COM (from parent company perspective the UNIX servers are authoritative, from our companys internal client/server systems W2k3 DNS is authoritative); The W2k3 Active Directory DNS servers conditionally forward queries for PARENT.COM and all child domains of PARENT.COM other than MYCO.US.PARENT.COM to MYCOs UNIX BIND DNS servers. This has worked fine. Affiliated, WAN-connected US company with Novell DNS zone OTHERCO.US.PARENT.COM (unable to conditionally forward and not in budget to perform necessary upgrade to OS to enable this feature); Within a year, both the parent company and otherco will be migrated to a globally-unified Active Directory implementation in a completely different namespace so that this will cease to be a problem. But we cannot let the problem persist for a year. Discussion: I believe the reason that laptop users from MYCO traveling to OTHERCO are unable to authenticate to MYCO.US.PARENT.COM Active Directory is that the OTHERCO DNS server sends packets to the US.PARENT.COM zone which looks to the UNIX BIND servers of MYCO.US.PARENT.COM for resolutionthe UNIX BIND servers have the A records for the W2k3 DC DNS servers dont have the SRV and LDAP records necessary to enable authentication to the MYCO DCs running DNS. Without spending a lot of $$ and without having to deploy an additional MYCO DC/DNS server at otherco, we need a temporary workaround so that the traveling users can authenticate.
[ActiveDir] WINS
Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] WINS
Yep, exchange 2003 still depends on NetBIOS (WINS). See http://support.microsoft.com/?id=837391 Jorge -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: 3/6/2005 6:55 PM Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] WINS
Outlook shouldn't need it unless your DNS has fallen down. Exchange server itself needs it. Well to be strictly correct, it needs NetBIOS name resolution, you can do that with Broadcast, LMHOSTS files, or WINS. Of the three, unless you are in the smallest of environments you probably want to use WINS. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Tock Sent: Sunday, March 06, 2005 12:56 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert MezzoneSent: Sunday, March 06, 2005 12:20 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5.Robert-Original Message-From: [EMAIL PROTECTED] [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.orgSent: Sun Mar 06 12:55:30 2005Subject: [ActiveDir] WINSIs WINS still needed for exchange 2003? Some have said outlook still needsWINS.List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] LDAP and related Exchange question
I don't think I am related to Denise Richards, it would be perfectly legal. I don't think I need to worry about Charlie Sheen, he is a punk. :o) On the Yamila Diaz-Rahi and the dash... I don't think we will ever know. She doesn't inspire me such as the likes of Eliza Dushku and Denise Richards. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 2:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question Depends on the country and the local culture. Some countries, men do change their names based on marital events. In the US for example, I've seen it. The bigger question would be why Joe would want to marry family what would that do to the whole unique naming thing when Eliza found out and, er changed him? :) This might make a good soap opera though. We'll just have to make sure that Joe stays unique so we can identify when he comes back from the corrective actions applied. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 04, 2005 2:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question Let's say after a few years I marry Denise Richards... While you are still married to Eliza Dushku ???. That would cause a lot of complications. For example, it would be UNIQUE across the North American Realm, but not in, say, African Realm. It will create illegal GUIDs in a lot of Realms, while it will be VALID in a lot of other Realms. That would lead to more collision. We don't want that now, do we? Then I go back to jricha34 Last time I saw you, you WERE male? I didn't think males last names change based on their marital statuses. You are not implying a surgical operation, here, are you? See, this is indeed causing a lot of collisions. ROFLM(F-ing)AO Deji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, March 04, 2005 10:58 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question Assign a new unique name and link it to the old name and the old name is still never reused except in the case that the person's name changes back which has happened. Say if I got married to Eliza Dushku, my new ID would be something like jdushku3 or something. Let's say after a few years I marry Denise Richards... Then I go back to jricha34. However jdushku3 would always still only reference me. Their biggest issue is that they are currently limited to 3-8 characters. At some point they will have to expand that range. I think it depends on what systems it has to go onto, what the flexibility is of those systems, and what you want to be the master of the whole thing. If you can make AD the master source and the other directories/stores/etc can accept a guid then it would work. Otherwise, you are correct, you need to come up with some other unique mechanism. Basically look at the least flexible piece that has to stay long term and build from there. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 1:41 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question How did they handle people changing their names? I see the ID, but does that ID make sense when the user changes their name from Joe to 'They' or something along those lines? That goes back to the idea of coming up with a unique identifier that expands the horizon beyond the AD forest(s) and into the rest of the realm. I maintain that at some point in just about every country and every company, there is a unique identifier that ensures that person gets their proper compensation. Not that it couldn't be messed up, but you'd know quickly if your paycheck were lower than expected or paid to you in Yuan vs. Rubles if that's what you expected. This needs to stretch beyond AD from what I can tell. Is that an incorrect assumption Marcus? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, March 04, 2005 1:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question I would tend to agree, I think objectGUID would be fine though it is a pain to deal with since it is binary. Another thing to consider is to stop the random wonton creation of samaccountnames. When someone gets hired, they get assigned from one source their ID for use within the company. That ID is used everywhere and forever identifies that person and is never reused anywhere else in that company. Someother company gets merged in, everyone gets new SAM IDs from the same source. One company I worked for I am the
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Seems we need to get to the bottom of this. It seems that exchange just might need WINS to do netbios resolution at some instance. Now what is that instance? It seems not everybody will necessarily come across that instance. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Van Noy, Glen Sent: Sunday, March 06, 2005 12:28 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 12:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS I'm really just a lurker on this list, but, last week I ran head-first intoaWINS/2003 Exchange issue adding a second Exchange Server into anew Exchange Administrative groupin one of the domains within our AD forest. I'm not ruling out other DNS/Exchange connectivity issues, but, once we fixed a WINS push/pull replication issue between the two exchange domains, our Exchange Routing group connector started to function properly. I too would love a definitive answer to how Exchange is using WINS. zach teton county sheriff's office From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael TockSent: Sunday, March 06, 2005 11:41 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] WINS Seems we need to get to the bottom of this. It seems that exchange just might need WINS to do netbios resolution at some instance. Now what is that instance? It seems not everybody will necessarily come across that instance. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Van Noy, GlenSent: Sunday, March 06, 2005 12:28 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert MezzoneSent: Sunday, March 06, 2005 12:20 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5.Robert-Original Message-From: [EMAIL PROTECTED] [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.orgSent: Sun Mar 06 12:55:30 2005Subject: [ActiveDir] WINSIs WINS still needed for exchange 2003? Some have said outlook still needsWINS.List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS I'll look when I get home. I remember reading about it a year ago and was bummed out. I thought I could rid myself of wins. I did run Exchange without wins for a while but added it being MS recommends it. Only thing is it didn't give a reason why. Just said it was needed. It may not be the deployment guide, it's in one of the three recommended reading documents, deployment, admin guide and I forget the name of the other doc (planning an exchange environment?) Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 13:27:42 2005 Subject: RE: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003 setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 12:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Okay, I will look into it also. We removed WINS from our forest about a year ago and have seen no ill effects. We are not real big, 2000 exchange accounts and 25000 users, but everything seems to be running fine without it. Over the next few months, we are going to add student accounts to Exchange, so we will end up with quite a few more accounts. If I find out anything I will post it. Thanks, glen The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert MezzoneSent: Sunday, March 06, 2005 1:20 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] WINS I'll look when I get home. I remember reading about it a year ago and was bummed out. I thought I could rid myself of wins. I did run Exchange without wins for a while but added it being MS recommends it. Only thing is it didn't give a reason why. Just said it was needed. It may not be the deployment guide, it's in one of the three recommended reading documents, deployment, admin guide and I forget the name of the other doc (planning an exchange environment?)Robert-Original Message-From: [EMAIL PROTECTED] [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.orgSent: Sun Mar 06 13:27:42 2005Subject: RE: [ActiveDir] WINSJust curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003 setup and we don't have WINS configured on our domain.glen[EMAIL PROTECTED]The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 12:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
Ok, let's review and recap to make sure we are on the same page: - Rick wants to authenticate extranet users as users in the ADAM store (requires simple bind) - Rick also wants to authenticate AD users in the internal forest The ADAM users require simple bind. AD users use either SASL bind with pass through auth or simple bind with userProxy objects. To authenticate AD users in either scenario, the ADAM server has to be a domain member in a domain that has a trust that will allow the authentication. ADAM can't be workgroup in this scenario. Rick can put ADAM in the internal DMZ and allow port 636 traffic from the external DMZ, so ADAM should be able to provide LDAP authN services to the server(s) in the outer DMZ. Also, Rick can get ADAM to DC traffic approved with ADAM in the internal DMZ. Therefore, it looks like the question comes down to whether he wants to use a mix of simple and SASL with pass through or do all simple bind, userProxy objects and bind redirection. The latter will require some sync to get the userProxy objects created. I'm not sure I know enough to know which one is the way to go, but it looks like either is possible at this point. Did I miss something? Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 11:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Talk to for what? If it isn't a member, it don't give a hoot about any domains. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 11:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Joe, Thanks for the feedback. This is pretty much what I had concluded, after doing some testing last night after this bugged me to the point that I couldn't go to bed. IPSec is an option, but I won't get it past InfoSec. They flat refuse to allow domain-direct communications to the DMZ (or from, more correctly). Let me elaborate for a minute: We have a three layer DMZ, our external (Public DMZ), the middle layer (Private DMZ), and the internal network. By policy, incoming communications can only communicate one layer at a time. So, in the solution that I've proposed - The Portal Web server sits in the Public DMZ and ADAM sits in the Private. Getting firewall and / or IPSec set up for 389 / 686 traffic is not an issue. Setting up traffic from ADAM to the internal, specifically DCs is not an issue (please - don't ask how that's different than a domain member sitting in the DMZ - I've suffered aneurysms trying to convince InfoSec that the difference is semantics). One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Thanks much! -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain membership? Otherwise, I don't see how you are going to get any of the options to work. You would instead need duplicate synchronized accounts in ADAM with the internal AD users' passwords to make it work and then you are getting in password capture and stuff (icky). We use IPSEC to do domain membership in the DMZ and it works pretty well for us (although it is a bit of a PITA). Another thing I can think of is perhaps using LDAP bind (simple or SASL or both) over SSL/LDAP and putting ADAM inside the DMZ. Then, you poke a hole in the firewall for port 636 between these two IP addresses. Eric will probably weigh in this as well. Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, March 05, 2005 10:57 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] ADAM - Clarification All - We have a Web Portal solution that has the option to use LDAP v3 for AuthN calls. Obviously, we want to use AD for our internal customers, and implement user objects that would not reside in AD for our external customers. In my mind, this screams ADAM. I can create the user objects in ADAM for the external customers.
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS I can't recall all of the circumstances but the ones I have personally run into or been involved in seemed to be around configuring and installing things. The one that was most fun involved the MCS guys working with the Exchange admins to load something or other on some server and I looked at the trace and the server would get a DNS name back from its initial query, then it would chop it down to a short name and try to resolve against WINS. The DC it was trying to hit was a hub DC so wasn't in the server WINS architecture [1] and therefore couldn't be resolved. It was picking the wrong DC in the first place because the subnet the server was in wasn't defined and it was picking some random site. The fun part was the MCS guys had been working on it for some time and finally called me. I told them to get a trace of it and that I expected it was probably WINS and I would be on my way to take a look. They didn't believe it was WINS but as soon as I got there and saw the traceI saw the WINS failure in a couple of seconds (litterally). Note that if you have joined namespace, i.e. DNS of AD matches DNS of servers and you have a single domain or multiple search suffixes for all domains involved, the standard process of falling through netbios/wins resolution to DNS may work for you and you are working simply by sheer happiness of that accident. joe [1] This is a hub and spoke with one way replication which probably will be extremely alien to anyone who hasn't run a large environment. In a larger environment (over 25 DCs) you simply do not publish all domain controllerson all of yourWINS servers if you want to have a good handle on things. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael TockSent: Sunday, March 06, 2005 1:41 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] WINS Seems we need to get to the bottom of this. It seems that exchange just might need WINS to do netbios resolution at some instance. Now what is that instance? It seems not everybody will necessarily come across that instance. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Van Noy, GlenSent: Sunday, March 06, 2005 12:28 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert MezzoneSent: Sunday, March 06, 2005 12:20 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5.Robert-Original Message-From: [EMAIL PROTECTED] [EMAIL PROTECTED]To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.orgSent: Sun Mar 06 12:55:30 2005Subject: [ActiveDir] WINSIs WINS still needed for exchange 2003? Some have said outlook still needsWINS.List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Traveling Users Unable to Authenticate to AD
Although it is not allowed (why?) there are two possibilities here as I can see... (1) On the UNIX zone MYCO.US.PARENT.COM delegate the underscore domains beneath to the AD/DNS servers as seperate zones. You'll need to do the same for the AD/DNS servers. This is needed so that the UNIX servers as the AD/DNS servers can find the underscore DNS domains. (not that beautifull but it works) You could also remove the MYCO.US.PARENT.COM zone on the AD/DNS servers and leave the underscore DNS domains as zones. Caveat here (of the latter issue) is you must also change the IP address of DNS servers on all servers/clients that should be queried to the IP address of the UNIX servers. Not recommended because these are overseas (2) On the UNIX servers remove the zone MYCO.US.PARENT.COM and delegate it to the AD/DNS servers (I would prefer this one) Hope this helps for you Cheers, Jorge -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Cc: [EMAIL PROTECTED] Sent: 3/6/2005 6:52 PM Subject: [ActiveDir] Traveling Users Unable to Authenticate to AD Statement of Problem: Laptop users from MYCO (on Active Directory) traveling to OTHERCO (on Novell NDS but not AD) are unable to authenticate to MYCO.US.PARENT.COM Active Directory. Required Result: To enable laptop users from MYCO traveling to OTHERCO to authenticate to MYCO.US.PARENT.COM Active Directory, get their mapped drives, access to file shares, etc. over the WAN. Background Information: Overseas parent company does not allow delegation/forwarding from/to their UNIX BIND 9.2 DNS servers to W2k3 Active Directory DNS; Parent company (not on Active Directory) is authoritative for DNS root zone: PARENT.COM. Neither name server records nor SOA records are allowed to be populated in any of the parent company-hosted DNS zones; Parent company is also authoritative 1st level DNS zone: US.PARENT.COM (this zone is hosted overseas); Our company's dual-authoritative AD-integrated and UNIX DNS zone: MYCO.US.PARENT.COM (from parent company perspective the UNIX servers are authoritative, from our company's internal client/server systems W2k3 DNS is authoritative); The W2k3 Active Directory DNS servers conditionally forward queries for PARENT.COM and all child domains of PARENT.COM other than MYCO.US.PARENT.COM to MYCO's UNIX BIND DNS servers. This has worked fine. Affiliated, WAN-connected US company with Novell DNS zone OTHERCO.US.PARENT.COM (unable to conditionally forward and not in budget to perform necessary upgrade to OS to enable this feature); Within a year, both the parent company and otherco will be migrated to a globally-unified Active Directory implementation in a completely different namespace so that this will cease to be a problem. But we cannot let the problem persist for a year. Discussion: I believe the reason that laptop users from MYCO traveling to OTHERCO are unable to authenticate to MYCO.US.PARENT.COM Active Directory is that the OTHERCO DNS server sends packets to the US.PARENT.COM zone which looks to the UNIX BIND servers of MYCO.US.PARENT.COM for resolutionthe UNIX BIND servers have the A records for the W2k3 DC DNS servers don't have the SRV and LDAP records necessary to enable authentication to the MYCO DC's running DNS. Without spending a lot of $$ and without having to deploy an additional MYCO DC/DNS server at otherco, we need a temporary workaround so that the traveling users can authenticate. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
Good restate. I think that captures it all. The key being that the ADAM server must be a member of the internal domain. If it isn't, all users need to go into some store (whether local, ADAM, or spinning up AD in DMZ) in the DMZ. Personally, I am not a fan of hooking anything outside the LAN/WAN to an internal AD so for me. I would look at populating the needed info out to the DMZ either in an AD sitting in the DMZ specifically for that purpose or into ADAM itself - don't forget to use SSL so you don't pass clear text passwords. If the number of users was under 50-60k or maybe evey 80k I would consider pushing the user auth into the local SAM of the server. If using a DMZ AD or the local SAM then you can use secure binding without invoking SSL overhead. Considering the fact that you may want to add additional AD/AM servers at a later point for redundancy makes me think a DMZ AD may be the way to go unless you want to use SSL and AD/AM users. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 2:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Ok, let's review and recap to make sure we are on the same page: - Rick wants to authenticate extranet users as users in the ADAM store (requires simple bind) - Rick also wants to authenticate AD users in the internal forest The ADAM users require simple bind. AD users use either SASL bind with pass through auth or simple bind with userProxy objects. To authenticate AD users in either scenario, the ADAM server has to be a domain member in a domain that has a trust that will allow the authentication. ADAM can't be workgroup in this scenario. Rick can put ADAM in the internal DMZ and allow port 636 traffic from the external DMZ, so ADAM should be able to provide LDAP authN services to the server(s) in the outer DMZ. Also, Rick can get ADAM to DC traffic approved with ADAM in the internal DMZ. Therefore, it looks like the question comes down to whether he wants to use a mix of simple and SASL with pass through or do all simple bind, userProxy objects and bind redirection. The latter will require some sync to get the userProxy objects created. I'm not sure I know enough to know which one is the way to go, but it looks like either is possible at this point. Did I miss something? Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 11:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Talk to for what? If it isn't a member, it don't give a hoot about any domains. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 11:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Joe, Thanks for the feedback. This is pretty much what I had concluded, after doing some testing last night after this bugged me to the point that I couldn't go to bed. IPSec is an option, but I won't get it past InfoSec. They flat refuse to allow domain-direct communications to the DMZ (or from, more correctly). Let me elaborate for a minute: We have a three layer DMZ, our external (Public DMZ), the middle layer (Private DMZ), and the internal network. By policy, incoming communications can only communicate one layer at a time. So, in the solution that I've proposed - The Portal Web server sits in the Public DMZ and ADAM sits in the Private. Getting firewall and / or IPSec set up for 389 / 686 traffic is not an issue. Setting up traffic from ADAM to the internal, specifically DCs is not an issue (please - don't ask how that's different than a domain member sitting in the DMZ - I've suffered aneurysms trying to convince InfoSec that the difference is semantics). One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Thanks much! -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well. Essentially, it is calling LogonUser under the hood to authenticate Windows users on the ADAM box, so users need rights to log on locally for bind redirection. Do you have an option for IPSEC or something to enable domain
RE: [ActiveDir] ADAM - Clarification
The DMZ AD sounds like a good way to go for me too. Our security guys are pretty terrified of AD in the DMZ (we use IPSEC to deal with this), but it seems like it would save a lot of hassle. I don't personally deal with IPSEC, but it seems to have a suck factor reputation with the people here who do. I don't think I follow the users in the local SAM database thing you are talking about here. Where would that fall in with Rick's scenario? Would those be for the internal users or the external? Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 2:25 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Good restate. I think that captures it all. The key being that the ADAM server must be a member of the internal domain. If it isn't, all users need to go into some store (whether local, ADAM, or spinning up AD in DMZ) in the DMZ. Personally, I am not a fan of hooking anything outside the LAN/WAN to an internal AD so for me. I would look at populating the needed info out to the DMZ either in an AD sitting in the DMZ specifically for that purpose or into ADAM itself - don't forget to use SSL so you don't pass clear text passwords. If the number of users was under 50-60k or maybe evey 80k I would consider pushing the user auth into the local SAM of the server. If using a DMZ AD or the local SAM then you can use secure binding without invoking SSL overhead. Considering the fact that you may want to add additional AD/AM servers at a later point for redundancy makes me think a DMZ AD may be the way to go unless you want to use SSL and AD/AM users. joe This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
I don't have a problem with AD in the DMZ, I just wouldn't let it be connected to my internal AD either via trusts or the truly uncool idea of putting an internal AD DC in the DMZ. The idea of using the local SAM ID's is if you want secure auth but don't want to use the required SSL for AD/AM user auth and you don't want to set up an AD. You sync your users from internal AD, the ones you need out on the extranet, not necessarily all of them to the local machine's SAM database. Then you can use a secure bind to connect to ADAM using those local Windows users. Of course if you go so far as to put up AD in the DMZ, do you need AD/AM? Maybe, depends on what else you are intending to do. If you are putting in app specific data, I would recommend AD/AM over AD and just have the auth bump over to AD. Of course others would say use an app partition, I don't like app partitions in AD. I am old fashioned but I see AD as my NOS auth store, I want everything else to get away from it because I consider auth more important than everything else. I constantly have fights with Exchange folks who consider the directory as theirs. It used to be theirs, now it is mine, stop abusing it before I slap you and you need to get that crap out, at least the config container stuff. I recall once a long while back before AD/AM was announced to anyone I knew or at least anyone willing to talk to me about it and I was talking to some MS Dev person who was trying to tell me how cool app partions in the up and coming Windows .NET would be and would I use them personally or as part of the enterprise I managed or would I recommend their use. I was like, I don't like the idea at all, why don't you guys just get over it and build a standalone LDAP server app; you have everything you need already. Why try to make AD the end all be all. I didn't believe it would ever happen the first time I heard about that plan, didn't believe it when I was talking with this guy about App partitions, and don't seem to be alone in believing in it now hence the push on MIIS. Sure it is possible to pull it off in the small companies and even medium ones that are all strictly MS with few directory aware apps. Once you get into the larger companies, the mere thought of one directory for everything sounds pretty funny. That old adage of you can't be everything for everyone comes in hard in that realm. I really wasn't and am not still a fan of app partitions. You want to put some cool things into AD, give me caching DCs (no not BDCs) and give me multiple domain hosting from a single DC. I can get along fine if the requirement for the multiple domains is XP SPx or better. I don't want to hear the excuse of well what about legacy clients. My response is, if someone sets up the multiple domain hosting, damn their legacy clients. Back to the topic, I am not even sure if I would sync the internal AD to the DMZ AD or AD/AM in Rick's case. I think there is something that can be said for a company that has users have different passwords for external access into the company versus internal access. Obviously I don't know all of the particulars and in Rick's shoes may think that having the users use that one password in both places is exactly what is needed. But if that were the case, I would also probably require a second form of auth as well, such as a securid token. I guess I am funny about extranet stuff, I don't trust it at all. I always assume the worst about it and am extremely paranoid about it. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 5:05 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification The DMZ AD sounds like a good way to go for me too. Our security guys are pretty terrified of AD in the DMZ (we use IPSEC to deal with this), but it seems like it would save a lot of hassle. I don't personally deal with IPSEC, but it seems to have a suck factor reputation with the people here who do. I don't think I follow the users in the local SAM database thing you are talking about here. Where would that fall in with Rick's scenario? Would those be for the internal users or the external? Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 2:25 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Good restate. I think that captures it all. The key being that the ADAM server must be a member of the internal domain. If it isn't, all users need to go into some store (whether local, ADAM, or spinning up AD in DMZ) in the DMZ. Personally, I am not a fan of hooking anything outside the LAN/WAN to an internal AD so for me. I would look at populating the needed info out to the DMZ either in an AD sitting in the DMZ specifically for that purpose or into ADAM itself - don't forget to use SSL so you don't pass clear text passwords.
RE: [ActiveDir] Traveling Users Unable to Authenticate to AD
without any statement about the solutions 1 and 2 presented, either pro or con 3. Point the clients that belong to the AD domain at the AD DNS Servers and have a secondary DNS server in the list for the OTHERCO stuff. 4. Have the users use local IDs and use RUNAS and NET USER /USER. The only time this would really fall down that I am aware is when managing Exchange because it is stupid and requires the managing machine to be in the same forest as the Exchange Org. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Sunday, March 06, 2005 3:16 PM To: 'Scott McIntosh '; '[EMAIL PROTECTED] '; 'ActiveDir@mail.activedir.org ' Cc: '[EMAIL PROTECTED] ' Subject: RE: [ActiveDir] Traveling Users Unable to Authenticate to AD Although it is not allowed (why?) there are two possibilities here as I can see... (1) On the UNIX zone MYCO.US.PARENT.COM delegate the underscore domains beneath to the AD/DNS servers as seperate zones. You'll need to do the same for the AD/DNS servers. This is needed so that the UNIX servers as the AD/DNS servers can find the underscore DNS domains. (not that beautifull but it works) You could also remove the MYCO.US.PARENT.COM zone on the AD/DNS servers and leave the underscore DNS domains as zones. Caveat here (of the latter issue) is you must also change the IP address of DNS servers on all servers/clients that should be queried to the IP address of the UNIX servers. Not recommended because these are overseas (2) On the UNIX servers remove the zone MYCO.US.PARENT.COM and delegate it to the AD/DNS servers (I would prefer this one) Hope this helps for you Cheers, Jorge -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Cc: [EMAIL PROTECTED] Sent: 3/6/2005 6:52 PM Subject: [ActiveDir] Traveling Users Unable to Authenticate to AD Statement of Problem: Laptop users from MYCO (on Active Directory) traveling to OTHERCO (on Novell NDS but not AD) are unable to authenticate to MYCO.US.PARENT.COM Active Directory. Required Result: To enable laptop users from MYCO traveling to OTHERCO to authenticate to MYCO.US.PARENT.COM Active Directory, get their mapped drives, access to file shares, etc. over the WAN. Background Information: Overseas parent company does not allow delegation/forwarding from/to their UNIX BIND 9.2 DNS servers to W2k3 Active Directory DNS; Parent company (not on Active Directory) is authoritative for DNS root zone: PARENT.COM. Neither name server records nor SOA records are allowed to be populated in any of the parent company-hosted DNS zones; Parent company is also authoritative 1st level DNS zone: US.PARENT.COM (this zone is hosted overseas); Our company's dual-authoritative AD-integrated and UNIX DNS zone: MYCO.US.PARENT.COM (from parent company perspective the UNIX servers are authoritative, from our company's internal client/server systems W2k3 DNS is authoritative); The W2k3 Active Directory DNS servers conditionally forward queries for PARENT.COM and all child domains of PARENT.COM other than MYCO.US.PARENT.COM to MYCO's UNIX BIND DNS servers. This has worked fine. Affiliated, WAN-connected US company with Novell DNS zone OTHERCO.US.PARENT.COM (unable to conditionally forward and not in budget to perform necessary upgrade to OS to enable this feature); Within a year, both the parent company and otherco will be migrated to a globally-unified Active Directory implementation in a completely different namespace so that this will cease to be a problem. But we cannot let the problem persist for a year. Discussion: I believe the reason that laptop users from MYCO traveling to OTHERCO are unable to authenticate to MYCO.US.PARENT.COM Active Directory is that the OTHERCO DNS server sends packets to the US.PARENT.COM zone which looks to the UNIX BIND servers of MYCO.US.PARENT.COM for resolution-the UNIX BIND servers have the A records for the W2k3 DC DNS servers don't have the SRV and LDAP records necessary to enable authentication to the MYCO DC's running DNS. Without spending a lot of $$ and without having to deploy an additional MYCO DC/DNS server at otherco, we need a temporary workaround so that the traveling users can authenticate. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive:
Re: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Page 51 of the Planning an Exchange Server 2003 Messaging System. Exchange requires WINS (even though Windows does not) There's no additional information as to why Exchange requires it. I'll take a look in the Exchange 2003 Technical Reference Guide to see if mentions anything about WINS. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 14:34:01 2005 Subject: RE: [ActiveDir] WINS Okay, I will look into it also. We removed WINS from our forest about a year ago and have seen no ill effects. We are not real big, 2000 exchange accounts and 25000 users, but everything seems to be running fine without it. Over the next few months, we are going to add student accounts to Exchange, so we will end up with quite a few more accounts. If I find out anything I will post it. Thanks, glen The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 1:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS I'll look when I get home. I remember reading about it a year ago and was bummed out. I thought I could rid myself of wins. I did run Exchange without wins for a while but added it being MS recommends it. Only thing is it didn't give a reason why. Just said it was needed. It may not be the deployment guide, it's in one of the three recommended reading documents, deployment, admin guide and I forget the name of the other doc (planning an exchange environment?) Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 13:27:42 2005 Subject: RE: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003 setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 12:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Some info regarding WINS requirement from Microsoft: http://support.microsoft.com/?id=837391 Yandi From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Mezzone Sent: Monday, March 07, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS Page 51 of the Planning an Exchange Server 2003 Messaging System. Exchange requires WINS (even though Windows does not) There's no additional information as to why Exchange requires it. I'll take a look in the Exchange 2003 Technical Reference Guide to see if mentions anything about WINS. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 14:34:01 2005 Subject: RE: [ActiveDir] WINS Okay, I will look into it also. We removed WINS from our forest about a year ago and have seen no ill effects. We are not real big, 2000 exchange accounts and 25000 users, but everything seems to be running fine without it. Over the next few months, we are going to add student accounts to Exchange, so we will end up with quite a few more accounts. If I find out anything I will post it. Thanks, glen The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 1:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS I'll look when I get home. I remember reading about it a year ago and was bummed out. I thought I could rid myself of wins. I did run Exchange without wins for a while but added it being MS recommends it. Only thing is it didn't give a reason why. Just said it was needed. It may not be the deployment guide, it's in one of the three recommended reading documents, deployment, admin guide and I forget the name of the other doc (planning an exchange environment?) Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 13:27:42 2005 Subject: RE: [ActiveDir] WINS Just curious, where in the deployment guide does it say that Exchange 2003 needs WINS? We are running a clustered Exchange 2003 setup and we don't have WINS configured on our domain. glen [EMAIL PROTECTED] The University of Texas at Dallas From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Mezzone Sent: Sunday, March 06, 2005 12:20 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] WINS Unfortunetly it does. I thought it didn't until I read the deployment guide. Recently upgraded for 5.5. Robert -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. The Laryngeal Mask Company (Singapore) Pte. Ltd. www.lmaco.com **
RE: [ActiveDir] ADAM - Clarification
I get it now. You are more paranoid about the extranet than me, not less. We actually do lots of domain member servers in the DMZ (including the Exchange clusters), so you would probably freak out if you worked here. :) In any event, hopefully Rick has enough info to push ahead. Thanks, Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 4:39 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification I don't have a problem with AD in the DMZ, I just wouldn't let it be connected to my internal AD either via trusts or the truly uncool idea of putting an internal AD DC in the DMZ. The idea of using the local SAM ID's is if you want secure auth but don't want to use the required SSL for AD/AM user auth and you don't want to set up an AD. You sync your users from internal AD, the ones you need out on the extranet, not necessarily all of them to the local machine's SAM database. Then you can use a secure bind to connect to ADAM using those local Windows users. Of course if you go so far as to put up AD in the DMZ, do you need AD/AM? Maybe, depends on what else you are intending to do. If you are putting in app specific data, I would recommend AD/AM over AD and just have the auth bump over to AD. Of course others would say use an app partition, I don't like app partitions in AD. I am old fashioned but I see AD as my NOS auth store, I want everything else to get away from it because I consider auth more important than everything else. I constantly have fights with Exchange folks who consider the directory as theirs. It used to be theirs, now it is mine, stop abusing it before I slap you and you need to get that crap out, at least the config container stuff. I recall once a long while back before AD/AM was announced to anyone I knew or at least anyone willing to talk to me about it and I was talking to some MS Dev person who was trying to tell me how cool app partions in the up and coming Windows .NET would be and would I use them personally or as part of the enterprise I managed or would I recommend their use. I was like, I don't like the idea at all, why don't you guys just get over it and build a standalone LDAP server app; you have everything you need already. Why try to make AD the end all be all. I didn't believe it would ever happen the first time I heard about that plan, didn't believe it when I was talking with this guy about App partitions, and don't seem to be alone in believing in it now hence the push on MIIS. Sure it is possible to pull it off in the small companies and even medium ones that are all strictly MS with few directory aware apps. Once you get into the larger companies, the mere thought of one directory for everything sounds pretty funny. That old adage of you can't be everything for everyone comes in hard in that realm. I really wasn't and am not still a fan of app partitions. You want to put some cool things into AD, give me caching DCs (no not BDCs) and give me multiple domain hosting from a single DC. I can get along fine if the requirement for the multiple domains is XP SPx or better. I don't want to hear the excuse of well what about legacy clients. My response is, if someone sets up the multiple domain hosting, damn their legacy clients. Back to the topic, I am not even sure if I would sync the internal AD to the DMZ AD or AD/AM in Rick's case. I think there is something that can be said for a company that has users have different passwords for external access into the company versus internal access. Obviously I don't know all of the particulars and in Rick's shoes may think that having the users use that one password in both places is exactly what is needed. But if that were the case, I would also probably require a second form of auth as well, such as a securid token. I guess I am funny about extranet stuff, I don't trust it at all. I always assume the worst about it and am extremely paranoid about it. joe This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] ADAM - Clarification
I think that pretty much covers it. Given the option, I'll likely go with the SASL, as the MS docs don't recommend the proxy. I'll dig into why, but I suspect that it might have to do with issues of security. However, LDAP/SSL is the default, and one would have to change a couple of settings to turn it off. My challenge in the next couple of days is putting together the presentation to our InfoSec group to show them that having a hardened member server in the DMZ is not a sign of the Apocalypse. There are a number of things that we need to do with it (like, Ironmail confirming that, yes - rtkingslan does exist in the AD and making Spam decisions based on user existence) and putting the brakes on this is not a forward thinking decision. IPSec, SSL, firewalls - these were all devised with these types of situations in mind. What I may end up doing, as joe rightly does conclude, a domain in the DMZ might not be a bad idea either. I could use 1-way synch to this domain, and then further isolate the information to ADAM for the Portal and Ironmail. So, I think that what I needed to get out of this conversation was accomplished. Thanks for JoeK, joe, and Al for the input. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 1:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Ok, let's review and recap to make sure we are on the same page: - Rick wants to authenticate extranet users as users in the ADAM store (requires simple bind) - Rick also wants to authenticate AD users in the internal forest The ADAM users require simple bind. AD users use either SASL bind with pass through auth or simple bind with userProxy objects. To authenticate AD users in either scenario, the ADAM server has to be a domain member in a domain that has a trust that will allow the authentication. ADAM can't be workgroup in this scenario. Rick can put ADAM in the internal DMZ and allow port 636 traffic from the external DMZ, so ADAM should be able to provide LDAP authN services to the server(s) in the outer DMZ. Also, Rick can get ADAM to DC traffic approved with ADAM in the internal DMZ. Therefore, it looks like the question comes down to whether he wants to use a mix of simple and SASL with pass through or do all simple bind, userProxy objects and bind redirection. The latter will require some sync to get the userProxy objects created. I'm not sure I know enough to know which one is the way to go, but it looks like either is possible at this point. Did I miss something? Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 11:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Talk to for what? If it isn't a member, it don't give a hoot about any domains. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 11:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Joe, Thanks for the feedback. This is pretty much what I had concluded, after doing some testing last night after this bugged me to the point that I couldn't go to bed. IPSec is an option, but I won't get it past InfoSec. They flat refuse to allow domain-direct communications to the DMZ (or from, more correctly). Let me elaborate for a minute: We have a three layer DMZ, our external (Public DMZ), the middle layer (Private DMZ), and the internal network. By policy, incoming communications can only communicate one layer at a time. So, in the solution that I've proposed - The Portal Web server sits in the Public DMZ and ADAM sits in the Private. Getting firewall and / or IPSec set up for 389 / 686 traffic is not an issue. Setting up traffic from ADAM to the internal, specifically DCs is not an issue (please - don't ask how that's different than a domain member sitting in the DMZ - I've suffered aneurysms trying to convince InfoSec that the difference is semantics). One other interesting tidbit - how does ADAM, as a non-member server, now who to talk to? I'm hoping that I don't have to hard define a particular DC. Is there a possibility that a call made references the RootDSE, leaving the redundant capabilities of AD in place? Thanks much! -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 10:18 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification You need domain membership for the SASL bind as well.
RE: [ActiveDir] LDAP and related Exchange question
WTF?!?!? Has this list sunk this far? However, I should know better. It's joe, Al, and Deji. Never mind all. False alarm. Nothing odd going on at all. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, March 06, 2005 12:29 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question I don't think I am related to Denise Richards, it would be perfectly legal. I don't think I need to worry about Charlie Sheen, he is a punk. :o) On the Yamila Diaz-Rahi and the dash... I don't think we will ever know. She doesn't inspire me such as the likes of Eliza Dushku and Denise Richards. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 2:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question Depends on the country and the local culture. Some countries, men do change their names based on marital events. In the US for example, I've seen it. The bigger question would be why Joe would want to marry family what would that do to the whole unique naming thing when Eliza found out and, er changed him? :) This might make a good soap opera though. We'll just have to make sure that Joe stays unique so we can identify when he comes back from the corrective actions applied. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 04, 2005 2:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question Let's say after a few years I marry Denise Richards... While you are still married to Eliza Dushku ???. That would cause a lot of complications. For example, it would be UNIQUE across the North American Realm, but not in, say, African Realm. It will create illegal GUIDs in a lot of Realms, while it will be VALID in a lot of other Realms. That would lead to more collision. We don't want that now, do we? Then I go back to jricha34 Last time I saw you, you WERE male? I didn't think males last names change based on their marital statuses. You are not implying a surgical operation, here, are you? See, this is indeed causing a lot of collisions. ROFLM(F-ing)AO Deji -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, March 04, 2005 10:58 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question Assign a new unique name and link it to the old name and the old name is still never reused except in the case that the person's name changes back which has happened. Say if I got married to Eliza Dushku, my new ID would be something like jdushku3 or something. Let's say after a few years I marry Denise Richards... Then I go back to jricha34. However jdushku3 would always still only reference me. Their biggest issue is that they are currently limited to 3-8 characters. At some point they will have to expand that range. I think it depends on what systems it has to go onto, what the flexibility is of those systems, and what you want to be the master of the whole thing. If you can make AD the master source and the other directories/stores/etc can accept a guid then it would work. Otherwise, you are correct, you need to come up with some other unique mechanism. Basically look at the least flexible piece that has to stay long term and build from there. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 1:41 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question How did they handle people changing their names? I see the ID, but does that ID make sense when the user changes their name from Joe to 'They' or something along those lines? That goes back to the idea of coming up with a unique identifier that expands the horizon beyond the AD forest(s) and into the rest of the realm. I maintain that at some point in just about every country and every company, there is a unique identifier that ensures that person gets their proper compensation. Not that it couldn't be messed up, but you'd know quickly if your paycheck were lower than expected or paid to you in Yuan vs. Rubles if that's what you expected. This needs to stretch beyond AD from what I can tell. Is that an incorrect assumption Marcus? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, March 04, 2005 1:27 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] LDAP and related Exchange question I would tend to agree, I think objectGUID would be fine though it is a pain to deal with since it is binary. Another thing to consider is to
RE: [ActiveDir] ADAM - Clarification
Sorry for just weighing in on this thread now, this weekend has been crazy busy with things related to my upcoming move. I can take some of the credit/blame (you decide :)) for our guidance on ADAM generally, as I've been involved in the docs out there. There are two major reasons we don't recommend bind proxy: 1) It requires a simple bind, so in the absence of LDAPS (which is required by default, but some people disable this) your creds are flying naked over the wire. Some other bind types give you security in the absence of LDAPS, which is nice. 2) Bind proxy requires more mgmt overhead - you need to keep proxy objects around, and up to date. If you create a new user, you need to create a new proxy. If you migrate a user you need to recreate the proxy (sidHistory buys you time). If you delete a proxy you should delete a proxy (though I guess you don't have to if you don't mind the cruft). In the DMZ, you could sync your AD users out, or have enough connectivity such that the ADAM box can talk to a DC in the domain in question if you're going to use proxy bind. ADAM uses LogonUser() to auth the user in the proxy scenario, so take that for what it is worth. If you're not going to open anything from the DMZ to the internal (or not enough for a domain member) then proxy bind is off of the table. In that case you have some options which include: 1) You could sync your internal AD users to the extranet (in to an AD environment or ADAM that is out there). This requires password sync, which may or may not be ideal for you. 2) You could just have LDAPS open from the extranet in, and then have your users in the internal AD environment just get auth'd over that, and your extranet users (the ones in ADAM) just be a local bind against that ADAM instance, with the logic of deciding where being in your extranet app. By no means a complete list of options, just a few thoughts that sound like they are along the lines of what you're thinking about. I see mention earlier in the thread of using a workgroup machine out there (SAM db) and syncing crud out. I'm not sure I'm a fan of this, but am open to a compelling argument if someone has one. I don't see the benefit of this vs. just setting up an extranet domain that has no relationship to the intranet domain. If nothing else, the extranet domain can be just as hardened as the workgroup extranet scenario, and you have other options (policy, auth between extranet boxes, no user scalability issue as it is AD and not the local SAM db crud, etc.). And you have the same user sync out to the extranet problem either way. My $0.02 If you have specific questions just holler. ~Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, March 06, 2005 8:55 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification I think that pretty much covers it. Given the option, I'll likely go with the SASL, as the MS docs don't recommend the proxy. I'll dig into why, but I suspect that it might have to do with issues of security. However, LDAP/SSL is the default, and one would have to change a couple of settings to turn it off. My challenge in the next couple of days is putting together the presentation to our InfoSec group to show them that having a hardened member server in the DMZ is not a sign of the Apocalypse. There are a number of things that we need to do with it (like, Ironmail confirming that, yes - rtkingslan does exist in the AD and making Spam decisions based on user existence) and putting the brakes on this is not a forward thinking decision. IPSec, SSL, firewalls - these were all devised with these types of situations in mind. What I may end up doing, as joe rightly does conclude, a domain in the DMZ might not be a bad idea either. I could use 1-way synch to this domain, and then further isolate the information to ADAM for the Portal and Ironmail. So, I think that what I needed to get out of this conversation was accomplished. Thanks for JoeK, joe, and Al for the input. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 06, 2005 1:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] ADAM - Clarification Ok, let's review and recap to make sure we are on the same page: - Rick wants to authenticate extranet users as users in the ADAM store (requires simple bind) - Rick also wants to authenticate AD users in the internal forest The ADAM users require simple bind. AD users use either SASL bind with pass through auth or simple bind with userProxy objects. To authenticate AD users in either scenario, the ADAM server has to be a domain member in a domain that has a trust that will allow the authentication. ADAM can't be workgroup in this scenario. Rick can put ADAM in the internal DMZ and allow port 636 traffic from the external DMZ, so ADAM should be able to provide LDAP authN
RE: [ActiveDir] WINS
Title: Re: [ActiveDir] WINS Both Outlook and Exchange are users of NetBIOS name resolution - to wit, in the general case, WINS. Outlook uses it to determine where to find itsExchange server to connect to and sometimes for what DC to use (GC information comes from DNS unless overridden by a registry item). Outlook will normally fall back to DNS except in some pathological conditions. Documented, but not public I don't think (my copy is dated during OL 2003 beta testing and it could've changed since then - I haven't run a network trace like joe probably has). The easiest thing to note about Exchange is that Exchange servers (take a look at them in your CN=Servers,CN=Administrative Group,CN=Administrative Groups,CN=Organization Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,domain) aren't known by a FQDN or DN or GUID back into the A/D. Do some searching with ADSIedit for yourself on that topic. :-P Since Exchange is a forest-wide entity, hostnames could be duplicated in the DNS (note: I didn't say FQDN's - I said hostnames), but they can't be duplicated in WINS. -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org ActiveDir@mail.activedir.org Sent: Sun Mar 06 12:55:30 2005 Subject: [ActiveDir] WINS Is WINS still needed for exchange 2003? Some have said outlook still needs WINS. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
[ActiveDir] Network Monitoring
Hi All, - Is there a template where there is a checklist of the things that should be checked on the network maintenance? Like a network Administrator is there a baseline that one can have and compare when monitoring and maintaining the network to ensure everything is fine of course in addition to the alarms received when some thing goes wrong. - Another thing is am using serversalive, it says it can email me if the SMTP stops, does this mean it has its own SMTP engine? Thanks List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] Network Monitoring
Sorry I forgot to write my main question too: - Is there any way to have the even viewer trigger an email? Thanks On Mon, 7 Mar 2005 09:25:13 +0300, rubix cube [EMAIL PROTECTED] wrote: Hi All, - Is there a template where there is a checklist of the things that should be checked on the network maintenance? Like a network Administrator is there a baseline that one can have and compare when monitoring and maintaining the network to ensure everything is fine of course in addition to the alarms received when some thing goes wrong. - Another thing is am using serversalive, it says it can email me if the SMTP stops, does this mean it has its own SMTP engine? Thanks List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
