No the embedded devices that will need to write credit card details to
the SQL Database and get access to the network via RADIUS.

Cheers

Ryan

 

 

From: Brian Desmond [mailto:[email protected]] 
Sent: Monday, September 20, 2010 1:23 PM
To: NT System Admin Issues
Subject: RE: RADIUS Server

 

For service accounts? 

 

Thanks,

Brian Desmond

[email protected]

 

c   - 312.731.3132

 

From: Ryan Finnesey [mailto:[email protected]] 
Sent: Sunday, September 19, 2010 10:22 PM
To: NT System Admin Issues
Cc: Brian Desmond
Subject: RE: RADIUS Server

 

I would have no problem deploying and upgrading the DCs to 2008R2 that
is a great idea thank you. Now the only problem is finding a way to
handle password changes on the embedded CE devices.

Cheers

Ryan

 

 

From: Brian Desmond [mailto:[email protected]] 
Sent: Sunday, September 19, 2010 11:08 PM
To: NT System Admin Issues
Subject: RE: RADIUS Server

 

Ryan-

 

If you're going to spend the money on a separate domain (not a great
plan IMO) you might as well just upgrade the DCs to 2008/2008R2 in your
current domain and apply a separate password policy to the users in
question. If you can get your apps that have service accounts on 2008R2
then you can use managed service accounts which absolves you of a
password policy issue there. 

 

Thanks,

Brian Desmond

[email protected]

 

c   - 312.731.3132

 

From: Ryan Finnesey [mailto:[email protected]] 
Sent: Sunday, September 19, 2010 10:04 PM
To: NT System Admin Issues
Subject: RE: RADIUS Server

 

So a separate domain within the forest will be helpful.  One of the
issues I need to work out regarding password policies is how we change
passwords on the embedded CE devices.  The passwords are going to have
to be changed every 90 days.  

 

I was also hoping to have single deployments of BizTalk, System Center
Data Protection Manager, System Center Operations Manager ect within the
forest. 

 

I think the PCI auditor is going to become my new best friend.

 

Cheers

Ryan

 

 

From: Andrew S. Baker [mailto:[email protected]] 
Sent: Sunday, September 19, 2010 10:18 PM
To: NT System Admin Issues
Subject: Re: RADIUS Server

 

Agreed, re: Scope

 

Sharing the same production domain will mean that password policies are
in scope, but as long as physical and network access to the systems in
question are tightly controlled, the entire domain will not be in scope
from a machine perspective.

 

Be advised, however, that for PCI in particular, *networks* can be in
scope if they contain PII data, or if they contain machines which
*access* PII, so plan your segmentation carefully, and chat with your
friendly neighborhood auditor early and often.

ASB (My XeeSM Profile) <http://XeeSM.com/AndrewBaker>  
Exploiting Technology for Business Advantage...
 

On Sun, Sep 19, 2010 at 8:55 PM, Brian Desmond <[email protected]>
wrote:

You can setup a trust to a separate forest and use accounts across the
trust, potentially.

 

I don't know much about PCI but the customers I've worked with AD has
typically not been in scope of the PCI Audit/Compliance Requirement as
long as the stuff in scope for PCI has been appropriately segmented off.


 

Thanks,

Brian Desmond

[email protected]

 

c   - 312.731.313

 

From: Ryan Finnesey [mailto:[email protected]] 
Sent: Sunday, September 19, 2010 7:42 PM


To: NT System Admin Issues

Cc: Brian Desmond
Subject: RE: RADIUS Server

 

After diving deeper into the design requirements it looks like we are
going to need domain accounts for SQL Server per the SQL PCI compliance
white paper.  So that adds AD into the design.  What I need to figure
out now is do I need to deploy a completely separate AD forest or if I
can use to one we have in place now.  I do not want to open the entire
network to a PCI audit.    

 

Cheers

Ryan

 

 

From: Brian Desmond [mailto:[email protected]] 
Sent: Saturday, September 11, 2010 2:09 PM
To: NT System Admin Issues
Subject: RE: RADIUS Server

 

Yes it would. In this case NPS makes no sense to you.

 

You'd need a CAL for each user /or/ device the user is connecting from. 

 

Thanks,

Brian Desmond

[email protected]

 

c   - 312.731.3132

 

From: Ryan Finnesey [mailto:[email protected]] 
Sent: Saturday, September 11, 2010 12:52 AM
To: NT System Admin Issues
Cc: Brian Desmond
Subject: RE: RADIUS Server

 

Right now I do not have DCs or AD in the design.  Would NPS look to AD
for the username and password information?  I would need a CAL for each
device I think.

 

Cheers

Ryan

 

 

From: Brian Desmond [mailto:[email protected]] 
Sent: Saturday, September 11, 2010 12:58 AM
To: NT System Admin Issues
Subject: RE: RADIUS Server

 

I've used IAS (now "NPS") many times - works fine. I imagine it would
work fine for your Sprint project. You can just install it on your DCs
in most cases.

 

Thanks,

Brian Desmond

[email protected]

 

c   - 312.731.3132

 

From: Ryan Finnesey [mailto:[email protected]] 
Sent: Friday, September 10, 2010 11:24 PM
To: NT System Admin Issues
Subject: RADIUS Server

 

I wanted to get the groups feedback on RADIUS servers.  In the past (NT
4.0/2000 days) I would of used Funk Software's Steel-Belted Radius but
Funk Software has been acquired  by Juniper Networks.  We require a
RADIUS server to authenticate devices connecting to the Sprint 3G/4G
Data link service.  Per the Data Link install guide 

 

 

*         Data Link can support proxy authentication to the customer's
enterprise AAA server running the RADIUS protocol. This equipment is
managed by the customer and resides on their network.

*         Sprint supports RADIUS ports UDP 1812/1813 and 1645/1646 for
authentication and accounting.

*         RADIUS "Time to Live" (TTL) is 500 milliseconds on the Data
Link network and timeouts are set accordingly.  RFC 3344 only supports
CHAP-MD5 and CHAP requires that the customer authentication server have
access to the user password in clear text. 

*         For static IP implementations, the customer will need to add
the Framed-IP-Address RADIUS return list attribute to every user with an
IP as the value.

*         Customer user databases or directories that encrypt the user
password are not supported. 

*         If the customer uses a backend database or LDAP directory, the
passwords must be stored in clear text.

 

I would like a server that will support failover, I see there is within
Windows Server 2008, Network Policy Server (NPS) but I do not know if
this is the best option and I am still researching if NPS will meet
Sprints requirements.  Thanks in advance for your feedback and
recommendations.

Cheers

Ryan

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin


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 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here:
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

Reply via email to