One of the interesting recent developments in Second Life fashion is the increasing extent to which programming and automation are a part of virtual dress-up. An interesting example of this is a line of clothing from one of Second Life’s greatest and oldest design houses: PixelDolls. What initially caught my attention was the following ad:

Sign for Second Life skirt describing its HUD for on-the-fly color and fabric changes

As I research Second Life fashion, one feature I’m always on the watch for is the language or even cultural logic of technology showing up in unexpected ways, and this sign really grabbed my attention. In plain English, it says that the skirt comes with an HUD (heads-up-display) that enables the user to change the color and fabric of her clothing while she is wearing it. According to the Universal Font of All Knowledge, an HUD is an interface or data display that doesn’t obstruct a user’s view; HUDs were originally developed for military aircraft and later became a common metaphor for first-person shooter video games. Here’s how it works:

Avatar against a white background, with two HUDs visible

Here I am standing in the skirt against a white background. At the right of the screen are two HUDs. The lower one controls my body’s poses and animations, e.g., how I sit and my gait when walking. the one near the top controls the skirt. It features several fabric previews. Clicking one of these previews instantly changes the color and/or fabric (i.e., texture) of my skirt. Here I am in all my fabulousness.

Two side-by-side copies of me in different colors of the skirt

There are a couple reasons why this development is worthy of comment. First, this paradigm does not match our real life mental models of clothes. If I want to change the color of my clothes, I have to change into other clothes. Historically, fashion designers in Second Life have sold multiple color variants of the same garment separately: buy this red shirt for 50 cents, blue for 50 cents, etc., or buy all six colors for $2 (in what’s called a “fat pack,” an unfortunate name for women’s clothing if I ever heard one). In your inventory, you would end up with 6 shirts in your inventory, and if you wanted to change them, you’d have to dig around your inventory and drag it onto your avatar, to replace the one you were wearing. Abstractly, this process mirrors real life, except that we use closets, not Windows-Explorer-like inventory systems, and our closets don’t (typically) have thousands of garments in them.

The second significance, related to the first, is that usability is transforming the way clothes are made, sold, stored, and worn/used. This system is, at least superficially, far more usable than the old way. Interaction design is asserting itself to replace the more literal translations of real-life to Second Life fashion that preceded it. I know in real-life wearable computing that some researchers are exploring fabrics that can change color, and one wonders if Second Life here is a prototype of future fashion.

Finally, I said “at least superficially” more usable in the previous paragraph, because as a user, I still have a concern about this strategy. The HUD only works for this skirt. I bought a pair of matching trimmed heels (pictured below; don’t hate me because I’m beautiful) from the same store display, and they came with their own HUD.

A close-up of my trimmed heel shoes.

If we extend this logic forward, for every multi-use garment we wear, we’ll have a separate HUD. And HUDs are as much of a pain to manage as garments, perhaps more so, because they are more abstract and interactive than clothes are. Thus, we could go from managing too many clothes to managing too many HUDs.

This HUD-based approach to handling clothing variation is an interesting development, because it has interesting implications for virtual fashion and real-life fashion and wearable computing in the future, but it can’t be the right answer. HUDs will have to become more flexible, more interoperable–in short, they’ll have to become clothing management applications–if they are truly to get the job done.

This entry was posted on January 20, 2008 at 1:15 pm and is filed under Fashion, HCI, Leisure, SecondLife, Wearable Computing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

http://interactionculture.wordpress.com/2008/01/20/wearable-computing-automation-and-fashion-in-second-life/

HCI Forum Topic DISS 720

2008-07-30T17:49:00.000-07:00

http://blogs.soi.city.ac.uk/hcid/2008/03/19/second-life-virtual-event/

HCID ran a virtual seminar (funded by ESRC in conjunction with the ESRC festival of Social Science event) in Second Life to discuss Social Learning in Virtual Worlds. The event took place on the 13th of March in the EMERGE island in Second Life. This was followed by a face-to-face workshop in our Interaction Lab on the 14th of March.

I think about 30-40 people participated in the virtual event and an additional 20 in the face-to-face workshop. I was facilitating the discussion and it was a very interesting experience! For instance, I was struggling a lot on a simple issue like turn taking. In the end I hardly looked at the 3D world because I was too busy tracking who raised their hands on the chatting windows! So much talk about social presence in virtual worlds!

HCI Forum Topic DISS 720

2008-07-21T10:19:00.000-07:00

Julie A. Jacko and Francois Sainfort under investigation.

http://www.ajc.com/metro/content/metro/stories/2008/04/23/tech0423.html?cxntlid=inform_sr

Doctoral Paper by Adam Norten on Schneider's Dissertation

2007-04-26T09:17:00.000-07:00

Assignment 3: Dissertation Review

by

Adam Norten

An assignment submitted in partial fulfillment of the requirements
for the degree of Doctor of Philosophy
in
Information Systems

Graduate School of Computer and Information Sciences
Nova Southeastern University
DISS-725 The System Development Process
Winter 2007 Institute
Dr. Yair Levy

2007

A Case Study of Information Assurance Field Experience

by

Helen Schneider
Chairperson – Gertrude W. Abramson, Ed.D

A dissertation submitted in partial fulfillment of the requirements
for the degree of Doctor of Philosophy
in
Computing Technology in Education

Graduate School of Computer and Information Sciences
Nova Southeastern University

2006

DISS-725 Dissertation Review
The dissertation, “A Case Study of Information Assurance Field Experience” by Helen Schneider (2006) proposes that small businesses and non-profit corporations lack the resources to deal with their own Information Assurance (IA) needs. IA is a way of assuring the “confidentiality, integrity, availability, authentication, and nonrepudiation” of information that is digitally stored or communicated (Schneider, 2006, p.1). In order to explore one possible solution to this problem, Schneider conducted a case study of a scholastic program at Walsh College in Troy, Michigan. In the study students enrolled in cyber security and computer forensics programs at Walsh College provided IA services for small businesses and non-profit organizations as part of a supervised field program. The dissertation also includes a mini-case study in which students from three classes from University of Findlay in Findlay, Ohio processed, analyzed, and presented the results of a community technology survey for the local Chamber of Commerce (Schneider, 2006).
The results of the studies which were derived from questionnaires completed by the participating students, faculty members, and businesses showed that the students involved gained practical experience for themselves while also satisfying the unmet IA security needs of the participating small businesses and non-profit organizations (Schneider, 2006). From those results Schneider (2006) was able to articulate success factors which can be used to direct the incorporation of field experience into future IA program curricula (Schneider, 2006).
What is the problem this dissertation is trying to address?
The problem that Schneider (2006) tries to address is threefold. First, small businesses and non-profit organizations need but do not have access to IA resources. IA encompasses the concept of security, of which there is a greater demand among today’s companies than existed in the past (Schneider, 2006, p. 5). In order to meet this need for security, companies’ employees must to be educated on a variety of security issues (Allen & Sledge, 2002). This need may go unmet by small businesses and non-profit organizations due to budgetary concerns and the unavailability of trained personnel (Schneider, 2006).
Second, one of the stated goals of the National Security Association (NSA), as well as a cyber-security responsibility of the Department of Homeland Security (DHS), is to promote public awareness and outreach in, “Establishing a comprehensive national awareness program to promote efforts to strengthen cybersecurity throughout government and the private sector, including the home user” (U.S. Government Accountability Office [U.S. GAO], 2005, p. 24). The inclusion of mandatory or optional field experience service in IA programs will contribute towards meeting these goals (Schneider, 2006).
The third problem that Schneider (2006) addresses is that IA curriculums under-utilize the concept of service work experience (Schneider, 2006). As such, IA programs fail to provide their students with the practical experience that a service work program would afford (Schneider, 2006). In this way, IA service work programs not only meet the needs of the participating businesses but enhance the educational experience of the participating students as well (Schneider, 2006).
One deficiency in the threefold problem statement Schneider (2006) presents is that it changes focus over the course of the dissertation. Schneider only briefly addresses the need of students for practical experience at the beginning of the dissertation addressing it more as an added benefit of the study rather than an actual problem to be addressed. Instead, Schneider initially focuses solely on the needs of small businesses and non-profit organizations. However, in the conclusion summary section, Schneider reverses the order of problems and instead lists first and stresses the benefits to students derived from field experience. This new problem order is inconsistent with the order Schneider presents in the beginning of the dissertation.
Why should anyone read this dissertation?
IA educators could gain from reading this dissertation in order to explore the benefits from including field work in their IA course curricula (Schneider, 2006). Schneider (2006) demonstrates that including field work in an IA curricula results in positives outcomes for the IA students involved. In addition, small businesses and non-profit organizations have everything to gain and nothing to lose by reading Schneider. They can find out how to satisfy their unmet security needs by obtaining IA services, security information and resources from students completing their field experience (Schneider, 2006). Finally, by reading Schneider, students can learn how to augment their IA education with practical, real world experiences. They can likewise develop problem-solving skills and associations with clients (Schneider, 2006). In addition, Schneider provides much useful information on scholarships that are available to IA students (Schneider, 2006, p.9).
What is the point of this dissertation (goal)?
The goal of this dissertation was to create a case study and mini-case study in which students at two colleges were assigned field work that provided IA services to small businesses and non-profit organizations. These two studies joined up the IA students’ need for field experience with the needs of small businesses and non-profit organizations for IA security support (Schneider, 2006). Schneider (2006) uses the results of these studies to determine success factors to be used in incorporating field experience into IA program curriculums (Schneider, 2006, p. 60). A sub-goal of Schneider is that all the participating students, small businesses and non-profit organizations benefit from their involvement in the studies.
Who should care about the solution?
Students currently enrolled or looking to enroll in computer forensics or cyber security curriculums should care about the benefits to be gained by incorporating field experience in their college programs discussed in Schneider (2006). IA educators may be interested as well in augmenting their schools’ programs by incorporating field experience into their curricula. In addition, small businesses and non-profit organizations should also be interested in the results of Schneider for the benefits that it could potentially provide them (Schneider, 2006). The DHS and NSA should also be interested in Schneider as well because the dissertation addresses their goals of promoting cyber-security awareness and outreach to the general public in order to strengthen national security (Schneider, 2006; U.S. GAO, 2005).
What is the argument behind the research?
The claim presented in Schneider (2006) is a three-fold claim that IA students, through field experience programs (1.) help meet the IA needs of small businesses and non-profit corporations, (2.) extend the reach of federal programs promoting IA such as those administered by the NSA and DHS, and (3.) gain real world IA experience for themselves (Schneider, 2006).
In support of her three-part claim, Schneider (2006) presents evidence primarily in the form of questionnaire responses. As to the first part of Schneider’s claim concerning benefits to small businesses and non-profit corporations from field experience programs, Schneider presents questionnaire responses from students, clients and professors (Schneider, 2006). Participating students felt that the clients became more aware of IA issues, and participating professors in both studies felt that the clients’ needs were met (Schneider, 2006). While Schneider acknowledged that the clients’ responses were “cautiously positive,” Schneider also pointed out that the clients agreed that the projects helped them to better respond to IA issues (Schneider, 2006).
As to the second part of her three-part claim, that supervised field experiences involving IA students will extend the reach of federal programs such as those administered by the NSA and DHS, Schneider failed to present any evidence to support this claim. As to the third part of her three-part claim, that students benefit from supervised field experiences, Schneider presents questionnaire responses from eleven of thirty students involved in the first study (Schneider, 2006, p. 73), and thirty-nine of forty-two of the students involved in the mini-case study (Schneider, 2006, p. 94). Of the students who responded to the surveys, a majority agreed that they gained knowledge they had not gained from attending classes and skills from participating in the program (Schneider, 2006).
Concerning warrants, the first part of the three-part claim is tied to the evidence under the implied warrant that although they lack real world experience, IA students can contribute valuable knowledge, skills and abilities to small businesses and non-profit corporations in the area of IA. Connecting the third part of the three-part claim with the evidence is the implied warrant that the real world experience students receive from participating in supervised field experiences rounds out and compliments their classroom training.
What evidence does the author present to support the arguments?
The sources of evidence on which Schneider (2006) relies includes, “documentation, archival records, interviews, and surveys” (Schneider, 2006, p. 49). In order to support that the educational environments in which the main and mini-case studies were as the dissertation represents, Schneider relies on “descriptions of the IA program and field experience criteria in the form of course catalog descriptions, syllabi, and project guidelines for the course” (Schneider, 2006, p. 49). As to students participating, Schneider relies on archival records consisting of “student lists, records of the course offerings, and numbers of students completing the course.” (Schneider, 2006 p. 50). Physical artifacts were also sought including notebooks and project records (Schneider, 2006, p. 50).
To capture evidence to support the dissertation’s main claim, Schneider (2006) used questionnaires. Schneider submitted questionnaires to participating students, faculty members, and the client organizations. The responses to these questionnaires formed the evidence on which Schneider based her conclusion that multiple benefits result from IA students participating in work study programs with small businesses and non-for-profit corporations.
What are the authors underlying assumptions or biases?
As to underlying assumptions, Schneider (2006) presents numerous assumptions concerning the benefits from and need for IA field experience programs. However, Schneider fails to substantiate these assumptions, a step which is necessary in order to use the assumptions to support a sound argument (Hart, 1998). For example, Schneider asserts that field experience involving IA majors working with non-profit corporations and small businesses raises “public awareness” (Schneider, 2006, pg. 4). Schneider likewise claims that the current business workforce lacks IA education (Schneider, 2006, p. 4), that small businesses do not have the budget to deal with their IA needs (Schneider, 2006, p. 4), that within non-metropolitan areas there are too few “paid services” available (Schneider, 2006, p. 4), and that even in metropolitan areas, non-profit organizations can not handle the expense of IA services (Schneider p. 4). Schneider presents these various assumptions, however, with no supporting literature or evidence.
The term “bias,” when used in the context of qualitative research, typically refers to the subjectivity of the researcher impacting the research study (Maxwell, 2005). In order to remove researcher bias and to ensure that Schneider (2006) did not change the reporting or the views of the participants, a draft of the dissertation was inspected by a key informant of the study before the final report was written (Schneider, 2006, p. 56). However, Schneider never identifies who the key informant is.
In order to minimize the impact of bias contained in a single source of evidence, Schneider (2006) uses multiple sources of evidence. While many sources of evidence can be used including interviews, documents, old records, direct or participant observation and physical artifacts, each of these can have its own bias and limits (Yin, 2003). Using them together, however, can create a pattern in which the data converges (Yin, 2003). Even though Schneider agrees with Yin about bias, Schneider only supports her conclusions with two types of evidence: responses from questionnaires and one telephone interview. Also, Schneider fails to address possible bias in one of the questionnaire responses she received. In particular, in response to the mini-case study, the client organization “indicated strong agreement with all of the Likert scale items” (Schneider, 2006, p. 92). While Schneider compares these questionnaire results with those received from the client in the main case study, Schneider does not acknowledge any possible bias despite the fact that the client gave the highest possible score in each category without deviation (Schneider, 2006, p. 92).
What is the claim of this dissertation?
The claim in Schneider (2006) is that IA field experience is both beneficial for students and companies (Schneider, 2006, p. 12). IA students, through field experience programs that are supervised by their instructors, help meet the security and IA needs of small businesses and non-profit organizations (Schneider, 2006). In addition, the use of field experience helps students gain real world IA experience and extends the reach of federal programs such as those administered by the NSA and DHS (Schneider, 2006).
Where and what are the holes in the argument/claim? (Study Limitations)
Schneider (2006) performed both her studies at small sized institutions with small numbers of participants (Schneider, 2006, p. 14). While the size of the institutions may not have prevented the studies from being effective, the level of student participation in the main case study proved problematic in that Schneider only received responses to 11 out of 30 questionnaires submitted to participating students in her main study (Schneider, 2006, p. 73). The response rate in Schneider’s mini-case study was better in that she received back responses from 39 out of 40 questionnaires submitted to students (Schneider, 2006, p. 94).
Another hole in her argument resulted from her failure to limit participation to the group of students she originally targeted to participate. Schneider acknowledges in her conclusion that since the data collected in the main case study was less than what she had hoped for, she had to perform an additional mini-case study at Findlay University where she is employed (Schneider, 2006, p. 102). While Schneider (2006) was careful to limit participation in the main case study to students enrolled in cyber security and forensics programs, in the mini-case study, only three IA students participated (Schneider, 2006). The rest of the students allowed to join in on the mini-study were enrolled in either statistics or project management (Schneider, 2006).
What is the success measure in the dissertation?
Schneider (2006) states that the results of her main and mini-case studies backed up her predictions with “positive affective reactions, and better understanding of the principles taught” for the students involved, and “positive reactions, better preparedness, and a willingness to share experiences with other organizations” for the businesses and non-profit organizations involved (Schneider, 2006, p.113). In Schneider’s summary of results, she also claims that both Walsh College and University of Findlay were pleased with the results of the field work at their institutions (Schneider, 2006).
Despite her conclusion that the measured results of her studies were successful, Schneider (2006) fails to speak to possible bias in the positive questionnaire responses she received. In particular, Schneider does not address the fact that the questionnaire results from the client in the mini-case study “indicated strong agreement with all of the Likert scale items” (Schneider, 2006, p. 92).
What are the validity (internal and external) as well as reliability issues in this dissertation? Did the author address it? Did the author justify it?

In the context of a research study, internal validity is the extent to which the study and its results enable the researcher to make correct conclusions concerning the study’s outcome (Leedy & Ormrod, 2005, p. 97). Schneider (2006) acknowledges that issues with internal validity, particularly during the data analysis phase, could have arisen. Schneider proposes, without citing any supporting research, that the negative impact of internal validity issues can be limited by use of “pattern matching, explanation building, addressing rival explanations, and using logic models” (Schneider, 2006, pp. 56-57). Schneider then indicates that at least two rival theories were identified. While Schneider identifies the rival theories, she provides no explanation as to who formulated the theories, and how they compared and contrasted with her work.
In order to address pattern matching, Schneider (2006) writes that she made pattern matching predictions before she collected the data. In addition, she looked for commonalities and differences between the test environments, and that these “commonalities and differences were used to identify converging and diverging patterns of response” (Schneider, 2006, p. 57). However, Schneider provides no explanation as to what patterns, commonalities and differences she found and assessed.
In the context of a research study, external validity is “the extent to which its results apply to situations beyond the study itself . . . .” (Leedy & Ormrod, 2005, p. 99). While Schneider (2006) claims that she covered the issue of external validity during the research design phase by using “analytical generalization,” Schneider does not elaborate or provide any discussion on how she used “analytical generalization” (Schneider, 2006, pp. 57-58).
Finally, as to reliability, Schneider (2006) uses triangulation within the design of her case study by incorporating multiple sources of evidence. To ensure the reliability of the documentation, she created a database of the evidence she collected and a narrative of the report of the case study (Schneider, 2006). Schneider also ensured that she maintained the chain of evidence for the documents she collected so that her case study could be recreated by an observer (Schneider, 2006).
What is next? Did the author propose any valid path of future studies? What is it?
Schneider (2006) gives four different proposals for future study in this area. First, Schneider proposes that a study could be conducted involving students in programs where field experience was optional (Schneider, 2006). Then a comparison between students could be made of those who had to perform field experience and those students who had the option of choosing to do field experience (Schneider, 2006). Secondly, Schneider suggests a study of students from different scholastic programs such as research, traditional, undergraduate programs, computer engineering and criminal justice (Schneider, 2006). Thirdly, she suggests a study of students who have already been in the workplace from five to ten years (Schneider, 2006). Lastly, Schneider suggests longitudinal studies of the businesses that are involved in students’ field experiences in order to see what benefits the businesses derive from the students’ efforts (Schneider, 2006).
After reading this dissertation, what are the contributions it provided you?
I learned about the needs for small businesses and non-profit organizations to become more aware of IA and strive to achieve it, particularly in light of the increasing instances of data theft and use of malicious code (Symantec, 2007). I also learned the potential value of field experience to my own education. In particular, I discovered that field experience can be a combination of internship and service learning experiences and can promote community service (Schneider, 2006). I learned about the rigor that is involved in completing a Ph.D. dissertation at Nova Southeastern University. From closely analyzing Schneider, I saw that it is important to support your statements with high quality literature and that the failure to do so reduces the credibility of your research. As an aside, I found out about numerous scholarship opportunities available to IA students.

Reference List

Allen, J. H., & Sledge, C.A. (2002, July). Information survivability: Required shifts in perspective. Crosstalk: The Journal of Defense Software Engineering, 7-9. Retrieved April 11, 2007, from http://www.cert.org/archive/pdf/CrossTalk_Shifts_7-02.pdf

Hart, C., (1998). Doing a literature review. Thousand Oaks, CA: SAGE Publications Inc.

Leedy, P. D., & Ormrod, J. E. (2005). Practical research: Planning and design (3rd ed.). Columbus, Ohio: Pearson Prentice Hall.

Maxwell, J. A. (2005). Qualitative research and design an interactive approach (2nd ed.). Thousand Oaks, CA: Sage Publications Inc.

Schneider, H. (2006). A case study of information assurance field experience. Dissertations Abstracts International, 67 (02). (UMI No. 3207809) Retrieved March 14, 2007, from Dissertations and Theses database.

Symantec. (2007, March). Symantec reports rise in data theft, data leakage, and targeted attacks leading to hackers’ financial gain. Retrieved April 19, 2007, from http://www.symantec.com/about/news/release/article.jsp?prid=20070319_01

U.S. Government Accountability Office. (2005). Critical infrastructure protection: Department of Homeland Security faces challenges in fulfilling cybersecurity responsibilities. Retrieved April 20, 2007, from http://www.gao.gov/new.items/d05434.pdf

Yin, R.K. (2003). Case study research: Design and methods (3rd ed.). Thousand Oaks, CA: SAGE Publications.

The Graduate School of Computer and Information Sciences

Certification of Authorship of Dissertation Work

Submitted to: Dr. Levy

Student’s Name: Adam Norten

Date of Submission: April 22, 2007

Purpose and Title of Submission: Dissertation Review

Certification of Authorship: I hereby certify that I am the author of this document and that any assistance I received in its preparation is fully acknowledged and disclosed in the document. I have also cited all sources from which I obtained data, ideas, or words that are copied directly or paraphrased in the document. Sources are properly credited according to accepted standards for professional publications. I also certify that this paper was prepared by me for this purpose.

Student's Signature: Adam Norten____________________________________

2006-10-28T17:09:00.000-07:00

Resume

2006-10-28T17:07:00.000-07:00

Adam Norten
451 N. Highview Ave.
Elmhurst, IL 60126
Phone 630-279-8747
graceandglory13@sbcglobal.net

Experience PolyScience Niles, IL 2001-2002
Electrical Engineering Technician
o Aided and implemented in the construction of chillers re-circulators and optical design at an ISO9000 certified company
o Audited product safety and met UL and CE standards
o Gained knowledge of refrigeration and thermodynamics

Paige Personnel Rosemont, IL 2000-2001
Instrumentation Group Contractor
o Drafted drawings using AutoCAD and Micro Station for use in Chemical Engineering projects at UOP
o Checked purchase orders of engineering equipment against engineering schematics and mechanical flow diagrams

Cendant Mobility Danbury, CT 1999-2000
IT Help Desk Analyst
o Supported Microsoft and company software applications over a network
o Maintained MS Outlook, MS Access, Windows NT and MS word
o Provided customer service and support

Education
Nova Southeastern Ft. Lauderdale, FL Ph.D. in Computer Information Systems
Expected graduation: June 2009

Elmhurst College Elmhurst, IL
Master of Science in Computer Network Systems
May 2006 GPA 3.5

DeVry University Addison, IL
Bachelor of Science in Computer Engineering Technology
October, 2004 GPA 3.8

Honors Received
o President’s List o Dean’s List o Phi Theta Kappa
o Alpha Chi o Graduated Magna Cum Laude

The Session Token Protocol for Forensics and Traceback

2006-10-28T17:05:00.000-07:00

Carrier, B., & Shields, C. (2004). The Session Token Protocol for Forensics and Traceback. ACM Transactions on Information Security and System Security, 7, 333-362. Retrieved on September 13, 2006, from the ACM Digital Library database.

In this article, Carrier and Shields describe the Session Token Protocol (STOP), a protocol designed to be used by forensic investigators and others to track the identity of an attacker. It is based and expands on the Identification Protocol (IDENT).

By “stone stepping,” an attacker logs on through many host computers before trying an attack to complicate any attempt to learn his identity. To seek a remedy for this problem, the authors started by reviewing two alternative but limited types of network traceback: IP traceback which attempts to locate the source of spoofed Internet Protocol packets, and network-based connection-chain which tracks attacks that were performed using a connection chain. These two types of traceback are not effective if the attacker spoofs the IP address of the victim in a system that responds with a protocol like DNS, also known as a reflector attack. The authors then described IDENT, the protocol on which STOP is based. IDENT is a two-way protocol used by a server to identify the client-side of a network connection. First, it establishes a TCP connection from the client port to the server port on the host computer. Then, the host computer connects to the TCP port on the previous host computer and sends the message , . The previous host computer then uses the source IP address to determine which process had a connection from the client port to the server port. If it is able to locate a process, it returns a message. IDENT’s limitations include that it may provide insecure sources with information concerning the service a user is using, can be used to collect email addresses, and the IDENT daemon does not automatically protect a user’s privacy.

The authors then introduced the STOP protocol which provides additional functionality to what is offered by IDENT, and data that is usually missing in forensics investigations. It gives a log of socket activity, can request that a daemon using this protocol save additional user-level and application-level data, and provides a mechanism that the protocol can use to trace a hacker using many hosts. In fact, STOP works most effectively when it is run on many hosts. While IDENT did not maintain privacy, STOP does so by returning a random token rather than a user’s name. Because IDENT is widely used, STOP has been built to be backward compatible with it. The protocol used by STOP incorporates recursive traceback in an attempt to gain access to information on the whole pathway of a connection. This lets investigators trace an attacker to their home system or computer. STOP may not always show the entire chain of connection. But it can lower the expensive costs of a forensics investigation required to catch an attacker.

Two of the three case studies that were shown by the authors were the simple and complex process structures. Their examples were of process trees that could be analyzed by a daemon that used the STOP protocol. The protocol was tested on three operating systems: Solaris, OpenBSD and Linux. Solaris used the KVM library to read kernel memory, but it used a stream design for it in-memory network structures. Solaris’ design made it harder for it to get information than in the OpenBSD design. OpenBSD, on the other hand, used the KVM library to read the process table and tables from the kernel’s memory. Linux used the pseudofile process system to get information about the process. In the tests it was found that Linux had a 973% increase in lookup time. Linux also spent 136% more time on a SV lookup than the OpenBSD operating system did. This was because OpenBSD could do more in kernel space and Linux had to utilize file IO and use scanf() to determine process data.

Some limitations of STOP are partial deployment, covert channels, its effects on network channels, integrity of saved data and the compromising of STOP daemons. While it is certain that the STOP protocol will not solve all traceback situations, it is a step closer to a solution.

Public-Key Cryptography and Password Protocols

2006-10-28T17:04:00.001-07:00

Halevi, S., & Krawczyk, H. (1999). Public-Key Cryptography and Password Protocols.
ACM Transactions on Information and System Security, 2, 230-268. Retrieved on September 13, 2006, from the ACM Digital Library database.

In this article, Halevi and Krawczyk studied the combined use of weak (passwords) and strong (private key for public-key encryption) authentication and key exchange in asymmetric scenarios.

The most basic password use is sending a password from a user to a server in the clear in which the server stores a file with the plain password or its image to validate the password. In remote authentications, the password can be easily read by an eavesdropper. One of the most basic attacks is password guessing in which an attacker uses a small dictionary of common passwords. In an off-line attack, the attacker notes communications and then uses the dictionary to look for consistent passwords, while in an online attack, he keeps trying passwords from the dictionary until he gets the correct one. The authors define the security for a password-based one-way authentication protocol by describing an attacker who can watch runs of the protocol between the user and the server, prompt new authentication sessions where he can see all messages sent between the two, intercept messages which he can change or drop, and see if the server accepts the authentication or not.

Several protocols in the asymmetric scenario were then presented where the authentication server has a pair of private and public keys and the client uses a password. The first protocol, part of broader group of protocols called “encrypted challenge-response mechanisms,” was a simple one in which the password was encrypted with the server’s public key and then sent to the server for verification. The authors’ findings showed additional properties were needed to maintain the security of the protocol. Next, the authors used the challenge-response approach to encrypt the user’s response under the public key of a server to fend off guessed passwords. The authors determined that while encrypting the response would appear to be an effective way of preventing password guessing, it was not. The authors stated that since they aimed to achieve a higher level of security for their protocols than semantic security, they chose to use OAEP, a simple encoding of data for use with RSA encryption to provide protection against strong attacks.

The authors added to their authentication protocols the function of authenticating the server to the user their exchange of an authenticated secret key. They indicated that this provides security needed in many security applications. While the protocol does not give perfect forward secrecy because exposure of the server’s private key means the session key is revealed, the authors stated that perfect forward secrecy could be performed by using the Diffie-Hellman exchange and Mutual Authentication. The authors next suggested giving the user a hashed version of the public key, a so-called “public password,” to be used where clients cannot verify the authenticity of the server’s public key in order to extend the human-password and serve as a “hand held certificate” to a public key.

The authors next stated their definition of password protocol security and established the security of their encrypted challenge-response protocol. To do so, they created a model on which they could run and see their security requirements. The authors proposed a “probabilistic game” with a user, server, and intruder who has great but limited power. Each game had security parameters controlling the strength of cryptographic keys and functions, and a dictionary of passwords. Using their probabilistic game, the authors defined a secure one-way password authentication protocol by first stating that a protocol is syntactically correct when all messages are passed unchanged, then by explaining successful impersonation and authentication. Within this definition, the intruder’s strategy is to keep trying passwords until he is successful.

Finally, the authors gave an explanation of their public-key encryption method that can stop ciphertext-verification attacks using a key generation, probabilistic encryption and decryption algorithms. The authors noted that users and servers in a password setting have a shared secret, and that all the strong password mechanisms they and others propose use public-key techniques.

Use of Nested Certificates for Efficient Dynamic, and Trust Preserving Public Key Infrastructure

2006-10-28T17:04:00.000-07:00

Levi, A., Caglayan, M.U., & Koc, Cetin K. (2004). Use of Nested Certificates for Efficient Dynamic, and Trust Preserving Public Key Infrastructure. ACM Transactions on Information Security and System Security, 7, 21-59. Retrieved September 13, 2006, from The ACM Digital Library database.

The purpose of this article is to present the Nested Public Key Infrastructure (NPKI) model, an alternative to the existing Public Key Infrastructure (PKI). NPKI improves on PKI by providing a more efficient method for verifying certificates for public key distribution.

A PKI is a certificate network designed to enable verifiers to find the right public key for a user by following a path of certificates. Certificates are digitally signed bindings between a public key and attributes such as a name, e-mail address, URL or authorization of the owner. They are issued by trusted Certification Authorities (CAs). A verifier uses a certificate by verifying the digital signature of the CA over the certificate and then locating the public key for the user. In PKI, since there are several CAs and a verifier does not know the public key for each, a verifier, in order to get a public key, needs to take and verify a certificate path in order to locate the public key it is seeking. In doing so, it must verify each certificate along the way to find the public key of the next CA, and the CA’s public key is then used to verify the next certificate. The verifier must trust all CAs in the chain.

In order to avoid having to verify each certificate along a path just to locate a single public key, the authors proposed a new PKI, nested-certificate-based PKI (NPKI). NPKI utilizes nested certifications which are basically certificates for other certificates and can be used to determine certificate paths. In NPKI, both classical and nested certificates can be used together. Certification Authorities (CA’s) distribute nested certificates instead of the certificates given their children in the PKI allowing PKI to transition into NPKI. In this way, classical certificate paths are made into nested certificate paths without wrecking trust relationships or topology already in place. In practice, NPKI provides nested certificate paths in which the first certificate is verified cryptographically and the others by fast hashing thus increasing verification speed.

In order to improve verification time, many nested certificates must be issued resulting in a trade off between improvement in verifying and the overhead in nested certificate issuing. This trade off was studied by the authors with a generic balanced tree PKI model. It was seen that, although not distributed uniformly, for a 4-level, 20-ary tree shaped PKI, the average verification was sped up to between 2.41 and 2.50 times faster while the number of certificates increased by 3.85 times. The authors also noted that since nested certificates are not for users but for other certificates, the rules for revoking them are different. They propose that two or possibly even one revoking tool is enough for nested certification paths. As such, NPKI is better than PKI in certificate revocation.
Also, nested certificate paths are quick enough to be verifiable by wireless users.

Consistency Analysis of Authorization of Hook Placement in the Linux Security Modules Framework

2006-10-28T17:02:00.001-07:00

Jaeger, T., Edwards, A., & Zhang, X. (2004). Consistency Analysis of Authorization of Hook Placement in the Linux Security Modules Framework. ACM Transactions on Information Security and System Security, 7, 175-205. Retrieved on September 21, 2006, from the ACM Digital Library database.

In this article, the authors Jaeger, Edwards, and Zhang, tried to confirm for Linux users and kernel developers the correct location of hooks inside the Linux kernel which comprise the Linux Security Modules (LSM) project framework. The authors theorized that because hooks define the kinds of authorizations, including sensitive security operations, that a module can enforce, the consistency in authorizations is dependent on the proper placement of the hooks making consistency an indicator of correct hook placement.

Whenever a security sensitive operation is performed as a specific event, a set of LSM hooks must have mediated in that operation. While there are benefits to locating the hooks inside the kernel, their location makes a mediation interface harder to see, so the controlled operations and their mapping to policy operations are also harder to see. The authors noted that there was no location inside the kernel similar to the system call interface at which all the kernel’s controlled operations that access security sensitive data must pass, making pin-pointing such operations more difficult. In the absence of such a location, the authors sought a model to help identify controlled operations in the kernel, determine controlled operations authorizations requirements, and compare actual hook authorizations to authorization requirements.

In arriving at a solution, the authors considered the fact that LSM authorization hooks were almost always placed correctly making inconsistencies in authorization a sign of trouble, and that consistency is dependent on context. To collect and analyze authorizations, they established a system of logging generation tool using run-time analysis of the kernel and static analysis of its source code, and an authorization consistency analysis tool such as JaBA (a Java static analysis tool) to collect the logs. They also discussed improvements to the overall analysis that could be made using JaBA data flow analysis. They were able to identify operations that were irregular or unexpected by analyzing the output of a logging tool, and in this way found four anomalies that could have been exploited but were corrected with help of Linux Security Module users.

The concept of Layered Proving Trees and Its Application to the Automation of Security Protocol and Verification

2006-10-28T17:02:00.000-07:00

Dojen, R., & Coffey, T. (2005). The concept of Layered Proving Trees and Its Application to the Automation of Security Protocol and Verification. ACM Transactions on Information and System Security, 8, 287-311. Retrieved September 13, 2006, from the ACM Digital Library database.

In this article, Dojen and Coffey presented the theoretical concept of Layered Proving Trees as a way of automatically employing a logically based security protocol verification.

While security protocols are important to maintaining secure communications, their construction leaves them vulnerable to attack. Verification of security protocols is essential but techniques used have had limited success. In response, the authors proposed the use of Layered Proving Trees using modal logics. The bonuses of Layered Proving Trees include that they have few resource requirements, allow for easy tracing of all decisions after completion of the proofs, and allow for the performance of exhaustive searches for proof of traces.

The authors explained the basic structure of a Layered Proving Tree including its levels, nodes (children and parents), and links between them, and then presented an algorithm which can be used to construct a Layered Proving Tree. They addressed implementation issues including proof of soundness (only true conclusions are reached) and proof of completeness (all true conclusions are reached), and also addressed avoiding non-termination which happens when the construction algorithm never runs out of nodes to be expanded. Non-termination can be classified into two groups: direct non-termination and indirect non-termination (which caused non-termination with other postulates). The authors suggested ways of preventing both types of non-termination.

The authors addressed the logic-specific issues of the Layered Proving Tree in a case study for the previously developed GNY logic. The issues were grammar, unification of terms, structure of postulates, and termination. The grammar developed had statements as its basic unit. A protocol was defined as a group of statements each consisting of a principal, operator and data. Data was an atom, a conjunction of data, data encrypted under a symmetric, public or private key, or the result of a function applied to some data. The type of data provided the idea of giving public and private keys to principals and the concept of two principal sharing secret and symmetric keys. The atoms of the grammar were: symmetric, public and private keys, principals, nonces, timestamps, functions and hash-functions.

The authors then set up a prototype and tested it against many security protocols, some of which had well known problems such as those in the BCY protocol. The automatic verifications from the prototype corresponded to the manual verifications, including detection of all the known problems in the protocols that were studied. Performance and scalability issues of setting up the prototype were summarized. The author’s results showed that a Layered Proving Tree has low memory and computing power requirements.

In conclusion, the Layered Proving Tree approach modeling the process of logic-based security protocol verification was proven to be effective and correc

A Framework for constructing Features and Models for Intrusion Detection Systems

2006-10-28T17:01:00.000-07:00

Lee, W., & Stolfo, S.J. (2001). A Framework for constructing Features and Models for Intrusion Detection Systems. ACM Transactions on Information and System Security, 3, 227-261. Retrieved September 13, 2006, from the ACM Digital Library database.

In this article, Lee and Stolfo described Mining Audit Data for Automated Model for Intrusion Detection (MADAM ID), a framework that uses data mining to compute intrusion activity patterns and create intrusion detection models, and proposed improvements to make intrusion detection systems more systematic and automated.

Of the two main intrusion detection techniques, misuse detection focuses on identifying typical attack patterns and locations. Because novel attacks are non-typical, misuse detection methods are not effective in combating them. Also, non-typical or anomaly detection systems are apt to generate a higher rate of false alarms than misuse detection systems. To develop Intrusion Detection Systems (IDSs) to address these techniques, MADAM ID employs the use of data mining programs to collect large stores of data which is processed into ASCII network packet information. After being summarized as connection records, data mining programs are used to find re-occurring patterns and extract essential and non-essential features. Classification algorithms are then used to create intrusion detection models. The authors proposed introducing new tools to the framework including replacing manually coded intrusion patterns with learned rules, using patterns found in the audit data to selected system features, and using meta-learning as a means of creating a model that incorporates evidence from many base models and for predicting relationships by a number of classifications. The reasons for using meta-learning were to improve efficiency of combining intrusion detection models and improve the accuracy of classifications.

The authors experiments demonstrated that user anomaly detection models could be created using re-occurring patterns mined from audit data. The patterns could also be used as a guide for choosing statistical features to build classification models. The authors stated that since anomaly detection models are the only means of finding innovative intrusions, their future work would be creating algorithms for learning network anomaly detection models. The authors also indicated that ID models need to consider costs such as the costs of development, operation, damages of an intrusion, and detecting and responding to an intrusion.

Effective Role Administration Model

2006-10-28T17:00:00.000-07:00

Oh, S., Sandhu, R., & Zhang, X. (2006). An Effective Role Administration Model Using Organization Structure. ACM Transactions on Information Security and System Security, 9, 113-137. Retrieved September 13, 2006, from the ACM Digital Library database.

In this article Oh, Sandhu and Zhang reviewed the Role-Based Access Control (RBAC) model, a model routinely used by enterprises, and proposed their own model, Administrative RBCA ’02 (ARBAC02) which improves on the RBAC model.

RBAC sought to administer security systems by using an organizational concept of rules to determine user access. A later improvement on RBAC, Administrative RBAC ’97 (ARBAC97), sought to improve on the original model by allowing for decentralized administration. ARBAC97 was made of three parts: User-Role Assignments ’97 (URA97) which used user pools and role ranges to decentralize user-role administration, Permission-Role Administration ’97 (PRA97) which used permission pools and role ranges to decentralize permission-role administration, and Role-Role Administration ’97 (RRA97) which used a role hierarchy to assign access rights to users. While URA97 sought to decentralize user-role administration, its drawbacks included that it required many steps for single user-role assignments and even more for higher destination roles in a role hierarchy, allowed for redundant role assignments, and had a restricted construction of user pools resulting from the use of user pools, prerequisite rules and a role hierarchy. While PRA97 was designed to decentralize permission role administration, it had the same problems at URA97 as well as the unwanted flow of permissions.

Unlike ARBAC97, ARBAC02 has a flexible make-up of user and permission pools by using organizational structure steps in role administration. First, users and permissions are granted to organizational units (OTs) by human resources and an information technology department. Next, security administration personnel grant the users and permissions in OTs to regular roles. Unlike the top-down method used in ARBAC97, ARBAC02 proposed a bottom-up inheritance for permission-role administration. ARBCA02 allots common permissions to lower positions and non-common permissions to higher positions in a Permission Organizational Structure (OS-P). This allows senior roles within the model hierarchy to inherit common permissions.

The authors also illustrated Organizational Structure User Pools and Permission Pools (OS-U/OS-P) in other access control models like Access Control Lists (ACL) and Lattice-Based Access Controls (LBAC) where access control choices are made beyond the control of one individual. An OS-U has all the users who are assigned by Human Resources in an organization while a Permission Organizational Structure (OS-P) is a hierarchy of organizational units shown as a permission pool. Since it is important that permission inheritance travels downward, an OS-P has an inverted tree structure, a maximum organization unit and only one direct child. An OS-P has permissions that were previously given by IT personnel within an organization. The authors therefore showed that organizational structure user pools and permission pools were a comprehensive solution to security administration for different access control methods.

Access Control

2006-10-28T16:59:00.001-07:00

Heingartner, U., & Steenkiste, P. (2005). Access Control to People Location Information. ACM Transactions on Information Security and System Security, 8, 424-456. Retrieved on September 13, 2006, from the ACM Digital Library database.

In this article, the authors Heingartner and Steenkiste recognized that information concerning a person’s location needs to be available in a ubiquitous computing environment, but acknowledged that the unauthorized release of such information is a problem. In response, the authors proposed a model for access control of location information utilizing certificates that are stored in a decentralized, distributed way.

There are two basic types of people location services within a system: those that have information on the location of a person (such as a calendar service that has a person’s schedule), and those that have information on the location of devices (such as cellular telephones and laptop computers). Location policies determine which entities or persons have permission to learn a person’s location information, and for security reasons, only services that utilize access control are granted such location information.

The authors then presented a formal model requiring services to react to a location request after going through a location policy check which verifies that the entity making the request had access. For forwarded requests, the services need to be certain that a requesting service is trusted. The formalism the authors proposed in their decentralized architecture for a trust management system utilizes SPKI/SKSI certificates. Requests are composed of these digital certificates with policy and/or trust statements, which can be forwarded or delegated to a second entity by chains of policy or trust statements. The authors identified that the components needed for access control are a client who submits a request on a person’s location, and a mediating information service who forwards or creates the request for a device’s location as per the location policy. That service must check to see if it received the request from a trusted source, and then leaf services give location information based on what technology is being used. A certificate repository consists of certificates for entities that are either policy or trust statements (both of which are locally stored in an Access Control List (ACL)) or membership statements.

The authors showed through the prototype they developed in RSA and DSA-based signature generation that, compared to the cost of setting up a secure connection, the costs of an ACL are small. Their findings with ACLs showed that DSA-based signatures were 41% less expensive than RSA-based signatures. For clients with limited resources, they suggested the use of DSA rather than RSA for signing operations (in conjunction with key caching). The costs of proving that a service is trusted is similar to the cost of verifying a person’s digital signature in experiments. This cost can be reduced by caching and further lowered when queries are made multiple times. With caching, DSA performance increased by 22%, and RSA performance increased by 43%.

In conclusion, the authors, by analyzing the access control needs of a people location system, have shown that their design has the following advantages: users or a central authority can create the policies, certificates do not need to be centrally housed thus avoiding bottlenecks, digital certificates and not the identity of the issued queries need to be given to the system, an entire group can be given access, and access control can be delegated.

Battery Power

2006-10-28T16:59:00.000-07:00

Chandramouli, R., Bapatla, S., & Subbalakshmi, K.P. (2006). Battery Power-Aware Encryption. ACM Transactions on Information Security and System Security, 9, 162-180. Retrieved on September 13, 2006, from the ACM Digital Library database.

Because the battery power of wireless devices is limited, they are vulnerable to attacks such as brute-force cryptanalysis attacks when their security parameters cannot be supported due to low battery power. The authors’ goal is to model and measure power usage of crypto algorithms to identify and thus minimize such security risks.

The stream and block ciphers the authors used for this paper were DES (a 64 bit symmetric block cipher), IDEA (a 64-bit plaintext block cipher), GOST (a 64-bit block encryption algorithm), and RC4 (a variable key-size cipher with a key stream independent of the plaintext). For the experimental hardware portion used to gather power consumption data, the writers used a laptop running a version of Oprofile for Red Hat Linux 2.4.8 adapted to monitor power value for different functions. The power used by the laptop to encrypt and decrypt algorithms in ten random plaintext data sets was measured as a function of the power going into the laptop, and the power consumption value was calculated as the product of the current and voltage used. The profiled data obtained from running the encryption algorithms on the laptop showed that power consumption changed linearly with the number of rounds in the DES, IDEA, and GOST encryption algorithms. (When the two part algorithm of substitution and permutation is applied once with a key, this is termed a “round”). The rate of change of power with respect to the number of rounds was the largest for IDEA, the smallest for GOST, and the power consumption of RC4 varied non-linearly with respect to the length of the key.

Although often used, the authors observed that there are no constructions of block ciphers that offer unconditional security. In order to assess the effectiveness of an encryption algorithm, they proposed subjecting it to a cryptanalysis attack such as a brute-force attack in which all possible encryption keys are tested. Since rounds and key length affect power consumed, a measure of security can be determined by comparing block cipher vulnerability in such an attack. By considering a linear attack of the DES algorithm, the authors determined that the vulnerability of a cipher can be defined as a ratio of the maximum number of block length plaintexts for such an attack to the number of plaintexts using a cryptanalysis algorithm.

To optimally allocate the battery power for a given number of data packets, each with different security requirements, without exceeding the power available, they proposed optimization formulation 1 and arrived at an algorithm they called GreedyAlloc_Power. Also, to determine optimal battery power where a relationship between plaintext-ciphertext pairs and cryptanalysis success rate is unavailable, the authors proposed optimization formulation 2 and arrived at an algorithm they called GreedyAlloc_Round. When the authors used the GreedyAlloc_Power algorithm, they found that an equal allocation of power to all packets regardless of vulnerability was inefficient, and when using GreedyAlloc_Round, that the cryptanalyst needed a factor of 2^8 more plaintexts to equal the performance of equal resource allocation.

In conclusion, the authors theorized that by using the algorithms they proposed, security provided by encryption algorithms can be optimized within the power limitations of a battery-powered device.

Annotated Bibliography

2006-10-28T16:58:00.000-07:00

Park, J.S., Ahn, Gail-Joon, & Sandhu, R. (2001). Role-Based Access Control on the Web. ACM Transactions on Information and System Security, 4, 37-71. Retrieved on September 13, 2006, from the ACM Digital Library database.

In this article, authors Park, Ahn and Sandhu observed that current ways to access Web Control on Web servers, based on a user’s identity, were inadequate for enterprise-wide systems. In response, they proposed the use of Role-Based Access Control (RBAC) in large-scale Web environments with the addition of user-pull and server-pull architectures, as well as secure cookies and smart certificates.

Access control methods currently used on Web servers tend to use individual’s identity, a method not compatible with enterprise-wide systems. Instead, the authors proposed the use of RBAC to manage and enforce security in such environments. With RBAC, permissions are associated with roles and users are assigned to roles. A role forms the basis of an access control policy. In RBAC, administrators can make roles, grant permission to them, and assign users to the roles based on their job responsibilities. Users can make sessions in which they can start a subset of roles to which they belong. Each of these sessions can be assigned to many roles, but it maps to only one user. In this way, RBAC guarantees that only authorized users can get to access certain data or resources. It also supports information hiding, least privilege, and the separation of duties.

In order to manage role-based access control (RBAC) in Web environments, the authors proposed the use of user-pull and server-pull for roles. In user-pull, a user pulls his roles from the roles server and then shows them to the web servers. In server-pull, each Web server pulls the user’s roles from the role server. In the user-pull architecture, the binding of roles and identification for every user must be supported. There are three main components in both user-pull and server-pull architectures: a Web server, role server, and client. A role server holds user-role assignment (URA) information (for the domain). A web server has a table for permission-role assignment (PRA) which states the necessary roles for resources in the web server.

Another contribution of this paper was the concept of secure cookies as a way of getting information between the browser and the Web server. Cookies are insecure because they are transmitted in clear text. The authors described how to change regular cookies that have no security into secure cookies that resist cookie harvesting, network security and end-system threats. The use of secure cookies is a transparent process to users, and can be applied to browsers and Web servers. Secure cookies are made by cryptographic technologies to maintain integrity, authentication in that authentication services verify who owns the cookies, and confidentiality. There are two types of cryptographic technologies for secure cookies: public-key based and secret-key-based. The authors used a public-key based solution by a PGP package with Common Gateway Interface (CGI) scripts. The authors decided to use Pretty Good Privacy (PGP) for secure cookies in their implementation. Secure cookies only support user-pull since the cookies are stored in the user’s machines. On the other hand, LDAP and smart certificates both support user-pull and server-pull architectures.
Authors Park and Sandhu presented the concept of smart certificates in a work in 1999, and in this article the authors described an RBAC implementation for smart certificates in a user-pull scenario. The basic idea of X.509 certificates, the predecessor to smart certificates, was to bind users to keys. Smart certificates are extended X.509 certificates for the Web and RBAC which support user-pull and server-pull architectures. They can maintain several certification authorities (CAs) without losing maintenance, contain attributes, give postdated and renewable certificates, and keep confidentiality.

To demonstrate the use of their ideas, the authors implemented each architecture by using well known technologies (i.e. X.509, cookies, SSL and Lightweight Directory Access Protocol (LDAP)) that could be used in conjunction with Web technologies. The authors discussed the use of RBAC on the Web using different technologies on different architectures, and compared the tradeoffs of different approaches on the basis of their experiences.

The authors proposed that successfully combining RBAC and the Web can make a huge impact on the deployment of effective enterprise-wide security in large-scale systems, and believe that their contributions in this paper were important in giving strong security management based on users’ roles on the Web.

Linux Paper

2006-03-06T15:26:00.000-08:00

GNU/Linux: A Convergence of
Ideas and Ideals

By: Adam Norten

Introduction

The following is a historical overview of the birth of GNU/Linux. Rather than beginning with Linux itself, however, this paper begins by looking at UNIX. As the first operating system, UNIX naturally opened the door and set the bar by which other operating systems would be measured.

Perhaps most importantly to the development of Linux, restrictions over broad use of UNIX ultimately created a technology vacuum which needed to be filled. This is a common story throughout history: those with technological advances attempt to hoard their discoveries in order to maintain some type of advantage over others, whether it be a military, financial, or technological leg-up on others. As has happened throughout history, new ideas are difficult to contain. Enough information about the new technology at some point leaks out and is seized upon by thinkers and tinkerers who pull apart and analyze it, recreate it, and then ultimately take it one step further. Such was the work of Richard Stallman and Linus Torvalds in developing GNU/Linux, but it all started with UNIX.

UNIX – A Not-So-Well-Kept Secret

UNIX is a computer operating system originally developed in 1960-70s by AT&T Bell Labs. (“UNIX”) In the 1960s, MIT and others developed an experimental operating system called Multics. (“UNIX”) Work on Multics led to another operating system called Unics and then UNIX itself. (“UNIX”)

UNIX was designed to be a portable, multi-tasking and multi-user operating system. (“UNIX”) “Multitasking” means that it can run more than one program at once, and “multi-user” means that it can be accessed by many users at once (Boom). Its importance cannot be overstated. The architecture of the Internet itself was created with UNIX. (Boom) UNIX is currently owned by the Open Group, although ownership to the right to UNIX source code is claimed by others. (“UNIX”)

In the early 1970s, UNIX was developed by Bell Labs to the point where it was usable as a text processing system which Bell used to process patent applications. (“UNIX”). A giant move towards making it more widely usable occurred in 1973 when it was converted to C programming language. This move meant that it could later be more easily modified for use on other machines thus making it portable, and the code became more concise and compact paving the way for increased development of UNIX. (“UNIX”)

At this point in its development, AT&T made UNIX available to universities, commercial firms as well as the U.S. government. This was under licensing agreements which included all source code except the kernel which was machine dependant. That kernel’s source code was written in PDP-11 assembly code. (“UNIX”)

In 1970s and early 1980s, its use in academic circles led to its wide adoption by commercial enterprises including Sun Microsystems. (“UNIX”) By the early 1980s, different versions or “variants” of UNIX were for sale. Throughout the 1980s, AT&T and others continued to develop their own UNIX variant. During this time, however, new commercial UNIX released ceased to include the all important source code. Between 1987-1989, AT&T and Sun Microsystems merged many different variants of UNIX into one package threatening the end of competing vendors and driving licensing fees up. In 1990, the Open Software Foundation released OSF/1, a UNIX variant, to counteract AT&T’s actions. In response, AT&T and other licensees formed UNIX International to counteract OSF/1. (“UNIX”)

Thus by 1991, UNIX variants were widely used by commercial enterprises, but were typically inaccessible for individual users for two main reasons. First, they have become too expensive for small users to afford. (Hasan) Second, the source code, which was at one time included, had become a guarded commodity and was no longer published publicly. (Hasan)

The GNU Project – Free Software for the Masses

Critical to the technical development and easy accessibility of Linux was the GNU Project. GNU standing for “GNU’s Not UNIX” (Boom) and was the brainchild of MIT computer programmer Richard Stallman. Stallman established the project in 1983 with the goal of developing and distributing a complete UNIX-like operating system composed entirely of “free software.” (Hasan; “Linux”) As GNU’s website clarifies, “The word ‘free’ in ‘free software’ pertains to freedom, not price. …[O]nce you have the software you have three specific freedoms in using it. First, the freedom to copy the program and give it away to your friends and co-workers; second, the freedom to change the program as you wish, by having full access to source code; third, the freedom to distribute an improved version and thus help build the community.” (“Overview of the GNU System”:)

Stallman’s quest was based not only on his phenomenal programming skills, but also on his personal belief that the prosperity and freedom of the public in general required that software be free and easily accessible. (Stallman. “Why Software Should Be Free.”) When Stallman first started working with MIT in 1971, his working group exclusively used free software. At that time, even computer companies distributed free software. Programmers such as Stallman were free to cooperate with each other and did. By the 1980s, software had become proprietary. (“Overview of the GNU System.”). Stallman felt that traditional copyright laws which were developed to address ownership issues of the printed word were inadequate to address the new technology of software. (Stallman. “Why Software Should Not Have Owners”) He theorized that restrictions on the distribution and modification of programs caused three levels of harm to users in particular and society in general. First, it meant that fewer people could use and benefit from the program itself. Second, those who had enough money to purchase and therefore use it could not adapt or improve on it. And third, users could not learn from the program or base new work on it. (Stallman. “Why Software Should Be Free.”) Ultimately, Stallman concluded that programmers “have the duty to encourage others to share, redistribute, study, and improve the software we write: in other words, to write ‘free’ software.” (Stallman. “Why Software Should Be Free.”) As such, Stallman conceived the GNU project in order to bring back the cooperative spirit he felt prevailed in the computing community back in the 1970s. (“Overview of the GNU System”)

In 1984, Stallman wrote the GNU C Compiler (GCC), considered one of the most efficient and robust compilers developed. (Hasan). By 1991, the GNU project had also created many tools, but had failed to develop a usable operating system. (Hasan) GNU had developed its own kernel in 1990, but due to a lack of cooperation from programmers in Berkeley, switched to using the Mach microkernel instead. This switch did not bring about the results desired leaving GNU without a usable kernel. (“Linux”)

Tanenbaums’ Minix

Also significant to the development of Linux was a predecessor operating system named Minix. Minix was written by Andrew Tanenbaum, a Dutch professor born in the United States. (Hasan) Tanenbaum wrote Minix as a teaching tool for his student. He essentially developed Minix from scratch but based it on the Bell Labs variant of UNIX. (Hasan; Hales) Tanenbaum was able to pair down this UNIX-type operating system to fit into an 8086 class PC. (Hales) Most significant to the Linux story, Tanenbaum wrote the book “Operating Systems” which gave the 12,000 lines of operating source code written in C and assembly. (Hasan)

Linux Arrives

By 1991, the stage was set. The average PC user had few options concerning the operating system they could use. The majority of users had to use DOS which was owned by Bill Gates. (Hasan) As to an alternative operating system, GNU was struggling to find a usable kernel. However, in Finland, another kernel was germinating which would ultimately become known as Linux. (“Linux”)

In 1991, at the University of Helsinki, a second year student by the name of Linus Torvalds was also working on developing a kernel to support a UNIX-like operating system. (“Linux’s History”; Hasan) To do so, he used Tanenbaum’s Minix. But because Tanenbaum did not permit others to extend the Minix operating system, Torvalds began developing his own. (“Linux”)

Unlike Stallman and the GNU Project, Torvalds was not motivated by an idealist drive to create an operating system for the masses. He began working on the Linux kernel as a hobby (“Linux”), and later admitted that, “Linux was just something I had done, and making it available was mostly a ‘look at what I’ve done – isn’t that neat?’ kind of thing.” (Ghosh)

On August 25, 1991, Torvalds communicated to the Minix news group by email, “Hello everyone out there using Minix – I’m doing a (free) operating system (just a hobby, won’t be big and professional like GNU) for 386(486) AT clones.” (Hasan) Despite Torvalds humble predictions, his operating system, later named “Linux,” exceeded his and the world’s expectations. The first version of the Linux kernel was released to the Internet on 9/17/91 (“Linux”), and next version came out shortly thereafter on October 2, 1991. (Hasan)

Amazingly, Torvalds received discouraging comments from Tanenbaum himself who commented in an email to Torvalds, “Be thankful you are not my student. You would not get a high grade for such a design.” (Hasan) And Tanenbaum later commented, “Linux is obsolete.” (Hasan) Despite Tanenbaum’s lack of favor, Linux standing for “Linus’ Minix” quickly surpassed its name-sake in functionality and widespread use. (“Linux”)

Torvalds developed the Linux kernel for his computer, a PC with an Intel 386 chip. His kernel was a monolithic kernel such that the device drivers are part of the kernel proper. Unlike the DOS on the Intel chip, Torvalds’ operating system allowed for multitasking. (“Linux”) Linux incorporated demand paging, copy-on-write, and swap space. (“Linux’s History”)

Torvalds ultimately joined forces with the GNU project, and worked with its programmers to adapt the Linux kernel to work with GNU’s already developed components. (“Linux”) With GNU’s support, the first complete version of Linux came available in 1994 (Boom), and it was ultimately licensed under GNU public license (GPL) (Hasan; “Linux”; Boom) sometimes referred to as “copy-left software” (Boom) or “share and share alike code.” (“Linux”)

Perhaps the open licensing of Linux was as important to the ultimate development of Linux as the initial work Torvalds did in creating it. By joining the open source software movement, Torvalds allowed Linux to achieve the full potential Stallman dreamed of when he originally created the GNU project. (“Linux’s History”) As open source software, users can take Linux, improve upon it, and distribute their own version of it. In doing so, however, they cannot restrict the rights of users who purchase the software. They must also make it clear that the software is covered by the GPL and provide the complete source code for the software at no cost. (“Linux’s History”)

Interestingly, Torvalds’ releasing Linux to the world under the GNU Public License unleashed its potential and improved exponentially upon an already superior model. Because the Linux kernel and other Linux utilities can be easily downloaded off the Internet, users can instantly change its source code to fix any software bugs found. This in turn decreases the fix time from weeks to a matter of hours. (“Linux’s History”) Because Linux has a fanatical following, whenever a new piece of hardware comes out, the Linux kernel is tweaked to take advantage of it. (Hasan) Because an unlimited number of people are able to work on Linux, as opposed to a limited group of computer programmers who typically work on commercial software products, the combined efforts of programmer-hours spent on perfecting Linux is staggering. A study of Red Hat Linux 7.1 found that a particular distribution contained 30 million source lines of code, and the Linux kernel contained 2.4 million lines of code. That translated to about eight thousand person-years of development time. Had it been developed by conventional means, it would have cost 1.08 billion dollars to develop in the United States. (“Linux”)

Linux has become one of the fastest growing operating systems in history. (Hasan) Because of GNU, Linux has many utilities to offer. (“Linux’s History”) Linux packages and distributions are being offered by Red Hat, Corel, Samba, Caldera, SuSE, Debian, and Slackware. (“Linux’s History”; Hasan; Hales) It is now used not only by individuals but by big businesses such as IBM and Compaq. (“Linux’s History”; Hasan; Hales)

Besides running PCs, Linux was ported to different platforms including running handheld computers (it is becoming an alternative to Windows CE and Palm OS), and embedded systems such as mobile phones and personal video recorders. (Hasan) The Sony Playstation 3 video game console released in 2005 will runs Linux. (“Linux”) The TiVO digital video recorder uses a customized version of Linux. (“Linux”)

On the other end of the spectrum, Linux has been used to run supercomputers (“Linux”) In 1996, researchers at Los Alamos National Laboratory ran Linux on 68 PCs as a single parallel processing machine to simulate shock waves. (Hasan)

Linux offers many benefits to users. While Linux originally viewed as something for computer professionals only, Linux distributions have become more user-friendly. (“Linux”) While difficulty installing it once was a barrier to wide adoption of Linux-based systems, the process has been simplified in recent years. (“Linux”)

Because it is open source software, users are constantly contributing security upgrades such as anti-virus software and firewalls, oftentimes in immediate response to a new security threat. (“Our Linux Top 10 Reasons”) Some users report superior patch management from Linux as opposed to Windows. (“Why Linux is a Better Choice Than Windows”) One study in 2002 found that Windows installations required twice the number of administrator hours on the average amount of time spent patching systems and dealing with other security related issues. (“Why Linux is Better Choice Than Windows”). Linux is a more stable program and tends to crash less than Windows. Linux typically comes with the Apache web server, and email server, router/firewalls capabilities and SQL databases, extras that would cost much more money on Windows. (“Our Linux Top 10 Reasons”) Because it is POSIX compliant, Linux applications developed for Linux can be used on other POSIX compliant UNIX derivatives with minimum effort. While commercial software support costs extra money and is typically limited in time, the open source community of users is available via the Internet to answer technical questions. Different flavors of Linux exist for users to pick and choose which best suits their needs. For Windows users, the product choice is more limited. Because so many active developers use and participate in Linux’s development giving a large quantity and good quality of free feedback from the field, Linux’s development is at a distinct advantage over Windows, which has a limited number of in-house technicians working on it. Linux can be obtained for free and different flavors can be purchased. (“Our Linux Top10 Reasons.”) Because of its low price, Linux is ideal in Set/top boxes and devices such at the Simputer, a computer aimed at developing nations. (“Linux”)

Conclusion

In summary, a number of significant achievements preceeded and contributed to the development of Linux. Initially there was UNIX, which was designed to be a portable, multi-tasking and multi-user operating system. However, by the 1990s, UNIX’s inaccessibility due to its cost and closely controlled source code forced computer programmers to find an alternate operating system to use. Next, there was the GNU project which was critical to the development and accessibility of Linux. The goal of the GNU project was to develop and distribute an entirely “free software” operating system. While GNU made significant advances towards developing an alternative to UNIX, the project failed to develop a usable kernel. Also significant to the development of Linux was a predecessor operating system named Minix. Ultimately, it was Minix that Linus Torvalds used to develop a kernel to support a UNIX-like operating system. Torvalds ultimately joined forces with the GNU project and issued Linux under GNU’s GPL. The open licensing of Linux was as important to the development of Linux as the initial work that Torvalds did in creating it. While Linux was originally viewed as for computer professionals only, later distributions of Linux have become more and more user-friendly.

It should be noted that even in the peaceful world of open source software, there have been some disagreements. GNU is adamant that it be called “GNU/Linux,” a demand which Linus Torvalds finds “ridiculous.” The disagreement over name aside, the collaboration between GNU and Torvalds in creating Linux and making it openly available continues to change the world.

Stallman and the GNU project have stated that the project’s ultimate goal is to “provide free software to do all of the jobs computer users want to do—and thus make proprietary software obsolete.” (“Overview of the GNU System”) While this lofty goal may never be reached, GNU project and Torvalds have already made a contribution for which computer programmers all over the world are grateful – Linux.

References

Boom, Clyde. Hello Linux! A Comprehensive Hands-On Course.

Ghosh, Rishab Aiyer. “First Mind Interview with Linus Torvalds: what Motivates free Software Developers?.” 1998. First Monday. 25 February 2006 http://www.firstmonday.org/issues/issue3_3/torvalds/.

Hales, John. Linux – Quick Study. Boca Raton: Bar Charts, Inc., 2001.

Hasan, Ragib. “History of Linux.” The Linux Gazette. 1 December 2004. 11 February 2006
Lewiston, NY: Lancom Technologies, 2003.

“Linux.” Wikipedia, the free encyclopedia. 11 February 2006 .

“Linux’s History.” The Penguin’s Guide to Linux. Thinkquest. 11 February 2006 .

Our Linux Top 10 Reasons. 2004. Reichel.net. 13 February 2006 http://www.reichel.net/opensource/linuxtop10.html.

“Overview of the GNU System.” GNU Project – Free Software Foundation. 1996. Free Software Foundation. 28 February 2006 http://www.GNU.org/GNU/GNU-history.html>.

Stallman, Richard. “Why Software Should Not Have Owners.” GNU Project – Free Software Foundation. 1994. Free Software Foundation. 23 February 2006 http://www.GNU.org/philosophy/why-free.html>.

Stallman, Richard. “Why Software Should be Free.” GNU Project – Free Software Foundation. 24 April 1992. Free Software Foundation. 23 February 2006 http://www.GNU.org/philosophy/shouldbefree.html>.

“UNIX.” Wikipedia, the free encyclopedia. 13 February 2006 .

(Novell) Why Linux is a Better Choice than Windows. 2005. Novell. 13 February 2006 http://www.novell.com/linux/truth/better_choice.html.

Network Project

2005-12-16T11:24:00.000-08:00

Table of Contents

Table of Contents ………………………………………………………………………………. 2

I. Introduction ………………………………………………………………………… 2

A. Scenario ……………………………………………………………………….…2

B. Functionality Requirements ……………………………………………………. 2

i. Windows ……………………………………………………………….. 2
ii. LINUX …………………………………………………………………. 3

C. Services to Consider …………………………………………………………. . 3

II. Analysis ……………………………………………………………………………. 4

A. Project Proposal ………………………………………………………………. .4

i. Windows (Windows 2003 Server) ……………………………………. .4

1. Active Directory, Primary DNS, and WINS Server
(IP 10.207.32.4) (Jeff H., Jeff S., & Adam) ……...……………. 4

2. Terminal Server (IP 10.207.32.2) (Mustapha, Adam, & Jeff H.)14

3. DHCP Services and DHCP Relay Services (IP 10.207.32.3)
(Tarik & Jeff H.)………………………………………………..19

4. Router (IP 10.207.32.1 and 10.207.33.1) (Jeff H.)

ii. LINUX (Red Hat Server) …………………………………………….. 24

1. Secondary DNS and DHCP Services (IP 10.207.33.2)
(Mustapha & Jeff H.) ….………………………………………24

2. SAMBA, NFS, and CUPS Services (IP 10.207.33.3) (Steve,
Adam, Jeff H. & Jeff S.) ………………………………………31

3. APACHE and FTP Services (IP 10.207.33.5) (Steve)……….. 34

4. SMTP & POP3 (IP 10.207.33.4) (Adam) ...…………………. 39

III. Conclusion ………………………………………………………………………. 45

IV. References ………………………………………………………………………. 45

I. Introduction

For its CS 545 Group Project, the Class of Fall 2005 including Mustapha Aitzemkour, Steve Ehrlich, Jeff Heiden, Adam Norten, and Jeff Sarris, has been assigned the task of developing a computer network for a small hypothetical company. The scenario and network requirements were defined by Professor Ali, and the class members distributed the network building tasks among themselves. This paper will recount the project scenario, definitions and parameters. It will also present basic working definitions used by class participants in completing the project, explanations of the software and programs used, and will include a summary of the work completed by the class members.

A. Scenario

A small company called Manamana, which likes to have a mix of Windows XP and LINUX servers, has hired the Elmhurst College CS 545 Class of Fall 2005 as consultants. The company has a variety of computer equipment running Windows XP, a number of hubs and a few class A IPs. It utilizes a number of laser printers connected to each of its networks. The company would like the class to set up a LAN/WAN such that its current resources can be more efficiently utilized.

Manamana hired the class as its primary network consultant on a contract basis. Our assignment is to make the appropriate proposal, provide detailed configuration recommendations and support our recommendations by implementing them. At the current time cost is not an issue.

B. Functionality Requirements

i. Windows

1. The computer network consists of an ADS Windows 2003 Domain and sub-domains.
2. All client computers use Dynamic Host Configuration Protocol (DHCP) Server to obtain Internet Protocols (IPs) Addresses.
3. We are using internal Windows Internet Name Services (WINS) to resolve the Host Names.
4. We have configured the Terminal Server, so that users and administrators can remotely use and manage the network resources.
5. The users on the two networks (LINUX network and Microsoft Windows Network) have access to each other’s printers.
6. All users on the LINUX network are able to access the file and print services of Windows 2003 network, and visa versa.
7. The Administrator is tired of reconfiguring the desktop settings on each workstation every morning. He wants us to enforce a consistent policy across all workstations such that users, except the Administrator, should not be able to save their Desktop changes.
8. Manamana wants us to make sure that internal networks are protected from security threats. The company owns few Class C IPs, but is using class “A” IPs that they do not own for their internal networks. We are to make sure these addresses are not broadcast to the outside.
9. We will create few Organizational Units (OUs) in each domain and restrict them from accessing particular applications by implementing group policies.
10. We will use roaming profiles to allow users to access different workstations.

ii. LINUX

1. We will implement both a primary and secondary Domain Name Server (DNS) to resolve the Host Names and Domain Names.
2. All client computers have access to a printer.
3. All client computers have access to the file services of a central server via Network File Server (NFS) or Samba.
4. All client computers have access to e-mail; both sending (SMTP) and receiving (POP3), as well as having aliases and virtual accounts configured for users and groups.
5. There is File Transfer Protocol (FTP) access for an administrator.

C. Services To Consider

- Dynamic Host Configuration Protocol (DHCP)
- Domain Name Server (DNS) (primary and secondary / forward zone, reverse zone, cache zone)
- Printing services (CUPS)
- Network File Server (NFS)
- Samba
- Simple Mail Transfer Protocol (SMTP)
- Post Office Protocol version 3 (POP3) configured using software called Webmin.
- Apache for WWW We set this up and configured it using software called Webmin
-WU-FTP
NOTE:
o Every user should has an account on the system (e.g., email address) based on the first initial + last name schema, such that a user by the name of Jeff Heiden has an account jheiden.

II. Analysis

A. Project Proposal

i. Windows (Windows 2003 Server)

1. Active Directory, Primary DNS, and WINS Server (IP 10.207.32.4) (Jeff H., Jeff S., & Adam)

Per the project requirements, the class was to implement a primary DNS server, an Active Directory server, and a WINS server.
Before describing the work done on this portion of the project, the following is a brief explanation of the terms “Domain Name System” and “Windows Internet Name Service.” The Domain Name System (DNS) is a database that contains information about all computers in a TCP/IP network. It is a system which helps Internet users access the Internet more easily, by allowing them to specify meaningful names to web sites and/or other users with whom they want to communicate. When computers talk to each other via the Internet, they use the Internet Protocol (IP) protocol. The IP distinguishes hosts from each other by an IP address. Therefore, a DNS server is needed by the software applications to convert humans’ meaningful names into computer meaningful names (IP addresses) and provide the final user with an easier way to communicate via the Internet.
Each computer name consists of a sequence of alpha-numeric segments separated by periods. For example, a computer name might be: eccnsdns.eccns.local. A Computer name is also called a “Domain Name” and Domain names are hierarchical, with the most significant part of the name on the right. The left-most segment of a name (eccnsdns in the example) is the name of an individual computer. Other segments of the full name identify the group that owns the individual name. In the example, the individual name eccnsdns belongs to the eccns group of names, which is itself belongs to the local group.
To obtain access to a domain (eccns.local in our case), DNS helps clients locate a domain controller, which “stores the objects for the domain in which it is installed” and “accepts account logons and initiates their authentication…and controls access to network resources.” When a client wants to log on to a domain, it sends a query to the DNS server designated in the client TCP/IP configurations. Then the DNS server, which stores information about all domain controllers available in the domain through constant messages containing the availability status of these controllers, will reply back by assigning the right domain controller to that client.
The domain controller (DC) (eccnsdns in our domain) is automatically created as a global catalog server. A Global Catalog server stores the objects and their attributes from all domains in the forest. It contains its own full, writable domain replica (all objects and all attributes) plus a partial, read-only replica of every other domain in the forest. It is built and updated automatically by the Active Directory replication system. The object attributes that are copied to global catalog servers are the attributes that are most likely to be used to search for the object in Active Directory Service (ADS).
The main role of the global catalog is to make it possible for clients to search the Active Directory without having to be referred from server to server until a domain controller that has the domain directory partition storing the requested object is found. Hence, all clients’ requests to the DNS are actually directed by the ADS to the global catalog servers.
To provide fault tolerance in eccns.local, we assigned a secondary, back up DNS server (dns2). The secondary DNS stores the contents of the zone file located in the primary DNS. Both servers (eccnsdns and dns2) are synchronized through their zone files, hence enabling the secondary DNS server to perform name resolution and to be available for clients in case the primary DNS server fails to respond.
Windows Internet Name Service (WINS) provides the equivalent of a DNS server for the NetBIOS namespace in that it resolves NetBIOS names into IP addresses by using the WINS dynamic database to call the exact name records. It offers a distributed database for registering and querying dynamic mappings of NetBIOS names for computers and objects on a network.
In the example below, the following scenario occurs:
1. HOST-A, a WINS client, registers any of its local NetBIOS names with its configured. WINS server: WINS-A.
2. HOST-B, another WINS client, queries WINS-A to locate the IP address for HOST-A on the network.
3. WINS-A replies with the IP address for HOST-A.
WINS reduces the use of local IP broadcasts for NetBIOS name resolution and enables users to locate systems on remote networks easily. Because WINS registrations are done automatically each time clients start and join the network, the WINS database is automatically updated when dynamic address configuration changes are made. For example, when a DHCP server issues a new or changed IP address to a WINS-enabled client computer, WINS information for the client is updated. This requires no manual changes to be made by either a user or network administrator.
Since we have designed our network to host two operating systems (LINUX and Windows), any client that is not a Windows client will use the WINS server designated in its TCP/IP configuration for any NETBIOS names queries.
Installation & Configuration

Before configuring these services, Windows Server 2003 had to be installed and configured. The IP address of the server (10.207.32.4) was statically entered. This is important since this is a server on the network, but even more important because it is also the Primary DNS server. Clients must be able to communicate with all the servers in the network at all times. If a server has a dynamic IP address, the clients will not know that address at all times. The DNS server can track any changes, but obviously this DNS Server address then has to be known to the entire network and cannot change. When setting up a network, dynamic IP addressing should be utilized only for the client PCs. Since this server will also be the primary DNS server, the DNS setting is set to the same as the IP address (10.207.32.4).

After completion of the Windows Server 2003 installation and base configuration, the services are then installed beginning with Active Directory. The reason that this server is a DNS server along with Active Directory is because Active Directory requires DNS to also be installed in order to function properly. The Active Directory service is very closely tied to the DNS service. At the beginning of the installation for Active Directory, the prompt comes up informing of this requirement, so DNS is installed prior to Active Directory. The domain that was chosen is eccns.local in order to distinguish our internal network from any external domain such as a .com address. This is not a requirement, but a good practice to follow when creating an Active Directory domain. After these services are installed, so is WINS.

Configuration begins with DNS. First, a forward lookup zone is created which is the zone most used for DNS queries. The forward lookup is used to resolve an easy to remember domain name to an IP address. The reverse lookup zone, which also needs to be created, is used for resolving an IP address to a domain name. After adding the zones, the records must then be added. When adding records to the forward zone, it can also create the corresponding reverse zone entry automatically. Once all the records are added, DNS can be tested by using nslookup. An nslookup of a domain name (for example eccnsdns.eccns.local) should resolve to an IP address (10.207.32.4) and visa versa, an nslookup of an IP should resolve to a domain name. Once this works, the DNS server is configured properly.

Next, Active Directory is configured. Users were added to Active Directory following a previously determined naming convention, first initial + last name. Once users are added, the next task is to start joining servers and workstations to the domain. At each Windows based computer under System Properties the domain name must be set. By default the workgroup is set to WORKGROUP, but instead of workgroup settings the domain name (eccns.local) must input into the second box. A valid login is required in order to join the domain. Once it is joined to the domain, the Domain Controller can resolve all future logins on that computer. At this point only logins are resolved, however, once roaming profiles are added one can login to their personal desktop from any location on the network as the roaming profile stores all this information on the server.

In order to join the Linux servers to Active Directory, the following steps had to be taken:

1. Stop the winbind and samba services:
/etc/init.d/smb stop
/etc/init.d/winbind stop
2. Edit the Kerberos files to have the right configuration
/etc/krb5.conf
[libdefaults]
default_realm = ECCNS.LOCAL
[realms]
ECCNS.LOCAL = {
kdc = eccnsdns.eccns.local
default_domain = ECCNS.LOCAL
kpasswd_server = eccnsdns.eccns.local
admin_server = eccnsdns.eccns.local
}
[domain_realm]
.eccns.local = eccns.local
3. Edit the Samba files to have the following configuration settings
/etc/samba/smb.conf
workgroup = server
security = ads
realm = ECCNS.LOCAL
encrypt passwords = yes
username map = /etc/samba/smbusers
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
4. Join the domain
net ads join -U administrator -S eccnsdns
5. Restart both the winbind and samba services
/etc/init.d/smb start
/etc/init.d/winbind start
6. Test the join with the following command:
/usr/bin/wbinfo -g
All the groups in the Active Directory structure should be displayed.
Once the Linux server has joined the domain, services, such as Samba, will authenticate any attempted logins to the domain. This allows for a user to be added at a central location and then be able to access, for example, file and print service from the Linux network.

Controlling the Active Directory Environment

There are many ways to accomplish different kinds of control within Active Directory. The tool for exerting most of these controls is Group Policy, the successor to NT 4’s System Policy.

With Group Policy, the administrator of the server can control a wide variety of features like allowing the user to have the “Run” command in their Start menu. Other options include controlling how a user’s desktop appears, providing a particular website within their Favorites menu inside Internet Explorer, or controlling the system time on a PC (by default, normal users cannot change the time on their workstations) as well as controlling other security features.

In our scenario, we were presented with the task of eliminating the administrative task of reconfiguring desktops for non-administrative staff by not allowing users to save their desktop settings. The way we chose to accomplish this task was to create a group policy that prevents such activity and apply it to an Organizational Unit (OU). After creating the OU in Figure 1 called “Domain Users,” the OU was populated with user profiles.

Figure 1.

Using the Group Policy Editor, a snap-in module used in the Microsoft Management Console for Active Directory, the policy called “No changes,” was created. See Figure 2.

Figure 2.

At this point, we attached the group policy to the OU, see Figure 3.

Figure 3.

One important step we discovered was the need to create an OU or use an existing OU of which the Administrator or Administrator Equivalent is not a member. If an Administrator creates a group policy in the same OU to which he/she belongs, they may set a configuration policy against all other users and himself/herself thereby forcing the Administrator to reinstall Active Directory in order to remedy the problem.

Another type of control that can be established is by using roaming profiles. Roaming profiles are used to preserve a user's configuration (desktop, background, etc) and present the user with an identical environment on any computer onto which the user logs. This is done by storing the user’s profile in a central location (in this case, Active Directory), as opposed to the traditional user profile that is stored on the local device. By storing this information in a central location, the information is always the same as long as the user logs onto the same Active Directory environment.

One of the required features of Manamana’s network design was the implementation of roaming profiles on user profiles to allow them to access different workstations. The roaming profile is used to provide the same look and feel to a user’s login profile no matter which machine he/she is logged into within the Active Directory environment.

Roaming profiles are created by location of the user profile path to a shared location. Therefore, a shared location must be created. See Figure 4.

Figure 4.

After creating the shared location, the profile is modified to accommodate the shared location, as depicted in Figure 5.

Figure 5.

After the above was been completed, the final requirement was to give shared permissions to the users so that the Group Policy can be accessed and modified by the user if this is required. Figure 6 shows the security permissions.

Figure 6.

Regardless of which machine a user is logged onto in the domain, he/she can have all of the shortcuts and desktop settings that are viewable on any other desktop. Roaming profiles are a very good choice for consistency, but the user must have the correct permissions to access the shared location otherwise the roaming profile will not work and the user will be logged on with a default profile.

1. Terminal Server (IP 10.207.32.2) (Mustapha)

In this portion of the project, we were required to set up Terminal Server for Manamana.
Microsoft Windows Terminal Services was introduced for Microsoft Windows NT with a separate Terminal Server Edition. Beginning with Microsoft Windows 2000, and continuing on to Microsoft Windows 2003, it became a fully integrated part of all Windows servers.
Terminal Server provides an effective and reliable way to distribute Windows-based programs with a network server. With Terminal Server, a single point of installation allows multiple users to access the desktop on a server running one of the Windows Server 2003 family operating systems. Users can run programs, save files, and use network resources as if they were sitting at that computer.
You can use Terminal Services Manager to manage and monitor users, sessions, and processes on any terminal server on the network. It can also be used to:
• Display information about servers, sessions, users, and processes.
• Connect to and disconnect from sessions.
• Monitor sessions.
• Reset sessions.
• Send messages to users.
• Log off users
• Terminate processes.
This is how it works. The service provides remote access to a Windows desktop through "thin client" software, allowing the client computer to serve as a terminal emulator. Terminal Services transmits only the user interface of the program to the client. The client then returns keyboard and mouse clicks to be processed by the server. Each user logs on and sees only their individual session, which is managed transparently by the server operating system and is independent of any other client session. Client software can run on a number of client hardware devices, including computers and Windows-based terminals. Other devices, such as Macintosh computers or UNIX-based workstations, can use additional third-party software to connect to a server running Terminal Server.
One of the many benefits of using Terminal Server is centralized deployment of programs. With Terminal Server, all program execution, data processing, and data storage occur on the server, centralizing the deployment of programs. Terminal Server ensures that all clients can access the same version of a program. Software is installed only once on the server, rather than on every desktop throughout the organization, reducing the costs associated with updating individual computers.
Another benefit from using Terminal Server is improved speed. Terminal Server brings Windows Server 2003 family operating systems to desktops faster. Terminal Services Helps Bridge the gap while older desktops are migrated to Microsoft® Windows® XP Professional, providing a virtual desktop experience of any Windows Server 2003 family operating system to computers that are running earlier versions of Windows.
Terminal Services clients are available for many different desktop platforms including Microsoft MS-DOS, Windows-based terminals, Macintosh, and UNIX. Additionally, a Web-based version of the Terminal Services client (Remote Desktop Web Connection) provides Terminal Services connectivity to computers with Web access and an Internet Explorer browser. (Connectivity for MS-DOS, Macintosh, and UNIX-based computers requires additional software.)
Terminal Services also takes full advantage of existing hardware. Terminal Services extends the model of distributed computing by allowing computers to operate as both thin clients and full-featured personal computers simultaneously. Computers can continue to be used as they have been within existing networks while also functioning as thin clients capable of emulating the Windows XP Professional desktop.
One of the functionality requirements Manamana presented was that we configure a Terminal Server so that users and administrators can use and manage the network resources remotely. Remote Desktop for Administration (formerly known as Terminal Services in Remote Administration mode) provides remote access to the desktop of any computer running one of the Windows Server 2003 family operating systems, allowing you to administer your server—even a Microsoft® Windows 2000 server—from virtually any computer on the network. Up to two remote sessions, plus the console session, can be accessed simultaneously. Terminal Server licensing is not required to use this feature.
The following is information on some additional features Terminal Services provides:
• You can configure new connections for Terminal Services, modify the settings of existing connections, and delete connections by using the Terminal Services Configuration tool (TSCC.msc) or Group Policy (gpedit.msc).
• By default, Terminal Services connections are encrypted at the highest level of security available (128-bit).
• You can monitor the actions of a client logged on to a terminal server by remotely controlling the user's session from another session. Remote control allows you to either observe or actively control another session. If you choose to actively control a session, you will be able to input keyboard and mouse actions to the session. A message can be displayed on the client session asking permission to view or take part in the session before the session is remotely controlled. You can use Terminal Services Group Policies or Terminal Services Configuration to configure remote control settings for a connection and Terminal Services Manager to initiate remote control on a client session Windows Server 2003 family operating systems also support Remote Assistance, which allows greater versatility for controlling another user's session. Remote Assistance also provides the ability to chat with the other user. Remote control can also be configured on a per-user basis using Group Policies or the Terminal Services Extension to Local Users and Groups and Active Directory Users and Computers.
• When you install one of the Windows Server 2003 family operating systems, the Remote Desktop Users group is one of the built-in user groups on your computer. By default, this group is not populated when you install Terminal Server on your computer. You must choose the users and groups that you want to have permission to log on remotely to the terminal server, and manually add them to the Remote Desktop Users group. This increases the security of remote connections, and also allows you to install any required programs before users start connecting to the terminal server.
As to installing the Terminal Server, we determined that we only needed to install for the remote administration. We did not need to install the entire Terminal Server program but just enable remote connection. The easiest way is to add a role to the server using manage your server wizard or using windows components wizard accessible via add or remove programs tool in the control panel.
The following are the steps we followed in order to set up Terminal Server remote connections:
To enable or disable remote connections
1. Open System in Control Panel.
2. On the Remote tab, select or clear the Allow users to connect remotely to your Computer.
The following are the steps we followed in order to set up Terminal Server remote Desktop Users Group:
To add users to the Remote Desktop Users group
1. Open Computer Management.
2. In the console tree, click the Local Users and Groups node.
3. In the details pane, double-click the Groups folder.
4. Double-click Remote Desktop Users, and then click Add....
5. On the Select Users dialog box, click Locations... to specify the search location.
6. Click Object Types... to specify the types of objects you want to search for.
7. Type the name you want to add in the Enter the object names to select (examples): box.
8. Click Check Names.
9 When the name is located, click OK.
The following are the steps we followed in order to connect to the console session of a server using the Remote Desktops MMC Snap-in:

1. Open Remote Desktops snap-in.

2. If you have not already done so, create the connection to the terminal server or computer to which you want to connect.

3. In the console tree, right-click the connection.

4. In the context menu, click Connect.

The following are the steps we followed in order to activate the Remote Desktop Connection:

1. Start->Programs->Accessories->Communications->Remote Desktop Connection.
2. Open Remote Desktop Connection.
3. In Computer, type a computer name or IP address. The computer can be a terminal server, or it can be a computer running Windows XP Professional or a Windows Server 2003 operating system that has Remote Desktop enabled and for which you have Remote Desktop permissions.
The following are things to be certain of in order to connect to the Remote Desktop for Administration:

1. Be sure you have the appropriate permission to use Remote Desktop for Administration. You must be an Administrator, or you must be a member of the Remote Desktop Users group.

2. Be sure Remote Desktop for Administration is enabled.

3. You must have the network computer name or IP address of the server.

4. You must not turn off the server.

Terminal Services permissions can be handled easily on a per-computer basis, using the Remote Desktop Users user group and the RemoteInteractiveLogon right. In some cases, however, it might be necessary to manage permissions on a per-connection basis.
The following are the steps we followed in order to remotely control a session:

1. Open Terminal Services Manager.
2. Right-click the session you want to monitor, and then click Remote Control. The Remote Control dialog box appears.
3. In Hot key, select the keys you want to use to end a remote control session, and then click OK. The default hot key is CTRL+* (using * from the numeric keypad only).
When you want to end remote control, press CTRL+* (or whatever hot key you have defined).
The following are things to be certain of when remotely controlling another session:

1. You must have Full Control permission to remotely control another session.
2. To configure remote control settings for a connection, use Terminal Services Configuration. Remote control can also be configured on a per-user basis by using the Terminal Services Extension to Local Users and Groups and Active Directory Users and Computers.
3. Before monitoring begins, the server warns the user that the session is about to be remotely controlled, unless this warning is disabled. Your session might appear to be frozen for a few seconds while it waits for a response from the user.
4. When you enter the remote control session, your current session shares every input and output with the session you are monitoring.
5. Your session must be capable of supporting the video resolution used at the session you are remotely controlling or the operation fails.
6. The console session can neither remotely control another session nor can it be remotely controlled by another session.
7. You can also use the shadow command to remotely control another session.
Each user who logs on to a Terminal Services session must have a user account either on the server or in a domain on the network that the server is on. The Terminal Services user account contains additional information about the user that determines when users log on, under what conditions, and how specific desktop settings are stored. Windows Server 2003 family operating systems contain a built-in User group called Remote Desktop Users, which is used to manage Terminal Services users.

2. DHCP Services and DHCP Relay Services (IP 10.207.32.3) (Tarik)

In this portion of the project, we were required to set up DHCP Services for Manamana.
Before proceeding with an explanation of the work done on this portion of the project, the following is a brief explanation of the term “Dynamic Host Configuration Protocol.” Dynamic Host Configuration Protocol (DHCP) is an IP standard to simplify host IP configuration management. It provides a way for DHCP servers to manage dynamic allocation of IP addresses and other related configuration details for DHCP-enabled clients on a network.
Every computer on a TCP/IP network must have a unique IP address. The IP address (together with its related subnet mask) identifies both the host computer and the subnet mask to which it is attached. When a computer is moved to a different subnet, the IP address must be changed. DHCP allows you to dynamically assign an IP address to a client from a DHCP server IP address database on a local network. In fact, DHCP reduces the complexity and amount of administrative work involved in reconfiguring computers.
There are many benefits to using DHCP. It requires less effort than manually configuring the assignment of IP addresses. Also, it makes updating a default gateway easier or DNS server’s IP address. Having to manually make changes would be labor intensive requiring to you visit every machine to be updated. DHCP also eliminates duplicate IP addresses, provided you correctly configure the DHCP scopes.
The DHCP server database should contain valid configuration parameters for all clients on the network, valid IP addresses maintained in a pool for assignment to clients (10.207.32.10 to 10.207.33.254 in our network), plus reserved addresses for manual assignment and duration of a lease offered by the server. The lease defines the length of time for which the assigned IP address can be used.
We chose to have two DHCP servers, one for Red Hat (10.207.33.2) and one for the Windows 2003 server (10.207.32.3). The following is a discussion of the work we did on the Windows 2003 DHCP server.
The first component of DHCP we looked at is the Relay Agent. The Relay Agent is a type of router. This is how it works. The Relay Agent intercepts DHCPDiscover packets from clients and then unicasts to the DHCP on their behalf. The secret of successful relaying is to create the appropriate scope on the DHCP server. The Relay Agent adds the source IP address when it contacts DHCP. This is how the server knows from its list of scopes which subnet to offer an IP address. You find the Relay Agent in Routing and Remote Access (RRAS). Because the Relay Agent is a type of router, the RRAS location to install and configure the DHCP Relay is appropriate. Once you find and install the Relay Agent, configuring it is easy. You need to instruct the router or DHCP Relay Agent the IP address of the real DHCP server. Right click the DHCP Relay Agent, and then select “properties” from the shortcut menu.
To determine how many routers lie between you client and its DHCP, with each router representing 1 hop, calculate the maximum hop count that you need and configure the Relay Agent accordingly. If you wish to check the Hop Count Threshold, from the RRAS interface, navigate to the IP Routing, DHCP Relay Agent, and right click on the Interface, not the server.
When using Relay Agents, especially if you configure more than one, there is a possibility of duplicate IP addresses. The conflict detection feature means that the DHCP server checks by pinging the proposed address lease before actually issuing it. Naturally, if the server receives a reply that IP address is not offered. Conflict Detection is a property of the DHCP server as a whole and not of individual scopes. To set the threshold, right click the server icon, properties, then Advanced (Tab).
If DHCP cannot assign an IP address, then clients can give themselves an Automatic Private IP Address (APIPA) in the range 169.254.x.y where x and y are two random numbers between 1 and 254. While APIPA is a sign of failure, the fact that the client has a valid IP address means that it can keep on polling to see if a DHCP server has come back online.
You can use Predefined options to set the WPAD (Web Proxy Auto Detect) for XP clients. You could set the ISA server Proxy with a group policy, but it may be easier to control via a DHCP option. From the DHCP server icon, select: Set Predefined Options. Select: Add. Next, in the Name box, enter WPAD. Change the Data Type box to: String. In the Code box, type: 252. Press enter. In the Predefined Option and Values dialog box, type http:// ISA-yourServer: 80 /wpad.dat. Note that 80 is the default port of the ISA AutoDiscovery service.
As to troubleshooting, IPCONFIG is a good troubleshooting tool. For example IPCONFIG /all, /release /renew. When you run IPCONFIG, if you see address beginning 169.254.x.y, this is known as APIPA which is discussed above.
Since Manamana’s DHCP server will be newly installed, we checked to ensure that it was Authorized in Active Directory by an Enterprise Admin. Since it was Authorized, we then checked to ensure that the scope was activated.
It goes without saying that the very DHCP server itself must have a fixed IP address. The DHCP server cannot be its own client.

We made sure that we added the interface to the Relay Agent. The Relay Agent is found under the Routing and RAS server icon. While we added the interface itself, by right clicking the Relay Agent object, we selected New Interface from the short cut menu.
In order to install the DHCP server and configure it correctly, we navigated to: Add Remove Programs, Windows Components, Networking Services. Then we were prompted to insert the Windows server CD.
While adding the DHCP service is easy, configuring the scope options requires thought. For instance, if you make a mistake with the subnet mask, you cannot amend that scope, you would have to delete and start again. However, you can add and change the options such as Type 006 DNS server, or Type 015 Domain name.
Here is a table summarizing how a DHCP service results in clients getting an IP address. Here are the classic 4 packets that clients exchange during a lease negotiation.
Client Server
DHCPDiscover --> <--- DHCPOffer
DHCPRequest --> <--- DHCPack

Reserving IP addresses is useful in two situations: for file and print servers and for important machines where leases are in short supply. DHCP knows which machine to lease a particular IP to by its MAC address (also called NIC or Physical address). In Windows 2003, when you enter the MAC address, DHCP strips out the hyphens if you include them amongst the HEX numbers. To find the MAC address, ping the machine then type arp -a.
In a Windows Server 2003 domain, all DHCP servers need to be authorized in Active Directory. We logged on (or type “RunAs”) as a member of the Enterprise Admins group, then right click the DHCP server icon, and Authorize. The RIS service also needs to be Authorized before it becomes active.
After we Authorized a server, each scope needed to be activated individually. So, we right clicked the scope to activate. We got a green arrow and knew we were successful.
To install the DHCP server, we did the following:
1. Open Windows Components Wizard.

2. Under Components, scroll to and click Networking Services.

3. Click Details.

4. Under Subcomponents of Networking Services, click Dynamic Host Configuration Protocol (DHCP), and then click OK.

5. Click Next. If prompted, type the full path to the Windows Server 2003 distribution files, and then click Next.
Required files are copied to your hard disk.
In order to open the Windows Components Wizard, we did the following:
1. Click Start.
2. Click Control Panel.
3. Double-click Add or Remove programs.
4. Click Add/Remove Windows Components.
DHCP servers must be configured with a static IP address
In order to open the DHCP console, we did the following:
1. Click Start.
2. Click Settings.
3. Click Control Panel.
4. Double-click Administrative Tools.
5. Double-click DHCP.
The DHCP console is an administrative tool for managing DHCP servers. For more information
In order to connect to a DHCP server, we did the following:
1. Open DHCP.
2. In the console tree, click DHCP.
3. On the Action menu, click Add Server.
4. In the Add Server dialog box, do one of the following:
a. Click This server, enter the name of the DHCP server that you want to connect to, and then click OK.
b. Click This authorized DHCP server, click the DHCP server that you want to connect to, and then click OK
To open DHCP, we did the following:
1. Click Start.
2. Click Settings.
3. Click Control Panel.
4. Double-click Administrative Tools.
5. Double-click DHCP.
If you are operating DHCP in an Active Directory environment and are connecting to a server for the first time, you need to first authorize the new DHCP server in the directory service.
If DHCP is installed and running on this computer, you do not need to make a manual connection using the wizard. In most cases, the local DHCP server automatically appears in the list of servers when the DHCP console starts, and you connect to the server by clicking it in the console tree.
Only users belonging to the following groups can connect to a DHCP server:
• DHCP Users
• DHCP Administrators
• Domain Admins
• Enterprise Admins
To start the DHCP server, we did the following:
1. Open DHCP.
2. In the console tree, click the applicable DHCP server.
3. On the Action menu, point to All Tasks and then click one of the following:
a. To start the service, click Start.
b. To stop the service, click Stop.
c. To interrupt the service, click Pause.
d. To stop and then automatically restart the service, click Restart.
After you pause or stop the server, the Resume option appears and can be clicked to immediately resume service.
You can also perform the tasks Start, Stop, Pause and Restart at a command prompt by using the following commands:
1. Net start dhcpserver
2. Net stop dhcpserver
3. Net pause dhcpserver
4. Net continue dhcpserver
You can also perform these tasks at the netsh> command prompt or in a script using the Netsh commands for DHCP.
In order to reconcile the DHCP database, we did the following:
4. Open DHCP.
5. In the console tree, click the applicable DHCP server.
6. On the Action menu, click Reconcile All Scopes.
7. In the Reconcile All Scopes dialog box, click Verify. (Inconsistencies found are reported in the status window.)
8. If the database is found to be consistent, click OK.
If the database is not consistent, click the displayed addresses that need to be reconciled, and click Reconcile to repair inconsistencies.
4. Router (IP 10.207.32.1 and 10.207.33.1) (Jeff Heiden)

Routers are devices that route packets of data destined for networks other that your local network. A packet is a network message that includes data and has a source and destination identified within it. A Router can be a very expensive dedicated appliance or it can be created from a multi-homed computer. The difference between the dedicated appliance and the multi-homed computer is that the dedicated appliance is more efficient at routing to different networks.

For the purpose of our test system, the Router is a multi-homed computer that has been configured as a Windows 2003 server with “Routing and Remote Access” installed on it. The Routing and Remote Access (RRAS) is used here to redirect the traffic from the Windows network to the Linux network and vise-versa.

ii. LINUX (Red Hat Server)

1. Secondary DNS and DHCP Services (IP 10.207.33.2) (Tarik, Mustapha, Jeff H. & Jeff S.)
Per the project requirements, the class was to implement a secondary DNS servers as a fail-safe and a DHCP server for the Linux network.
As explained in Section II.A.i.1. above, the Domain Name System (DNS) is a database that contains information about all computers in a TCP/IP network. Section II.A.i.1. addressed our setting up the Primary DNS, and this section will address setting up the secondary DNS.
As a side note, in order to complete work on the DNS, the class members were to go to their assigned server, open the network properties, and go to TCP/IP configuration. In the DNS part (which below IP address configuration), each was to include the following IP 10.207.33.2 as a secondary DNS. As a check when done, each class member was to attempt using nslookup in both directions :nslookup 10.207.33.2 and nslookup server4dns.

In order to create the secondary DNS which we named eccns.local, we needed to create forward and reverse zones.

Creating the Forward Zone
To create the forward zone, we did the following:
1. Click on create a new master zone
2. Zone type: Forward (forward name to address) select it
3. Domain name /Network: eccns.local. (domain here) (Note the (.) at the end of the domain name, it has to be there -is not a mistake.
4. Record file: Automatic
5. Master server: server4dns.eccns.local [/] Add NS record for Master Server?
6. Email address: root@localhost or root@eccns.local
7. Use zone template: no
8. Click on create
Once the zone was created, we proceeded to edit its properties. It took us to this panel automatically.
In order to edit the Forward Zone, we did the following:
1. Click on Address
2. Enter name: eccns.local.
3. Enter address: 10.207.33.2 (note: this is the physical address domain 1)
4. Time-To Leave: default
5. Update reverse?: yes
6. Click on create

Figure 7 – Screen Shot of Address record
7. Return to record types
In order to add Name Server Records, we did the following:
1. Enter zone name: eccns.local.
2. Time-To-Leave : Default
3. Enter Name server: dns2.eccns.local. (host.domain.com)
4. Click on create

Figure 8 – Screen Shot of Name Server Records
5. Return to record type.
In order to add a Name Alias Record, we did the following:
1. Name: www
2. Time-To-Leave: Default
3. Real Name: eccns.local.
4. Click on create
5. Name: mail
6. Time-To Leave: Default
7. Real Name: eccns.local.
8. Click on create
9. Name: ftp
10. Time-To-Leave: Default
11. Real Name: eccns.local.
12. Click on create

Figure 9 – Screen Shot of Name Alias
13. Return to Record Type
To create a Mail Exchange Record (MX record), we did the following:
1. Name: eccns.local.
2. Time-To-Leave: Default
3. Mail Server: eccns.local.
4. Priority: 10
5. Click on create
6. Return to Record Types

Figure 10 – Screen Shot of Mail Record
We just finished creating the forward zone. At the very bottom of this current panel (Edit Master Zone), click on Return to zone list. From the zone list we clicked on Apply Changes.
The next step was to create the Reverse Zone for :eccns.local
Creating the Reverse Zone
To create the Reverse Zone, we followed these steps:
1. Click on Create New Master Zone
2. Now the Zone type will be: Reverse
3. Domain name/network: 10.207.33. (The last number is left out which is 2)
4. Records file: Automatic
5. Master server: server4dns.eccns.local [/] Add NS record for Master Server?
6. Email address: root@localhost or root@eccns.local
7. Use template: no
8. Refresh time: leave as default
9. Expiry time: leave as default
10. IP address for template: leave blank
11. Transfer retry time: leave as default
12. Default time to leave: leave as default
13. Click on create
Next we edited the Master Zone properties for the Reverse Zone that we just created.
Next, we created a pointer as follows:
1. Click on PT
2. Now add Reverse Address Record
3. Address: 10.207.33.2 (type complete IP address here)
4. Host name: eccns.local.
5. Update forward: yes
6. Click on Create
7. Return to Record Types
We next added a name Server (NS) as follows:
1. Zone Name: 33.207.10
2. Name Server: server4dns.eccns.local.
3. Time to leave: Default
4. Click create
5. Return to Record Types
In order to add a Name Alias Record (CN), we did the following:
1. Name: www
2. Time-To-Leave: Default
3. Real Name: eccns.local.
4. Click on create
5. Name: mail
6. Time-to-Leave: Default
7. Real Name: eccns.local.
8. Click on create
9. Name: ftp
10. Time-to-Leave: Default
11. Real Name: eccns.local.
12. Click on create
13. Return to zone list
14. Click on Apply Changes
We just completed a totally functional secondary DNS. We can now verify the changes in the main configuration file /etc/named.conf. Note that a new zone has been added to the file.
Figure 11 below is a screen shot of the secondary DNS created by BIND:

Figure 11 - screen shot of the secondary DNS created by BIND

Figure 12 - screen shot of the Record Files in the secondary DNS
Next, to activate all changes, restart the service by entering the following:
[root@server4dns root]# service named restart
In the alternative, you may reboot the system.
Since we created a working master DNS, Manamana can now use our system for almost anything. In the same manner we created this master DNS, you can also create a slave DNS server at a different IP address. By creating a slave DNS, the two DNS computers can replicate the data of each other (Fault Tolerance) so that if one of the servers is down, the other one will respond to the queries.

2. SAMBA, NFS, and CUPS Services (IP 10.207.33.3) (Steve, Adam, Jeff H. & Jeff S.)

Per the project requirements, all users must have access to file and print resources.
Configuration began by installing the RedHat Linux operating system on the print server. Difficulties were immediately encountered during installation of the operating system and the computer crashed twice. It was determined that the reason it was consistently crashing was because the drivers were not on the same CD as the operating system. One solution was to download drivers from the Internet and install them before installing the operating system. The route chosen was to install a more recent version of Linux, Fedora 3. During the installation of the OS, the packages for Samba, NFS, and CUPS were all installed along with the KDE and GNOME windowing systems for easier administration of the system.
Unlike on a Windows server, configuration of services rarely involves a graphical interface. This means that the KDE and GNOME windowing systems were not necessary to the installation, but they do offer some utilities that can aid in configuration. Although these graphical configuration utilities can streamline the process of configuration, the terminal and vi quickly become a Linux administrators best friend. The graphical interfaces simply change the text based configuration files. Instead of being limited by the GUI’s interface, it is very simple to configure everything through the terminal. Whenever changing any configuration files for services, that service must be stopped and restarted. In Red Hat, the command for that is service [name of service] restart. Since configuration is happening through the terminal, it is very quick to write changes to vi, restart the service, and test it out. On future File/Print servers a graphical environment will probably not be installed as it is not necessary.
Since the OS is now installed, it is time to configure CUPS, the print server. All initial configuration of this service took place using the graphical utilities. The printer that was chosen already had an internal network card. Through the Printers section it was added as a local printer. Once it was added, the web interface for CUPS was accessed and this printer was added to the CUPS service as an available printer. The web interface is convenient since it allows for remote access to the status of the print server. It displays the current queue and allows for canceling or resubmitting of jobs. The port to access this interface is 631, so through the network, both to add the printer and to access this interface that port was used. The format for accessing any available printer is as follows: fileprint.eccns.local:631/printers/[name of printer]. After some permission issues, the local network IP range was added and the printer worked just fine.
Next came the Samba configuration. This configuration of this service was handled solely through the command line and the file /etc/samba/smb.conf. First, a directory was created in the root called Share. It was then added to smb.conf as a common share directory that all users have full access to. Giving full access through this file, however, does not give complete access to the actual directory, just to the share. Change Mode must then be used to also give access to the directory. Once permission has been granted, since this server has been added to the domain, all users in Active Directory can access this share using the server’s name, FILEPRINT. In Windows, the mapping is created using the following syntax: \\FILEPRINT\Share. In Linux it is handled using the following syntax: smb://fileprint/Share.
Next came the NFS configuration.
NFS: Network File System

NFS, Network File System, was developed by Sun Microsystems in the 1980s. It provides a mechanism by which UNIX systems can share their disk resources. What makes NFS really useful is that it can function across multiple UNIX/Linux machines, enabling a centrally managed directory structure to be accessed by many clients by exporting access from the server and mounting it on the client. In this way, duplication is avoided and disk resources are centralized.

NFS Architecture

There are three programs that provide NFS services. They are:

rpc.portmapper - This maps calls made from other machines to the correct NFS daemons. It is meant for the client machine.

rpc.nfsd – This daemon translates the NFS requests into a format understood by the
local filesystems.

rpc.mountd – This daemon services requests to mount or unmount filesytems.

The NFS services are included in the Red Hat Linux distribution and can be chosen at installation time.

Configuring both NFS Servers and Clients

The two key files that are used for NFS services are /etc/exports at the server and /etc/fstab at the client. The /etc/exports file contains information as to which directories are to be shared with which clients and the extent of that client’s access rights. The /etc/fstab file on the client machine specifies a mapping between the local client directories and the servers and directories on those servers that map to each one. Note that there can be a mix; a client may have some sub directories come from one server and some from another, creating a sort of virtual directory structure.

The /etc/exports file follows this format:

directory-to-export client-ips permissions

So each host is given a set of access permissions. The most significant ones are as follows:

rw – Read and Write Access
ro -- Read Only Access
synch – Tells the server to commit file writes to disk immediately.

In order to allow the Linux client machines to gain access to the /export/nfsshare test directory, we had to enter the following:

/export/nfsshare 10.207.33.* (ro)

Note the use of the wildcard. This is important since the exact IP of the client depends on the value that the DHCP server will grant, and that cannot be known in advance. The only thing to do is to specify the known range of IPs from which the DHCP must choose.

Once changes in the /etc/exports file are made, you can have them picked up by the following command:

exportfs –r

This sends certain signals to the rpc.nfsd daemaon to reread the file.

At the client computer, we have two choices:

1) Each time we wish access to the exported files, we can mount the server’s directory to an (already existing) local directory: E..g

mount –t nfs fileprint:/export/nfsshare /nfstest

2) Most likely we would want that access to be established at boot time. To do that, the /etc/fstab file must be modified. The format of the /etc/fsab file is as follows:

Server:Directory-To-Export Mount-Point FileSystemType Options 0 0

as in:

fileprint:/export/nfsshare /nfstest nfs defaults 0 0

By the time you have logged in, the mount as been done.

Starting and Stopping NFS

To start the service at the server, the following command is entered:

service nfs start

This starts both the NFS daemons and runs the exportfs command.

To configure the machine so that NFS is started at the server’s boot, a determination must be made as to which run levels should be associated with this service. Normally those are levels 3 and 5, so we ran:

chkconfig --level 35 nfs on

On the client side, the “portmapper” process is required. Normally this is included and activated in the standard workstation Linux distribution, but it can be verified with the following command at the client computer:

rpcinfo –p

This will list all RPC programs running on the system.

3. APACHE and FTP Services (IP 10.207.33.5) ( Steve E.)
As required of all servers, initial configuration began with installation of the server OS. Having just worked out difficulties encountered in installing the email server (see section ii.4. below), the installation of the operating system went more smoothly.
Once the operating system was successfully installed, our next task was to setup the files for the web server. As with the email server (see section ii.4. below), what we found and ultimately recommend for Manamana is a software application that we located on the Internet at http://www.webmin.com/ called Webmin.

Apache Web Server

We will try to give an overview here of the issues involved in the installation, configuration and administration of the Apache Web Server.
Server Installation
There are two options for installing the Apache Web Server: either to install the RPM package that comes with the Linux installation media, or to top for compiling the source code yourself. We chose the former.
Apache RPM takes about 6 MB and installs files in the following directories:
/etc/httpd/conf -- This directory contains all the Apache configuration files, such as httpd.conf, access.conf and srm.conf.

/etc/rc.d - The tree under this directory contains startup/stop scripts. These are used to start and stop the server from the command line as well as when the computer is halted started or rebooted.

/var/www – The RPM installs default server ICONS, CGI programs and HTML files in this directory.

/var/log/http -- This is the default log directory. There are, by default, two log files, access_log and error_log which reside in this directory.

Runtime Server Configuration Settings.

Starting with Apace 1.3.4, all runtime configuration settings are stored in one file:
/etc/httpd/conf/httpd.conf
The general idea in this file is that one specifies configuration directives, which are commands to set a particular option, in the form of:
directive option option
Some directives are simple and set a single value such as a filename, but others are more complex and must be specified in sections. These larger, section directives, look like HTML tags and are enclosed in angle brackets. Within the scope of the starting and tags, individual options can be specified that apply only to that directive. The former category includes things like the server type, port number name of the server and an error logfile name. The later category includes such items as Virtual Hosting and restricting access to certain directories and resources.
The following is a listing of some of the more commonly used directives that are available:

ServerType - Can be either “standalone” or “inetd”. “inetd” will cause a new process to be spawned for every new HTTP request. Usually we want standalone.

ServerRoot - This is the absolute path to the server’s main directory, where the configuration and logfiles are kept. It defaults to /etc/httpd.

Port - Indicates which port the server should run on. This defaults to 80. If another value is used it needs to specified in the URL when attempting to bring up the page.

User and Group - These directives should be set to the user id and group id that the server will assume to process the requests. There are generally two ways to configure this option, either as “nobody” or as that of a specific user. Usually we chose “nobody” because of security considerations.

ServerAdmin – This directive is set to the email address of the webmaster administering the server. This setting is always a good idea in case there are problems.

ServerName - This directive sets the hostname the server will return. It should be set to a fully qualified name that has a DNS entry.

DocumentRoot - This sets the absolute path of the document tree from which the server will serve its files. The default is /var/www/html.

KeepAlive - Usually set to ON. This allows for persistent connection between client and server.

Authentication and Access Control
There could be times when there is material on the web site that is not supposed to be made available to the general public. One needs to be able to lock out these areas from everyone but a selected group of users. There are two basic approaches to doing this, either by checking the client’s IP or by asking for a user name and password.
The IP based approach can be implemented using the “allow” and “deny” directives for that purpose. These directives can use the word “all,” a fully qualified domain name, a full or partial IP or a network/subnet mask. Thus, one might have:
allow from x.y.com
allow from 212.85.67
deny from 212.85.67.9/255.255.255.0
The default behavior of Apache is to apply all the deny directives first and only then check the allow directives. This could be changed with an “order” statement. So, if one specified “Order deny, allow” the result would be that if a host does not meet the deny criteria it will be allowed. The other possibility is to specify “Order allow, deny” which means that the allow directives will be evaluated first. The effect would be that if a host is not specifically allowed, it would be denied access to the resource.
There are several methods of doing authentication in Apache. We will discuss only the most common: basic authentication. With this method, a user is required to submit a user name and password to be verified. In order to set up a file to check these user names/passwords against, the htpasswd command can be run with –c option. For example, on the command line one could enter:
httpasswd –c allowedpeople alig
to create the file “allowedpeople” with the user alig listed. You would then be prompted for this password. To tell Apache about this file, you would use the AuthUserFile directive. By associating different authentication files with different tags, one can get appropriate permissions for different groups of users.
For our project, we had no specific web requirements. No Virtual Hosting or dynamic content was needed, nor was there any need to restrict access. We therefore took the default settings, installed and started the service and confirmed that a test page was readable to all.
To configure the service, one can modify the httpd.conf file manually or one can use one of the Linux GUI’s. The GUI method is as follows:
System Settings -> Server Settings ->HTTP
Enter the options for ServerName, webmaster’s email address and Available Addresses (“all available addresses on port 80”)
To start the service, manually enter:
/etc/rc.d/init.d/httpd start
or use the GUI as:
System Settings -> Server Settings -> Services,
check the httpd box in the left column and then hit START.
After this, we could point the browsers to web.eccns.local and access the test web page. To be sure that the service starts from now on at boot time, we entered:
chkconfig –level 35 httpd on
FTP Services

We installed and configured Linux’s Very Secure FTP Daemon (vsftpd) to provide file transfer service. vsftpd was included in the Fedora distribution, and we chose that package as part of the (server6) installation.

There were several configuration decisions that had to be made. Configurations settings for the vsftpd service are stored in the /etc/vsftpd/vsftpd.conf file. The file contains a default group of settings that may be tweaked. However, the items in that file are not exhaustive as the complete set is found in the vsftd.conf manual page in section 5. The settings found there are the most common and useful. They include:

1) This setting enables the Administrator to make the FTP service anonymous or standard. Standard ftp requires logins and passwords on the server in order to obtain or install files. Anonymous ftp does not and accepts a universal “anonymous” login with a provided email address as a password. For Manamana’s application, we wanted a little more security and thus chose the standard option. We thus set:

anonymous_enable = NO

2) Similarly, we want local users to be able to log in. To make that happen, we set:

local_enable = YES

3) We want them to be able to upload files, such as html documents so we set:

write_enable = YES

4) Since it is good to keep logs of this activity though, we set:

xferlog_enable = YES

5) The default file for that is set by:

xferlog_file = /var/log/vsftpd.log

There are also settings for

- Limiting the maximum amount of simultaneous client connections (max_clients)

- The maximum rate of data transfer for both anonymous and standard logins
( anon_max_rate, local_max_rate)

- Limiting the amount of client connections from a single IP address. (max_per_ip)

- A greeting banner message (ftpd_banner)

Once the configuration options were setup as appropriate, we started the service.
We did so with:

service vsftpd start

To configure vsftpd to routinely start on booting the computer, we used

chkconfig vsftpd on

Since we are using standard ftp, the Administrator will need to create logins and passwords. Each ftp user will then be placed in an ftp documents (doc) directory. The root directory does this as follows:

1) Create a group for ftp users:

groupadd ftp-users

2) Setup a directory for the ftp documents:

mkdir /home/ftp-docs

3) Make that directory accessible to the ftp-users group:

chmod 750 /home/ftp-docs
chown root:ftp-users /home/ftp-docs

4) Add the users of that group, with their default directory set to /home/ftp-docs:

useradd –g ftp-users –d /home/ftp-docs sehrlich
useradd –g ftp-users –d /home/ftp-docs jheiden
. . .

5) Assign each of them the standard password:

passwd sehrlich ECcns2005
passwd jheiden ECcns2005

6) Copy files into the /home/ftp-docs directory for distribution:

7) Change the permissions in the file for read only access by the group:

chmod 740 /home/ftp-docs/*

On the client side, ftp client software comes included with standard Linux, and there is no special configuration to be done. We successfully tested the service from both the Linux and Windows client, performing both downloads and uploads of files.

4. SMTP, POP3, and DNS Relay Services (IP 10.207.33.4) (Adam)
Per the project requirements, all Manamana clients are to have access to email, both sending (SMTP) and receiving (POP3), as well as having aliases and virtual accounts configured for users and groups.
We began by installing the Linux/RedHat operating system on a PC that will be used as the email server for Manamana. We tried to install the Red Hat Linux 8.0 Publisher’s Edition found at the end of the textbook “Hello Linux!” We immediately encountered difficulties when he attempted to install it in that the computer crashed. This happened several times in a row. We determined that the reason it was consistently crashing was because the drivers were not on the same CD as the operating system. One solution suggested to us was to download drivers from the Internet and install them before installing the operating system. We wondered if we could save time by getting all the drivers at once from the newest distribution of Linux/Fedora/Red Hat, Version 3.0. We located that version on the Internet, installed it, and were able to continue with his portion of the project.
During the Linux installation process, we were prompted to select that it was an email server to be installed, and within that installation we chose SMTP for sending and POP3 for receiving emails according to the project requirements.
Simple Mail Transfer Protocol (SMTP)
Simple Mail Transfer Protocol (SMTP) is capable of sending e-mails both within a local computer network and outside of that local network. In doing so, SMTP performs a number of tasks including that it:
• Checks to see if the mail recipient is local;
• Searches local, root, and Elmhurst DNS servers based on MX records (Mail Exchange);
• Connects to the appropriate server; and,
• Hands off email to POP3.
• If mail not deliverable after 5 days, message considered “undeliverable.”
The following are some of the commands to be used in order to send an email using SMTP. To send e-mail at the command prompt, the user types the commands as they are show at the bullets below:
• TELNET server-name 25 (SMTP communicates on port 25)
• HELO your-domain (This is where we identify the source of the email)
• MAIL FROM: your-email-address
• RCPT TO: recipient-email-address
• DATA
• Text of e-mail goes here
• . (End of DATA section is punctuated with a single dot on its own line.)
• QUIT
Note that SMTP returns code to let the e-mail client know whether or not the command was successful.
As an example, the above command entered at the computer with the IP address 10.207.33.5 25 would appear as follows:
TELNET 10.207.33.5 25
HELO mx.elmhurst.edu
MAIL FROM: mustapha@eccns.local
RCPT TO: adam@eccns.local
DATA
This is a test message
.
Post Office Protocol ver. 3 (POP3)
Post Office Protocol ver. 3 (POP3) is capable of receiving e-mails both within a local computer network and from outside of that local network. In doing so, POP3 performs a number of tasks including that it:
• Has a text file for each account;
• Lists email accounts;
• Messages are formatted;
• Sends a copy of the mailbox
• Separates the file into separate messages; and,
• Resets and erases the mailbox.
The following are some of the commands that must be entered in order to receive an email via POP3.
• TELNET pop.eccns.local 110 (110 is the receiving port, and 25 is the sending port)
• USER adam
• PASS ECcns2005
• RETR
• QUIT
• LIST (lists the messages)
• DELE (deletes a message)
Webmin & Sendmail
We also had to configure the files for the email. One way of doing so was to utilize Sendmail. We soon learned that Sendmail has one of the nastiest configuration files in the Linux (or even Windows) world. We found that there is a special M4 scripting language to help make modifications easier, but even that was hard to work with. What we found and ultimately recommend for Manamana is a software application that we located on the Internet at http://www.webmin.com/ called Webmin. See Figure 7 which is a screen shot of Webmin.
Webmin is a web-based interface for system administration of Unix. Webmin can use any browser that supports tables and forms and Java for the File Manager module. Webmin consists of a simple web server, and a number of CGI programs which directly update system files like “/etc/inetd.conf” and “/etc/passwd”. The web server and all CGI programs are written in Perl version 5 which are both text-based programs, and use no non-standard Perl modules. Webmin provides a Web interface into the Linux box, thus providing a “semi” Graphical User Interface (GUI) for management. One of the Webmin modules is the Sendmail module. By updating one field on the form, Manamana can have Sendmail up and running.

Figure 7
The Webmin program automatically installed the following files for us:
• Distributions
– sendmail-..rpm
– sendmail-cf-..rpm
– sendmail-config-..rpm
– sendmail-doc-..rpm
• Procedure
– rpm –e package_name
– rpm –ivh package_name
Sendmail is set up to run this file when the computer is booted
/etc/rc.d/init.d/sendmail
/etc/rc.d/rc3.d/S85sendmail
The following file is set up to run when Sendmail starts:
/usr/bin/sendmail –q15m
The following file is set up to configure for Sendmail:
/etc/sendmail.cf
The following are the paths to the files which you can use to alter files within the Sendmail module to make the email program do exactly what you want it to do such as restrict access, create aliases, relay mails, etc. Of course, there will be “default” settings in each of these files already, but you can go into these files and change the text to override those default settings.
• Restrict access: /etc/mail/access
• Create aliases: /etc/mail/aliases
• Relay mail: /etc/mail/relay-domains
• Domains: /etc/mail/sendmail.cw
• Virtual users: /etc/mail/virturaltable
• Logging:
• mail.* /var/log/mail.log
• Secures file system with:
• chmod –R 600 /etc/mail/*
• Privacy Flags:
• 0 PrivacyOptions=needmailhelo,needexpnhelo,
noexpn, novrfy,restrictmailq,restrictqrun
In addition, the following are tools available in Sendmail that can be used to obtain information on the emails:
• mailq – prints a summary of mail messages queued for delivery. The mail is queued in directory: /var/spool/mqueue/
• mailstats – displays current mail statistics. Statistics are stored in file: /var/log/sendmail.st/
• purgestatmailstats: purges the mail statistics
• praliases: displays current mail aliases
Up to this point, we were looking at ways in which Manamana could access their email at the command prompt. In the alternative, we looked at Manamana’s setting up Evolution, a GUI that can be used to send, receive, and organize email. Figure 8 is a screen shot of the Evolution INBOX.
Figure 8
Now clients at Manamana can access their email either at the command prompt or they can set up Evolution at their terminal if they wish to have a GUI.

III. Conclusion

For its CS 545 Group Project, the Class of Fall 2005 successfully developed a computer network for Manamana, a small hypothetical company. The scenario and project requirements detailed that Manamana wanted to have a mix of Windows Server 2003 and LINUX servers. It already had several computers already running Windows XP, a number of hubs and a few class A IPs. It utilized two laser printers connected to each of its networks, and wanted the class to set up a LAN/WAN such that its current resources could be more efficiently utilized.

The class set up a single computer network incorporating Windows Server and LINUX operating systems. They designed the network to consist of seven servers with a router (IP 10.207.32.1 and 10.207.33.1) between the Windows and LINUX sides. They set up a client computer and printer on the LINUX side, as well as a client computer and printer on the Windows side. The class reviewed the functionality requirements for the network, and determined which server to use to resolve each requirement. On the Windows side, the class used the first server (IP 10.207.32.4) to implement Active Directory, Primary DNS and WINS services. It used the second server (IP 10.207.32.2) to implement Terminal Server, and the third server (IP 10.207.32.3) for DHCP services. On the LINUX side, they used the first server (IP 10.207.33.2) to establish the Secondary DNS and DHCP Services, and the second server (IP 10.207.33.3) to set up SAMBA, NFS and CUPS Services for printers. They used the third server (IP 10.207.33.4) for SMTP and POP3 for email services. Finally, they used the fourth server (IP 10.207.33.5) for APACHE web and FTP web services.

The network design developed by the class provides maximum computer efficiency using the resources that Manamana had available. Most importantly, it meets the current needs proposed by Manamana for a dual operating system network which can grow as Manamana’s business grows.

IV. References

Ball, Bill and Duff, Hoyt. Red Hat Linux 9 Unleashed. Sam’s Publishing, 2003.

Brandon, Cameron, MCSE TCP/IP for Dummies. IDG Books Worldwide, Inc., 1998.

The Computer Technology Documentation Project. Downtownhost.com Web Hosting Services. 26 Nov. 2005 .

Configuring Roaming User Profiles. Microsoft Corporation, 2005

Hall, Jon “Maddog,” and Sery, Paul G. Red Hat Fedora Linux 3 for Dummies. Wiley Publishing, Inc., 2005.

“How to Configure a Default Gateway for Multihomed Computer with LAN and Internet Access.” 20 December 20 2004 .

Minasi, Mark, Internet Connection Sharing. October 1999. .

Minasi, Mark, Mastering Windows 2000 Server, Second Edition. Microsoft Corporation, 2000.

“Roaming Profiles.” May 2002. .

“Router (definition).” Internet.com / Webopedia. Jupiter Media Corporation. 4 December 2005 .

“Squid with NTLM Authentication from How To Guides.” Townsville Linux Users Group. 4 December 2005. .

“Technical Overview of Terminal Services.” Microsoft Windows Server 2003. Microsoft Corporation
Thomas, Guy. “DHCP in Windows Servers 2003.” Computer Performance. 2 December 2005. .
Webmin.com. 18 Oct. 2005. Open Country/Sourceforg.net. 26 Nov. 2005. .
WindowsNetworking.com. TechGenix Ltd. 26 Nov. 2005 .

Zacker, Craig, 70-290 Managing and Maintaining a Microsoft® Windows Server™ 2003 Environment Textbook. Redmond, Washington: Microsoft Press, 2004.

my picture

2005-04-04T14:11:00.000-07:00

http://pg.photos.yahoo.com/ph/graceandglory13@sbcglobal.net/detail?.dir=b727&.dnm=6c96.jpg&.src=ph

photo

2005-04-04T14:06:00.000-07:00

http://pg.photos.yahoo.com/ph/graceandglory13@sbcglobal.net/detail?.dir=b727&.dnm=6c96.jpg&.src=ph