The CSC creates user accounts only upon receiving authorization and user data from the respective sections through ACSS in electronic form. Such authorizations and data are created by E-I for faculty, E-II for staff, IRD section for IRD staff, UG and PG sections for students and by faculty members for visitors. Once the data is created the ACSS transfers the data electronically to CSC where the pending accounts are created several times a day during working hours with the click of a button. For visitors, we also require the signed forms to reach us before creating the accounts.
If you are a new faculty member or a visiting faculty member who has just joined the institute, we will be happy to bypass the above process and create an account immediately. We request you to download this form, fill it up and obtain an authorization from your HOD/HOC. Please send the filled form over to us, or drop by for a cup of tea and we will create your account immediately. We will update your account information when a more formal authorization becomes available from the E-I section.
It will not be possible for us to follow the above procedure for others, and we will require a formal authorization. We are sorry about this. You can find out from the CSC reception counter (Phone: 1771) during working hours whether your data and authorization have reached the CSC. If not, we will pass on your request to the respective sections. In the interim you can request a faculty member of the Institute to create a temporary guest account for you through an interactive form available at https://www.cc.iitd.ernet.in/usermanage/guest-account.html
For new students at the beginning of an academic year the passwords are usually distributed at the time of registration.
All other users are requested to collect the passwords in person from the CSC reception counter during working hours. Users are requested to carry their identity cards.
Through the interactive web-page at https://userm.iitd.ernet.in/usermanage/pwchange.html
No, it is against the CSC policy to send passwords over email. You will have to visit the CSC reception counter during working hours with your identity card. An explanation may be sought if it is felt that the request is frivolous and you may be requested to obtain an authorization from your course advisor/supervisor. The CSC has over 10000 users and frequent such requests put the CSC staff under undue pressure. We request all users to cooperate and be careful with their passwords.
It is nearly impossible for your account to be hacked unless you have been careless. We use the highest industry grade encryption standards for all facilities where you are required to provide your password - the same that is used by most commercial banks. The only ways in which your account can be hacked are i) you have not installed the IITD CA-certificate as instructed on our web-page at http://www.cc.iitd.ernet.in and have accepted a false certificate presented by an attacker ii) have set an easy to guess password, or iii) have keyed in your password in an untrustworthy machine.
If indeed your password has been stolen then the third method above is most likely. Any machine which has been configured as a single user machine and is being used as a public multi-user machine, perhaps through a common account, is not safe. If you enter your password in the browser of such a machine it can possibly be read off by the next user, even if you have not permanently stored your password in the browser. Also, it is fairly easy to install a malicious program like a key logger on such machines, and such instances are fairly common in IITD. If in doubt, please don't use such a machine and use the CSC lab machines instead - these are safe. Even if you use such a machine, make sure that you have deleted your password from the browser's memory and have closed the browser properly after you are done. Also, please request the person in-charge of the facility to configure the machines as proper multiuser machines as per the guideline of the OS vendor. As a general precaution you should also change your password frequently.
We can almost surely trace any person who may have used your account, but we may not always be motivated. There are 10000 users in IITD and we don't have the bandwidth to investigate every case. As far as we are concerned keeping the password safe is a user's responsibility. We will investigate only when there are strong reasons for us to do so or when we are instructed by the IITD administration.
Please see above. No, it will not be reset unless you can give a satisfactory explanation.
Setting your machine to use Dynamic Host Configuration Protocol (DHCP) should be sufficient in the wired LAN to automatically obtain an IP address and other network parameters.
Alternatively, you can obtain a fixed IP address and other necessary network setting parameters (netmask, gateway address and name server details) from your local network administrator of your department or centre and configure the network settings manually.
Please see our web-page for the procedure for getting connected to the wireless LAN.
Getting on to the IITD network does not automatically enable you to access the Internet. For that, you need to configure your browser to use one of the IITD proxy servers. Accessing IITD email does not require proxy. Please see our web-page at http://www.cc.iitd.ernet.in for details.
You have to determine which part of the network you are unable to access.
If you determine that your port is faulty, then you should register a complain at https://internal.iitd.ernet.in/slats/ (or by phone call to 7126) and we will forward your complain to the Estate and Works section. Please identify the exact location of the port, its number and self while lodging the complain. Please note that CSC does not maintain the passive network infrastructure likes ports and network cables, the Estate section is responsible for those.
If you are able to ping your gateway then you should check whether you can reach the CSC servers. You can try to ping one of the proxy servers by ping 10.10.78.81. If this fails but you can ping your gateway you should let us know immediately. You can register your complain at https://internal.iitd.ernet.in/slats (or call 7126). When you do so we will appreciate if you can make the information as complete as possible and include the ping results, the port and room number, your IP and MAC addresses and the time of the day when you tried. We will try to get back to you within a few working hours. Please note that it may not be possible for us to attend to these complains outside working hours as we don't have an engineer available to us for 24x7.
Please follow the procedure outlined above to determine that indeed it is the network port that is faulty. If the port is not a backbone port and has been wired by your department or centre, please contact your laboratory in-charge. If the faulty port is a backbone port then please register a complain at https://internal.iitd.ernet.in/slats/ and we will forward it to the Estate section. This may involve changing the port or changing the backbone cable.
Please note that the CSC does not and cannot attend to physical damage to ports and cables. We do not have physical access to the backbone switches in your locations, we only program them remotely. Please follow up the problem with the Estate and Works section.
The ADSL connections to faculty homes are maintained by the telephone department which is under the Estate and Work section. Please register your complain at https://internal.iitd.ernet.in/slats/ and we will forward it to them (you can also call 7126).
Reliable ADSL connectivity crucially depends on quality of cabling. For ADSL to work at all the noise margin should be > 10 db and the attenuation should be within 0 - 40 db. However, to get the full speed of 6144 Kbps downstream and 640 Kbps upstream the noise margin should be > 20 db and the attenuation < 30 db. Please ensure that the ADSL maintenance team can demonstrate these levels at your location for ADSL to work reliably.
The quotas are fixed according to the groups/category and we would not like to make individual exceptions which are hard to keep track of or manage. A committee consisting the Dean (PG), Dean (UG), Dean (Students) and Head (CSC) is responsible for fixing the quota and you can make an appeal to increase the group quota at a suitable forum.
The current group/category quotas are as follows:
Category | Proxy Quota |
Faculty | Unlimited |
PhD | Unlimited |
MTech/ MBA/ MDes/ PGDip/ DIIT/ Dual/ Integrated 2nd year | 4GB/week 16GB/month 200GB/year |
MTech/ MBA/ MDes/ PGDip/ DIIT/ Dual/ Integrated 1st year | 4GB/week 16GB/month 200GB/year |
MSR | 4GB/week 16GB/month 200GB/year |
MSc | 2GB/week 8GB/month 100GB/year |
BTech 4th year | 2GB/week 8GB/month 100GB/year |
BTech 3rd year | 2GB/week 8GB/month 100GB/year |
BTech 2nd year | 2GB/week 8GB/month 100GB/year |
BTech 1st year | 2GB/week 8GB/month 100GB/year |
Staff | 2GB/week 8GB/month 100GB/year |
IRD Staff | 2GB/week 8GB/month 100GB/year |
HOD/ HOC | No Access |
Administrative Heads | No Access |
Adjunct Faculty | Unlimited |
Emeritus Faculty | Unlimited |
Retired Faculty | 2GB/week 8 GB/month 100GB/year |
Ex Faculty/ Ex Students | 2GB/week 8 GB/month 100GB/year |
Notes:
For Quota Assignments: 1GB=1000MB=1000000KB=1000000000B (4GB is equivalent to 3.90625GB)
For Quota Reporting: 1GB=1024MB=1048576KB=1073741824B
(e.g. 4GB quota assigned is equivalent to proxy quota use up to 3.90625GB)
1 Week = Last 7 days, 1 Month = Last 30 days, 1 Year = Last 365 days
The CSC has a special proxy server reserved for urgent research needs and you can make an application (through your supervisor) to get access on this. In such a case we may present the record of your past usage to your supervisor and request him/her to certify that usage was primarily academic in nature before granting you access to the special proxy server.
In the automatic proxy configuration URLs (http://www.cc.iitd.ernet.in/cgi-bin/proxy.*), we have explicitly programmed that accesses *.iitd.ac.in, *.iitd.ernet.in and 10.*.*.* are not routed through the proxy. All internal sites within IITD can be accessed without the proxy server. Your proxy quota may be getting consumed for internal downloads because you have explicitly set the proxy for internal download, which is not required.
Upon successful authentication the proxy server programs your browser to send a ``I am alive'' heartbeat message to the server once every three minutes. The proxy server terminates the session if two successive messages are missed.
The proxy servers have been tested for continuous connectivity from standard web browsers for weeks together. Almost certainly it is a local problem at your end. The most common reasons are:
If even after all the basic checks the problem persists then there is some problem in your connectivity to the switch and you are dropping packets. You'll need to get this checked up. Please contact 7185 or send an email to sysadm@cc.iitd.ernet.in. We will get back to you within a few working hours.
You will need to set proxy{xx}.iitd.ernet.in:3128 as your proxy server inyour non-browser application. Your can find proxy{xx} from the successful login page when you connect to the proxy server.
Of course, you will need to be logged on to the proxy server through a browser for the non-browser applications to work.
If this is happening frequently (several times a day) then it would almost certainly be a local problem - please see the answers to the FAQ on The proxy server logs me out frequently. What may be the problem?
Otherwise, the mail server may be down because of a power outage - you can check this by ping mailstore.iitd.ernet.in from the command prompt. It can also be an intermittent problem. You can be certain that we will hear about it pretty soon if the mail server is down for any significant length of time, but you can always call us at 7185 or 1771.
Please see the page on mail forwarding.
axxxx, eez09xxxx and so on are your login ids which you have to use for authenticating yourselves to the email server. However you can always set an alternate email id by editing the email alias field of your LDAP profile. If it is not already in use, your chosen email id will be assigned to you. For students we insist upon appending your group id to your chosen alternate email id, just to avoid complications like a first year student with an email alias neha@ee..... receiving a love letter intended for a person who may have just passed out and was using the same email alias.
If you set an email alias you should also change the From: and the Reply to: fields of your outgoing emails as well to enable people to reply to you using your alternate id. You can set these from the Preferences menu of your favourite email software - all of them let you change these.
Of course, your original email id (your login id) will also continue to work.
Our smtp server requires authentication for sending. So, script mailing is not possible unless you are willing to put your password in clear text in the script. We will not recommend it and the risk is entirely yours.
Please try again after disabling the firewall on your machine completely. On Windows machine this can be usually be done from the settings of your virus scanner. If it works, the problem is with your firewall which will need to be configured correctly.
We will need to see the header of the bounced messages, the possibilities are too many.
A few of the common reasons due to which this may be happening are:
The most common reason would be 1. above. We reject approximately 15 Lakh mails a week due to this reason, and only a handful of these are genuinine. Though the mail RFC doesn't mandate that both forward and reverse lookups are necessary before accepting mails, it is definitely a recommended setting for all mail servers (as per the mail RFC). We have an aggressive setting for mail acceptance. Most mail servers, including us, insist on reverse lookup before mail acceptance and this is an effective strategy for combating SPAM. Not only us but many others would be bouncing mails from such domains. We can make an exception for such a domain, but that would be an adhoc solution. We would suggest that you advise administrators of such domains to configure their DNS properly and let us know if that doesn't work.
In all cases the header of the bounced message should contain the exact reason.
JE FAQ 1.0 - Developed by J-Extension